0026-雙柱機械式汽車舉升機,機械式,汽車,舉升機 旋風分離器對稱蝸管進口的實驗室研發(fā) Bingtao Zhao, Henggen Shen, Yanming Kang 翻譯：于亮亮 摘要：設計三種具有不同幾何形狀進口的旋風分離器,一種是傳統(tǒng)的單一切向進口(CTSI),一種是對稱的直蝸管進口(DSSI),還有一種是對稱的收斂蝸管進口(CSSI)。進口類型對旋風分離器工作特性的效果,包括收集效率和壓降,本文研究并比較其與粒子大小和流速的關系。實驗結果表明對稱的蝸管進口(SSI),尤其是CSSI形狀進口,隨著新增的可忽略壓降的條件下越來越多的對收集效率有重要的影響。另外,收集效率和壓降的研究結果也包括試驗數(shù)據和理論模型之間的比較。 關鍵字:旋風分離器;對稱的蝸管進口;收集效率;壓降。 ⒈介紹： 旋風分離器廣泛應用于空氣污染控制領域，為含懸浮微粒氣體進行氣–固分離等工業(yè)應用[1］。由于其制造簡單,操作成本低,和對極端的苛刻條件的適應性好,因此無論是應用在工程上還是操作過程上旋風分離器成為最主要的除塵裝置之一。然而,越來越多的提倡環(huán)境保護，氣–固分離都強調應該分離出最大量的微塵粒子。為達到這個要求,旋風分離器幾何學和性能的改善要比替換可更換件來得重要。許多專家認為擴大旋風室是提高旋風分離器性能的主要因素,通過引進新設計的進口與操作變量。這包括對一臺分離試樣的旋風分離器的裝有多個進口葉片的分餾器的測試并結合其他的研究[2］,德奧特建立一個數(shù)學模型來預算小型圓柱多諧振蕩器旋風分離器的收集效率[3］,穆爾和麥克法倫以萊普勒的典型幾何學為基準測試一個有多個進口的旋風分離器[4］,高塔姆和斯蒂納斯設計和測試一個可換氣的多進口旋風分離器取樣器的最小方向偏差[5］,通過分離后的清潔空氣來比較一個雙進口旋風分離器的性能[6］。在本文中,介紹了一些形狀研究員設計的不同形狀進口的新式進口,和它們對旋風分離器的性能效果的實驗性研究。 ⒉試驗性的研究 三種具有不同幾何形狀進口的旋風分離器,包括傳統(tǒng)的單一切向進口(CTSI),對稱的直蝸管進口(DSSI),和對稱的收斂蝸管進口(CSSI),已經研制出了。它們的幾何形狀和尺寸見Fig1和Table⒈為了測試不同的進口類型所帶來的效果,其它的尺寸設計完全相同,僅進口的幾何形狀不同。 Fig.1 旋風分離器形狀示意圖：(a) Model A 傳統(tǒng)的單一切向進口 (b) Model B 對稱的收斂蝸管進口 (c) Model C 對稱的收斂蝸管進口。. Table 1：旋風分離器尺寸統(tǒng)計：（單位mm） Fig.2：試驗結構系統(tǒng)示意圖 圖⒉所示為實驗系統(tǒng)機構。 壓降是由接在旋風分離器進口和出口管的兩壓力計測量的。通過一數(shù)字微壓計(SINAP ,壓差1000-IIIC )讀得。收集效率是通過微顆粒大小分析器(SPSI,LKY -2)所得粒度分布計算的。由于Model B,C具有一樣對稱的進口,所以組合式旋風分離器各進口的流速是相等的。并且流速可由閥來控制;運行條件也相同,將濃度為5.0g/m3的粒子用雙噴管螺旋給料機喂到進口管中。固體顆粒為滑石粉核心密度的2700kg/m3,按原標準尺寸分配,平均直徑的5.97Am,幾何偏差為2.08。在這次測試過程中平均大氣壓,環(huán)境溫度,和相對濕度分別是99.93kPa,293K,75%。 ⒊結果和討論 3.1 收集效率 圖3顯示所測量的旋風分離器總效率與流速或者進口速度的關系。正如預料的那樣收集效率隨進口速度的增加而增加。然而,Model B Model C兩旋風分離器有著對稱的蝸管進口,在同一進口速度下,兩者的總效率永遠要高于傳統(tǒng)的單一切向進口旋風分離器(Model A)，特別是有CSSI的旋風分離器(Model C)的總效率最高。在測試給定的相同速度條件下,通過改善進口幾何形狀所帶來的旋風分離器總效率的增加率分別為0.15–1.15%和0.40–2.40%。 圖4(a)–(d) 比較不同進口類型的旋風分離器的分級收集效率。在進口速度分別為11.99,16.04,20.18,和23.85m/s時的流速分別為388.34,519.80,653.67,和772.62 m3/h?？梢?旋風分離器的摩擦效率隨粒子大小的增加而增加。所有旋風分離器的分級收集效率曲線都呈S形。DSSI(Model b)和CSSI(Model c)旋風分離器的摩擦效率分別比CTSI旋風分離器(Model a)大2–10%,5–20%。這表明進口的幾何形狀對旋風分離器的收集效率有著重要的影響。進入有對稱的蝸管進口的旋風分離器(Model B和C)的粒子容易聚集在旋風分離器壁上,因為粒子只能移動很短的位移,尤其CSSI(Model C)改變了粒子分布濃度并使粒子在進入旋風分離器的筒體前就從氣體中分離了出來.圖5根據傳統(tǒng)的理論[7–11］比較了流速為653.67m3/h(進口速度為20.18m/s)時的試驗數(shù)據。很明顯,以Mothes /Loffler模型Iozia/ Leith 理論得出的效率曲線比其它的學說所得的曲線更符合試驗結果。這些結果與研究進行經過Dirgo、Leith 和Xiang 等人的研究結果相吻合。 Fig.3 不同進口速度下旋風分離器的總效率 比較表明有些模型可以推斷一個還沒有公開的理論結果。但是現(xiàn)有的試驗數(shù)據理論還不足以推斷出流態(tài)和粒子濃度分布的變化是對稱的蝸管進口對旋風分離器性能產生的效果。為了更清楚地驗證對稱的蝸管進口對旋風分離器性能的作用效果,再看圖6,表示隨著流速或進口速度的變化引起的各個模型的50%切截尺寸。在相同進口速度下model c和model b的50%切截尺寸比model a要低。與進口速度的減少一樣,50%切截尺寸也是近似呈線性減少的。例如，當進口速度為20.18m/s時,50%切截尺寸的減少率由model b的9.88%和model c的24.62%決定。這表明新型進口可以促進旋風分離器的收集效率。 3.2.壓降 旋風分離器得壓差數(shù)值通常表示為一定數(shù)量的氣體入口速度壓頭高度差，用壓差數(shù)值系數(shù)表示，壓差數(shù)值系數(shù)是進口動壓壓差數(shù)值的分度。表2列出了在不同的入口速度時這三個旋風分離器的壓差數(shù)值系數(shù)值。 顯然,旋風分離器的壓降高低與流速高低有關。然而,一定流速或者入口速度下,A、B和C模式的壓力降系數(shù)有所不同，在5.21和5.76之間變化，其平均值為5.63。例如模式B在5.22–5.76之間變化，平均值為5.67；模式C在5.16–5.70之間變化平均值為5.55；模式A根據回歸分析計算。這是一個重點，因為由此有可能在沒有有效的壓差值增加的情況下提高氣旋收集效率。 表3列出了壓降的試驗數(shù)據與電流理論的比較結果。結果顯示Alexander和Barth模式與試驗數(shù)據最符合,盡管Shepherd ，Lapple 和Dirgo 氣旋模式推算也很出色。 Fig.4 不同進口速度時的選粉效率等級：(a)進口速度為11.99 m/s (b)進口速度為16.04 m/s (c) 進口速度為20.18 m/s (d) 進口速度為23.85 m/s. Fig.5 試驗所得效率等級與理論的比較 Fig.6 旋風分離器的50%切截尺寸 Table 2 ：旋風分離器的壓力損失系數(shù)： Table 3 ：與理論壓力損失系數(shù)比較： 4、結論 人們發(fā)明了一種具有對稱的蝸管進口(SSI)，DSSI和CSSI的新型旋風分離器,并且測試和比較了這種進口類型的旋風分離器的性能。實驗結果顯示這種DSSI旋風分離器和CSSI旋風分離器的總效率分別比CTSI旋風分離器高出0.15–1.15%和0.40–2.40%。此外,DSSI旋風分離器、CSSI旋風分離器和CTSI旋風分離器的壓力損失系數(shù)分別是5.63、5.67和5.55。盡管這些并聯(lián)進口增加了旋風分離器的復雜程度并加大了其成本,然而具有SSI尤其是CSSI的旋風分離器具有更好的收集效率,而且顯著的減少了壓力損失。這篇文章介紹了借助于改進進氣道幾何形狀設計而改善旋風分離器性能的可能性。 參考資料： [1] Y.F. Zhu, K.W. Lee, Experimental study on small cyclones operating at high flow rates, Aerosol Sci. Technol. 30 (10) (1999) 1303– 1315. [2] J.B. Wedding, M.A.Weigand, T.A. Carney, A 10 Am cut point inlet for the dichotomous sampl Environ.Sci.Technol. 16 (1982) 602– 606. [3] R.E. DeOtte, A model for the prediction of the collection efficiency characteristics of a small, cylindrical aerosol sampling cyclone, Aerosol Sci. Technol. 12 (1990) 1055– 1066. [4] M.E. Moore, A.R. Mcfarland, Design methodology for multiple inlet cyclones, Environ. Sci. Technol. 30 (1996) 271–276. [5] M. Gautam, A. Streenath, Performance of a respirable multi-inlet cyclone sampler, J. Aerosol Sci. 28 (7) (1997) 1265– 1281. [6] K.S. Lim, S.B. Kwon, K.W. Lee, Characteristics of the collection efficiency for a double inlet cyclone with clean air, J. Aerosol Sci. 34 (2003) 1085–1095. [7] D. Leith, W. Licht, The collection efficiency of cyclone type particle collectors: a new theoretical approach, AIChE Symp. Ser. 68 (126) (1972) 196– 206. [8] P.W. Dietz, Collection efficiency of cyclone separators, AIChE J. 27(6) (1981) 888– 892. [9] H. Mothes, F. Loffler, Prediction of particle removal in cyclone separators, Int. Chem. Eng. 28 (2) (1988) 231– 240. [10] D.L. Iozia, D. Leith, The logistic function and cyclone fractional efficiency, Aerosol Sci. Technol. 12 (1990) 598– 606. [11] R. Clift, M. Ghadiri, A.C. Hoffman, A critique of two models for cyclone performance, AI ChE J. 37 (1991) 285–289. [12] J. Dirgo, D. Leith, Cyclone collection efficiency: comparison of experimental results with theoretical predictions, Aerosol Sci. Technol. 4 (1985) 401–415. [13] R.B. Xiang, S.H. Park, K.W. Lee, Effects of dimension on cyclone performance, J. Aerosol Sci. 32 (2001) 549– 561. [14] C.B. Shepherd, C.E. Lapple, Flow pattern and pressure drop in cyclone dust collectors: cyclone without inlet vane, Ind. Eng. Chem. 32 (1940) 1246–1256. [15] R.M. Alexander, Fundamentals of cyclone design and operation, Proc. Aust. Inst. Min. Met. (New Series) (1949) 152– 153, 202– 228. [16] M.W. First, Cyclone dust collector design, Am. Soc. Mech. Eng. 49(A) (1949) 127–132. [17] C.J. Stairmand, Design and performance of cyclone separators, Trans .Inst. Chem. Eng. 29 (1951) 356–383. [18] W. Barth, Design and layout of the cyclone separator on the basis of new investigations, Brennst. Wa¨rme Kraft 8 (1956) 1 – 9. [19] J. Casal, J.M. Martinez-Bennet, A batter way to calculate cyclone pressure drop, Chem. Eng. 90 (3) (1983) 99– 100. [20] J. Dirgo, Relationship between cyclone dimensions and performance, Doctoral Thesis, Harvard University, USA, 1988. 5 附錄2——外語翻譯（原文） Computer aided process planning for sheet metal based on information management D. Lutters*, E. ten Brinke, A.H. Streppel, H.J.J. Kals Laboratory of Production and Design Engineering, University of Twente, PO Box 217, 7500 AE Enschede, Netherlands Abstract During the last few years, attention in the manufacturing cycle has shifted towards concurrent engineering (CE). With this, the integration of the different product life cycle processes has become a focus in both research and industry. However, it is obvious that the integration of all manufacturing processes, taking into account all life cycle aspects from initial functional requirements to final disposal, is hardly feasible in the traditional way. In this paper, the execution of the manufacturing cycle based on information management is explained by describing the development of a generic architecture for computer aided process planning. This architecture is elaborated upon for the field of sheet metal manufacturing in a small batch part environment. ＠2000 Elsevier Science S.A. All rights reserved. Keywords: Concurrent engineering; CAPP; Architecture 1. Introduction In the research presented here, it is advocated that the sheer integration of manufacturing processes within the product life cycle is insuf?cient to achieve true integrated product development. For this purpose, the main focus should be on the information that is applied and generated in these manufacturing processes. If the information of the separate processes can be made available during the entire development cycle, it can be the basis for the control of the entire manufacturing cycle. In order to take full advantage of the modi?ed role of information in the product development cycle, a different attitude with respect to the manufacturing processes is required. One of the main differences is, that the phases in the manufacturing process become instrumental to the information required in the manufacturing process. This immediately implies that processes in the manufacturing cycle haveto be defined as generic as much as possible. For example, it becomes practicable to interchange systems developed for different product types (prismatic, sheet metal, etc.). Moreover,if the interfaces of the mutual systems can be defined adequately, these systems can become independent modules,that are able to perform their tasks without being dependent on a predefined, sequential scenario. A ?rst prerequisite for this is the ability to effectively manage the information that becomes the basis of the manufacturing process. 2. Information management 2.1. Manufacturing engineering reference model In order to be able to deal with different views on a manufacturing system, the system is introduced by means of a reference model. A reference model represents a system as an organisation in terms of its structure of relatively independent,interacting components, and in terms of the globally defined tasks of these components [2]. The manufacturing engineering reference model proposed in the present context is shown in Fig. 1. This manufacturing engineering reference model is based on the manufacturing planning & control reference model introduced by Arentsen [1]. However, adaptations have been made, in order to emphasize the equivalent importance of products, orders and resources in the entire manufacturing cycle [4]. Company management is concerned with the control of customer orders. It is responsible for the strategic decisions concerning the range of products which will be produced and the processes and resources which are required to this end. Product engineering refers to all the engineering activities related to the product life cycle of a specific type of product.It is concerned with the design and development of a product type and its variants, starting from functional requirementsup to final recycling/disposal. Order engineering addresses those activities that relate a customer order to a specific (variant of a) product. It is the task of order engineering to compose production orders and to decide when given batches of products must be processed and with which resources. The objective of order engineering is the in-time execution of the production orders. Resource engineering refers to all (life cycle) aspects of the resources, required for the execution of the production activities. It therefore includes the specification, design,development, acquisition, preparation, use and maintenance of the resources of a company. Production is concerned with the actual execution of the plans generated by the engineering tasks. From production,information is fed back to these engineering tasks. In the manufacturing engineering reference model, information management is discerned as the kernel. This illustrates the opinion that the availability and accessibility of information is preferred over sheer data exchange. 2.2. Information management In recognising the fact that each of the departments in a company makes myriad decisions in order to generate required information, it is obvious that the reasoning behind all these decisions can hardly be transferred together with the information. Consequently, the need for feedback and interdepartmental communication increases, which may lead to extremely complex and uncontrollable flows of information between the separate departments. However, providing that information generated by the separate departments is attached to an overall and widely accessible model, this situation may change considerably. In this case, instead of `pushing' information from one department to another, departments can `pull' the information they require and are given access to. Hence, the focus can be on the information in support of the control of the manufacturing processes, and for this reason, the course of the manufacturing processes may be guided by the use of, and the need for information. The types of objects the information is concerned with(orders, products, operators, etc.) can vary considerably.Despite this variation, for the way the information is structured and attached to an overall model, it is unimportant whether information bears reference to, e.g. a product, a machine or its operator. Still, it is important to distinguish between different types of objects, as their different significance for the manufacturing processes is apparent. Each type of object can be attached to an overall model, a so-called information structure. In accordance with the three piles of the reference model, three of these information structures are discerned (see Fig. 2): ● product information structure; ● order information structure; ● resource information structure. Because the structures evolve independently of each other, whereas the way of their mutual interactions remains the same, the entire range of manufacturing environments can be addressed: from engineer-to-order to mass production.For example, in an engineer-to-order environment, the order information structure and the product information structure evolve almost simultaneously and the resource information structure remains relatively unchanged. In a mass production environment, the product information structure and the resource information structure are developed concurrently and remain rather static henceforth.Subsequently, the order information structure is used to specify the choice of a certain product variant, and to determine the lead time and other logistic consequences. The different behaviour of the information structures in different manufacturing environments implies that each of the structures has its own life cycle. In aiming for the integration of processes, the life cycles must be oriented on the information contained in the information structures, instead of on the processes concerned with this information.In elaborating this concept for the product information structure, the product life cycle is oriented upon the product instead of on the manufacturing processes.In this way, information management as part of the reference model, consists of an integrated collection of tasks that can be used as a basis to initiate, accompany, control and evaluate all the manufacturing processes in a structured and transparent way. These tasks are based on the information contained in the three information structures, as is shown in Fig. 2. It may be obvious that if the engineering tasks are based on information from one of the information structures, they can always be based on up-to-date information, not only from the structure they are directly related to, but from the other structures as well. Especially when applying the concurrent engineering principles, the simultaneous development of products and the related processes can be realised much easier. 3. An architecture for information management Based on a reference model, an architecture can be developed. An architecture is a specification of the functions of a system and the interactions between these functions in terms of input and output, as observed by the user. The architecture can be applied as the basis for the implementation and realisation of the intended functionality of the system. It is important to distinguish the different types of architectures that are required to establish the functionality represented in the reference model. On the one hand,architectures are to be developed for the engineering processes,e.g. for a design system or a process planning system.On the other hand, an architecture for information management plays a different, yet significant role. As information management is the kernel of the reference model proposed in Section 2.1, it is conducive to develop an architecture that in itself can constitute the footing for architectures outlining the engineering processes. Therefore,the main role of this architecture is to accommodate all functionality concerned with information processing to the architectures built upon it. Additionally, because information management is concerned with all information processing,it can also offer the possibility to initiate, accompany,control and evaluate development cycles by actuating the engineering processes. Moreover, even the entire manufacturing history can be captured. With this in mind, it is important to notice that no distinction is made between different types of information.The architecture has to deal with information concerningproducts as well as resources and orders. The architecture for information management is shown in Fig. 3. Before discussing the function blocks in the architecture,the contiguous parts are reviewed. First of all, the role of the user might easily be misconstrued; the above-mentioned task of the architecture implies that it is the basis for other systems. Consequently, what is called the `user' here, can only be a system based on this architecture. Even if aDhumanDuser wishes to access the information about, e.g. a product, it has to be done via a system that is built on top of information management. All users access information management through an interface. For systems that are designed according to the principles outlined in the above, this interface hardly influencesthe flow of information. For other systems, e.g.commercially available CAD or CAM systems, the interface accommodates the two-way exchange of information between the user and information management. The complexity of the interface can vary considerably, depending on the level of aggregation that has to be provided. The controller translates the exchanged information into actions. These actions can initiate, e.g. search, storage or retrieval procedures in information management, but they might also initiate actions of other users (e.g. a specific request for information, or the notification of a change that might influence actions of other users). It is important to recognise that information management in itself does not store information in a central database. It merely ‘redirects’information to and from databases owned by different users. For this purpose, a database interface is required. This interface provides low level access to different types of databases. The main function blocks of the architecture can therefore rely upon the database interface for the unformatted transfer of information. As mentioned before, the actual data is not stored in information management,but in several different types of databases owned by different users. As an example, a process planning department and a design department will have different databases.Information management virtually integrates these databases. In order to know which databases are involved in a certain project (concerning either products, resources or orders),meta-information is required. This meta-information is stored in one metabase per project. Such a metabase contains,e.g. the following information: ●specification of databases and database tables; ● specification of users and their access rights; ● specification of the information structure (including domains and views [5]); ●specification of the project ontology. Especially the use of an ontology (e.g. [3]) is very important. It offers the possibility of dynamically maintaining the meta-information of a project, without the need to predefine the type of information involved in the project. 3.1. Function blocks in the architecture Information exchange. The main function block in the architecture is information exchange. The task of this module is the translation of incoming user requests for information into actions that can be performed by the other modules. Information ontology. In order to be able to process any information request, it is essential to understand its contents.For this purpose, an ontological specification of the information is used. This is also required for –literally-translating a request into actions. Information structure. All information accessible via information management is structured, in order to allow for consequent settlement of information flows. The structure is established and maintained by this function block.More information on information structuring can be found in [5]. User access manager. Not every user has access to all types of information. For example, a process planner may be allowed to read design information, but he is not probably entitled to change it. This function block is therefore required to validate all user requests. User manager. As mentioned above, different users have different rights. Consequently, this function block acts as an account manager, specifying user access rights to (parts of)the structure, database tables and user groups. Life cycle conduct. This function block is concerned with the ontology of the manufacturing process. It specifies the required types of information and their mutual dependencies.Moreover, it is used to navigate the manufacturing process based on the information content. The need for information can be determined by comparing the current ontology of a product with the ontology describing the entire product life cycle. As a simple example,it is obvious that if production of a certain component is not outsourced, e.g. process planning information and production information have to become available. This, and the sequence in which it has to be generated can be deduced by life cycle conduct. Configuration and version manager. Many companies experience problems with version control, configuration management, etc. The apparent solution is to base PDM,ERP, etc. on the information content instead of on the processes. This additionally offers the possibility to maintain the manufacturing history. Another function of this block is the control of information integrity and transparency. 4. An architecture for process planning for sheet metal As mentioned before, the architecture for information management is meant to constitute the basis for other architectures. Therefore, an architecture for, e.g. a process planning system does not need to worry about data storage,etc. because this can be commissioned to information management effortlessly. Consequently, the architectures for engineering processes can be focused on their actual tasks. In this section, an architecture for process planning will be presented. Hitherto, these architectures were often designed for one specific product type (e.g. prismatic or sheet metal),which was reasonable, because most of the time, products were designed while implicitly presuming certain production processes. For the future we foresee a method of approach, where (in the utmost case) merely the functional faces of a design are specified, and knowledge of different candidate production processes can be applied to further specify the product geometry. This implies that process planning knowledge (and therefore its functionality) has to be available in a consistent way, based on a generic archetype. From this, it is clear that the strict borders that nowadays exist between, e.g. design and process planning are to be removed. This is merely possible if the manufacturing processes are dedicated to the product information instead of the other way around (see Section 3). Because the strict distinction between design and process planning disappears, consequently, it is difficult to circumscribe an architecture for any engineering process. Until now, this delineation has been made artificially, by defining distinct stages in the manufacturing process by means of scenarios. However, based on information management the possibility arises to deal with the engineering processes in a more flexible way. Obviously, we have to find a way of categorising engineering functionality that does justice to this flexibility. An example may help demystifying this reasoning. Until now, a design was finished, and transferred to the process planning department. When this department had finished its tasks, other departments had to carry on. In the desired situation, outlined in the above, a designer can exploit process planning knowledge and functionality the moment it is required. This implies that there is no need to make a process plan for an entire product in one go, but process planning information can be attached to, e.g. one feature as well. Even cost estimations or production planning information can be taken into account during the design phase or any other phase of the manufacturing process [8].This allows the designer to make well-founded decisions. Obviously, this has a considerable influence on the architectures that can be applied for process planning. As mentioned before, the template for the architecture must be independent of the type of production processes regarded.Moreover, while the function blocks in the architectures contain process type specific tasks, their mutual interaction should be generic. In the following, this template is presented and it is elaborated upon for the sheet metal type of product shown in Fig. 4 The architecture is shown in Fig. 5. It is partly based onthe PART-S architecture [7]. An important differencewith existing architectures is the fact that the input of a system based on this architecture is not prespecified. The input can be a product model, but might also be (a group of) features or faces. As mentioned before, the architecture is based on information management, which -strictly speaking- is therefore not a part of the CAPP architecture. The controller is dedicated to coordinating the functions provided in the architecture, and assuring consistent information flows with information management. The user can influence the behaviour of the system by means of the user interface. This interface has to provide more than just a view port on the activity in the system. The user must be able to pose directed questions, in order to engender specific operations. The other