下载文档原格式
VISION GUIDE INTEGRATED ROBOT GUIDANCEDesigned for vision guidance applications, Epson Vision Guide makes precision robotic guidance easy to use. Fully integrated within the Epson RC+® development environment for easy configuration and calibration, this intuitive solution features a point-and-click interface that makes it simple for users of all levels. It also features wizards and auto calibration methods, plus a combination robot/vision simulator for rapid offline testing. With a single point of support for both robots and vision guidance, Epson Vision Guide allows for fast development and simplified maintenance. An efficient and versatile solution, it also includes tools to address inspection, gauging and barcodes.2Visit /visionguideIntegrated vision guidance with easy configuration and calibrationIntegrated vision guidance solution — designed with tools specifically made for vision guidance applicationsSeamless integration — works with all current Epson robotsWizard-based setup — for fixed and mobile camera/ robot calibration; with auto calibration and no-touch calibration solutionsFast development with point-and-click interface — fully integrated into the Epson RC+ development environmentCombination robot/vision simulator — for rapid offline testing and developmentLow-cost scalable system — accommodates multi-camera applicationsHigh-precision parts placement — features built-in kinematic equations and advanced algorithmsPowerful vision tools — full suite of options for awide variety of applications and industriesIntuitive operation — easy to learn and use forentry-level to advanced usersPowerful throughput — CPU and vision processing runs parallel with Epson robot controllersExpansive camera support — supports up to12 cameras (GigE and USB); up to 20 MPmonochrome and color camerasVisit /visionguide3Visit /visionguide4ApplicationsVision Guide supports the common vision applications required in factories today. These include visionguidance, inspection, gauging and identification.IDENTIFICATION INSPECTIONQR CodeUPC Barcode Optical Character RecognitionData MatrixVisit /visionguide5PrecisionWith high resolution cameras, powerful tools and integrated calibrations, Vision Guide helps to optimize guidance and precision.High SpeedFast frame rates and high-speed processors allow Vision Guide to maximize throughput.Parallel ProcessingVision Guide offers powerful independent processors for both vision and robot motion calculations, enabling vision processing to be done in parallel with robot motion.This allows simultaneous processing for maximum performance.Vision guidance and inspection made easyWith advanced tools and parallel processing, Vision Guide optimizes performance, making it faster, moreprecise and easier to use.Visit /visionguide6Vision ObjectsDrag and drop vision objectsdirectly onto the imagedisplay windowFlowchartEasily identify how the sequences are composedObject Properties and ResultsUsers can input and adjust data. The software automaticallygenerates associated results based on input parametersIntuitive by designWith a point-and-click interface, just three core commands (VRUN, VGET and VSET), powerful object tools and built-in calibration data, all integrated within Epson RC+ Development Software, Vision Guide is easy for anyone to learn and use.Vision ButtonLaunch Vision Guide directly from Epson RC+Locate Count InsGeometric Correlation Blob Edge Polar Arc Finder Line Finder Box Finder Corner Finder Frame Line Point ContourVisit /visionguide7Versatile tool setVision Guide features a series of objects that can be used to easily find, measure and inspect parts and features. With everything from Geometric search to Blob and Edge finding tools, these objects make it easy tooptimize virtually any vision application.CorrelationMeasures quality compared to previously trained features for alignment, inspection, positionand orientation.GeometricFinds a model based on geometric features. Used for determining position and orientation.BlobComputes geometric,topological and other image features. Used for determining presence/absence, size, positioning and orientation.EdgeLocates edges by identifying changes in grey value from dark to light or light to dark.Uses correlation of a rotational area to determine object orientation.OCROptical Character Recognition is used to recognize character strings in an image.CodeReaderReads bar or two-dimensional codes, including data matrix and others.ColorMatchDetects user-defined colors.LineFinder Determines the location of a line in an image.LineInspectorIdentifies deviations on a linear path between two points.ArcFinderDetermines the radius and center point of an arc or major/minor axes and the angle of an ellipse.ArcInspectorCompares a template image to an input image to identify defects.FrameProvides dynamic position reference for other vision objects.LineDefines a line between two objects.Point Defines reference positions for other objects. BoxFinder Determines the center of an object.CornerFinderIdentifies the intersectionposition of two lines that form a corner.ContourGenerates a contour based on the external shape of an object.The power of MultisearchSave programming time with Multisearch. This flexible feature makes it easy to configure multiple vision tools, then automatically run the same set of tools on all parts that are found. Users can apply settings to various tools with one click, rather than setting up each tool individually. This enables the user to configure multiple objects and use them simultaneously at runtime when searching for a feature.8Visit /visionguide9Visit /visionguideCalibration made easyFor optimum precision, Vision Guide supports true geometry-based calibration. Unlike competitive products, which typically use basic mapping techniques, Vision Guide goes one step further to maximize performance and ensure consistency of calibration.Vision Guide supports a wide variety of calibrations, including both fixed and mobile mounted cameras, to optimize precision and meet most any need.Fixed DownwardFixed UpwardMobile J2Mobile J4Mobile J5Mobile J6StandaloneSCARA AND 6-AXISSCARA6-AXISNO ROBOTCALIBRATION WIZARDThis innovative tool takes users through the calibration process, step by step.SUPPORTED VISION CALIBRATIONSVisit /visionguide10Powerful performanceVision Guide supports many different resolutionsand is compatible with both monochrome and color cameras.CAMERAS SUPPORTEDPV1 CONFIGURATIONCV2 CONFIGURATIONSystemCV2SA CV2HAPV1Robot ControllerRC700A, RC90, RC90B, T-Series, VT-SeriesCameras Supported (Epson cameras only)GigE: Mono (0.3 MP, 1.3 MP, 2 MP, 5 MP, 10 MP and 20 MP) and Color (2 MP, 5 MP, 10 MP and 20 MP)USB: Mono (0.3 MP, 1.3 MP and 5 MP) and Color (1.3 MP, 5 MP)Vision ToolsLocate: Geometric, Correlation, Blob, Edge, Polar, ArcFinder, LineFinder, BoxFinder, CornerFinder, Frame, Line, Point and Contour Count: Blob, Correlation, GeometricInspect: Blob, DefectFinder, Line, LineInspector, ArcInspector and Color Match Read: CodeReader and OCR Image: ImageOp and TextQuantity of Connectable Cameras Up to 6 cameras (2 USB and 4 GigE cameras)Up to 8 GigE camerasImage Processing Speed StandardHigh-speedN/A Safety StandardCE, UL, KCN/A Dimensions W x D x H (excluding rubber feet)232 mm x 175 mm x 70 mm N/A Operating Temperature and Humidity 5~40 deg C, 20~80% (non-condensing)N/A Direction of Installation Horizontal or Vertical N/A Power Source Voltage DC 19 ~ 24 VN/A Rated Electric Current 11.57 A (at 19 V DC) ~ 9.16 A (at 24 V DC)N/A Weight2.1 kgN/AInterface (connection)Ethernet (for communication with Robot Controller)RJ45: 2 ports (10M/100Mbps). Pre-bridge setting for the 2 ports. Can be connected to HUB or Switch.N/AEthernet (for GigE camera)RJ45: 4 ports (1000Mbps). Power Over Ethernet (PoE) supported. Cannot connect to HUB or Switch.USB 2.0USB 2.0: 4 ports (for USB Camera, USB Memory, Mouse, Keyboard)Monitor Connection VGA: 1 port, DVI-D: 1 port (SXGA fixed) The 2 ports display the same output (mirror display)CON1, CON2Not availableCV2 Standard AccessoriesMounting Plates (1 set), Power Supply Connector (1 pc)N/A Vision System Controller CV2PCRobot Controller RC700ARobot Controller RC700ARobotRobotUp to 2USB +Lenses and Cameras Up to 4GigE +Lenses and CamerasUp to 8GigE +Lenses and CamerasVisit /visionguide11EPSON and Epson RC+ are registered trademarks, EPSON Exceed Your Vision is a registered logomark and Better Products for a Better Future is a trademark of Seiko Epson Corporation.All other product and brand names are trademarks and/or registered trademarks of their respective companies. Epson disclaims any and all rights in these marks. Copyright 2020 Epson America, Inc. CPD-57146 3/20Epson Business Solutions• World-class customer service and support • Cost-effective, high-quality solutions • A commitment to the environmentDiscover how Epson can help you work toward the future. /forbusinessEpson America, Inc.3840 Kilroy Airport Way, Long Beach, CA 90806Epson Canada Limited185 Renfrew Drive, Markham, Ontario L3R 6G3 www.epson.caTM。
培训大讲堂官方YY 频道：3660mCCNA题库考试代号： 640-802考试时间：英文110+30=140分钟通过分数： 825题库版本： V104.4鸿鹄论坛招募CCNA、CCNP答疑讲师答疑地点：鸿鹄官方YY频道3660鸿鹄大讲堂：bbs.hh010./thread-46172-1-1.htmlCCNA题库战报交流QQ群：144288127 （500人超级群）CCNA题库战报交流区： bbs.hh010./forum-261-1.html1000 G视频教程免费下载：bbs.hh010./forum-228-1.htmlCCNA（640-802）题库V104.4CCNA（640-802）题库V104.4（情人节版）CCNA 题库战报500人超级QQ群 144288127V104系列是官方的终结版本，以后不会再出V105 V106 V108等等CCNA 最新题库/最新战报发布区： bbs.hh010./forum-261-1.html下载官方正版题库、看最新考试战报，请随时关注鸿鹄论坛 bbs.hh010.CCNA考试报名1900，详情请联系鸿鹄全国区十七名客服 QQ 71202306========================================更新容：V104.1修正V104中错误题目，确定经典争议题目答案；V104.2增加拖图题并可完美模拟考试，VCE题库增加中文注释；V104.3针对思科CCNA考试变题，更新考试新增题目93Q,更新V104.2实验题；V104.4增加全文中文注释，汇总V104.3九次更新，删除部分旧题目，为目前最新官方正版题库；2011.8.1 增加每日新题，修订部分错误。
2012.2.14 情人节版增加5道新题，分别是519、520、521、522、523题修改176题、375题、443题、482题答案错误修改59题、88题、453题、107题、270题注释错误增加个别疑难拖图题注释，优化实验题=============================================QUESTION 1When you are logged into a switch, which prompt indicates that you are in privileged mode?(当您登录到交换机，哪种提示表明你在特权模式？)A. %B.C. >D. $E. #Answer: ESection: Chapter 4: Introduction to Cisco IOSExplanation/Reference:特权模式就是#提示符QUESTION 2Which command shows system hardware and software version information?(哪些命令显示系统硬件和软件的版本信息？)A. show configurationB. show environmentC. show inventoryD. show platformE. show versionAnswer: ESection: Chapter 4: Introduction to Cisco IOSExplanation/Reference:查看系统的软件和硬件信息使用的命令是show versionQUESTION 3Cisco Catalyst switches CAT1 and CAT2 have a connection between them using ports FA0/13. An 802. 1Q trunk is configured between the two switches. On CAT1, VLAN 10 is chosen as native, but on CAT2 the native VLAN is not specified.What will happen in this scenario?(思科 Catalyst 交换机 CAT1 和 CAT2 有它们之间的连接使用端口FA0/13。
VSC8211 Linking CPUs with R/GMII Interfaces to SGMII-BasedSwitches1Revision History (1)1.1Revision 1.0 (1)2Introduction (2)2.1Audience (2)2.2References (2)2.2.1Vitesse Documents (2)2.2.2IEEE Standards (2)2.2.3External Documents (2)3 A Managed Switch System (3)4System Considerations (4)4.1How Many Interface Ports? (4)4.2Packet Traffic Shaping (4)4.3RGMII-SGMII PHY Device Link Monitoring (4)5Hardware Considerations (5)5.1Connecting GMII (5)5.2Connecting RGMII (6)5.3Connecting SGMII (7)5.4Control and Status Connections (7)6Software Considerations (9)6.1VSC8211 Register Configuration (9)6.2SGMII Switch Register Configuration (9)1Revision HistoryThe revision history describes the changes that were implemented in the document. The changes arelisted by revision, starting with the most current publication.1.1Revision 1.0Revision 1.0 was the first release of this document. It was published in April 2005.2IntroductionThis Application Note will describe design considerations for connecting an embedded microprocessorthat contains a GMII or RGMII MAC interface to an SGMII-based Gigabit Ethernet Switch. This documentwill cover system, hardware, and software considerations as well as advantages and limitations for each.Systems such as IP DSLAMs, wireless platforms, and enterprise routers often require enhanced securityprotocol processors to help to perform switching and parsing of packets. However, packet processors’Ethernet interfaces are a generation behind the latest Ethernet switch devices. The latest GigabitEthernet switch devices with high port counts of 16-24 ports per chip have migrated towards SGMIIinterfaces, while processors are only now offering both GMII and RGMII interfaces. For a packetprocessor to connect to the latest gigabit switch, there will need to be an interface conversion device toget an RGMII processor to link to an SGMII-based Ethernet switch. This document will cover variousdesign considerations for connecting an embedded microprocessor with a GMII or RGMII MAC interfaceto an SGMII-based Gigabit Ethernet switch. This document will address system, hardware, and softwareconsiderations as well as advantages and limitations for each.2.1AudienceThis document is geared toward system, hardware, and software designers.2.2References2.2.1Vitesse DocumentsVSC8211 Datasheet (VMDS-10105)VSC8224 Datasheet (VMDS-10107)VSC7372 Datasheet (PD0031)VSC7374 Datasheet (PD0028)VSC7376 Datasheet (PD0032)VSC8211 Design and Layout Guide (VPPD-01173)VSC8224 Design and Layout Guide (VPPD-01145)2.2.2IEEE StandardsCSMA/CD Access Method and Physical Layer Specification (IEEE802.3)2.2.3External DocumentsFreescale MPC8548E Fact Sheet (MPC8548FS)Intel IXP2325 Product Brief (30367902)AMCC PowerPC 440GX Product Brief (PB2000)Mindspeed M27481 Product Brief (27481-BRF)3 A Managed Switch SystemA managed switch system is composed of at least an Ethernet switch chip, several physical layer devices(PHYs) that can interface to copper or fiber links, and at least one embedded processor. The system willgenerally be responsible for managing packets at a level of up to Layer 3 or higher.Figure 1 • Managed Switch Block Diagram4.1How Many Interface Ports?One factor to consider is how many interface ports from the switch will be connected to the embeddedprocessor. For example, the MPC8548E PowerQuicc III has four-gigabit Ethernet MAC interfaces. All fourof these ports could be linked to the Ethernet switch.4.2Packet Traffic ShapingGenerally a gigabit Ethernet connection requires at least 1 GHz of dedicated CPU processing power.Most embedded processors cannot handle a large continuous burst of packet data of this magnitude. Toprevent a processor from being overrun, it is important to consider if traffic shaping will be required.Traffic shaping is useful in that it can limit the amount of egress traffic from being sent out of a switchport into a bandwidth-limited device, such as a CPU.4.3RGMII-SGMII PHY Device Link MonitoringTo ensure the link between the processor and switch is active, there are several monitoring methods toconsider.The PHY’s link status register bit can be continuously polled.The PHY’s interrupt pin is connected to the interrupt controller to monitor change in link status.The LINK LED can be connected to a GPIO pin on the processor and then this pin is monitored.5Hardware ConsiderationsOnce the number of ports is established, the RGMII-SGMII conversion device must be selected. For 1-2ports, the VSC8211 single gigabit PHY can be used. For higher ports, the VSC8224 quad gigabit PHY is abetter choice due to its compact footprint size and low power.The following information in this section is a general description. Please consult both the PHY’sdatasheet or design and layout guide for more specific design information.Figure 2 • RGMII-to-SGMII Hardware Connectivity5.1Connecting GMIIGMII is a 25-pin per port interface. It has a clock speed of 125 MHz and 8 data bits in both directions.The interface clock is sourced by the PHY.Figure 3 • GMII Connection Diagram5.2Connecting RGMIIRGMII is a reduced pin count version of GMII as it only has 12 pins per port. While it uses the same 125MHz clock speed, the data pin count is reduced to 4 bits and the data is clocked in on both edges of theclock in a double-data rate manner.Figure 4 • RGMII Connection DiagramAnother aspect of RGMII that is different from GMII is that it requires a clock delay skew of 1.5 ns–1.9 nsAnother aspect of RGMII that is different from GMII is that it requires a clock delay skew of 1.5 ns–1.9 nsto either be placed on the board with a delay trace or the delay is created internally in the MAC and/orPHY. The VSC8211 offers this clock delay skew feature on both TX and RX pairs thereby removing theneed for a board trace delay. See the VSC8211 or VSC8224 Design and Layout Guide for moreinformation.5.3Connecting SGMIISGMII is a further pin reduction of GMII as it is only a 4-pin interface. The data and clock are embeddedand transmitted on a two pin differential interface in both directions. The latest switch will operate itsport interface using the SGMII interface. Both the VSC8211 and VSC8224 cannot perform a full RGMII-to-SGMII conversion. These devices however, can operate as an RGMII-to-1000BASE-X SerDes mediaconverter. 1000BASE-X SerDes is compliant electrically and functionally to SGMII’s 1000 Mbps setting.From a permanent link perspective, 1000 Mbps is the only speed that is required in an SGMII-basedEthernet switch system. Therefore the RGMII-to-1000BASE-X mode can be used to link the processor tothe SGMII-based Ethernet switch.For the VSC8211/VSC8224, AC coupling capacitors are needed from the processor to the PHY. The SGMIIswitches such as the VSC7372/74/76 have a register setting to allow the PHY-to-Switch portion to beelectrically compatible. To allow the SerDes on the PHY to link, the SIGDET pin must also be asserted bytying it high.Figure 5 • SGMII Connection Diagram5.4Control and Status ConnectionsIn order to setup the PHY the MDC and the MDIO must be connected to the host processor to setup theoperating mode and other PHY register settings. Also depending on how the processor will monitor thePHY during normal operation, other pins such as the interrupt pin (MDINT) or the LINK LED pin will needto be connected.Figure 6 • Control and Status Diagram6.1VSC8211 Register ConfigurationFor the VSC8211, the following registers must be configured.Set the operating mode (see the following table).If using RGMII, then set the delay skew setting (register 23[11:8]).Set Auto-negotiation Disabled (Register 0.12 = 0).Set Speed Selection (Register 0.[6,13] = 10).Set Duplex to Full (Register 0.8 = 1).If using MDINT pin as a link indication, set Register 25.15 = 1 and Register 25.13 = 1 (Link statechange indication).Table 1 • Setting the VSC8211 Operating Mode (Register 23[15:12, 2:1])Register Setting Description0011 01GMII-Fiber (1000BASE-X SerDes)0001 01RGMII-Fiber (1000BASE-X SerDes)6.2SGMII Switch Register ConfigurationFor the VSC7372/74/76 switch, the following registers must be configured in order to link to theVSC8211. This is in addition to the settings that are required for initialization of the switch. Thesesettings can be found in the Minimum Software Requirements section of the VSC7372/74/76datasheets.Set the SGMII_MACRO_CFGx.TX_ENA (Block 1, 0x1A bit 28 = 1)Set the SGMII_MACRO_CFGx.TX_OUTPUT_LEVEL (Block 1, 0x1A bit 26 = 1)Set the SGMII_MACRO_CFGx.TX_RESET (Block 1, 0x1A bit 25 = 1)Set the SGMII_MACRO_CFGx.RX_IB_AUTO_SQUELCH (Block 1, 0x1A bit 24 = 1)Set the SGMII_MACRO_CFGx.TX_COMMONMODE_TERM_ENA (Block 1, 0x1A bit 23 = 1)Set the SGMII_MACRO_CFGx.CDR_DISABLE (Block 1, 0x1A bit 22 = 0)Set the SGMII_MACRO_CFGx.RX_ENA (Block 1, 0x1A bit 8 = 1)Set the SGMII_MACRO_CFGx.RX_RESET (Block 1, 0x1A bit 0 = 1)Set the SGMII_INPUT_COMMONMODE_SELx.IB_B (Block 1, 0x1B bit 9 = 1)Set the SGMII_INPUT_COMMONMODE_SELx.IB_A (Block 1, 0x1B bit 0 = 1)Also, if traffic shaping is being employed, this can be found in the following table.Table 2 • Switch Egress Port Traffic Shaping ControlRegister Setting Register DescriptionWS_CONFx.ENABLE Block 1, 0x28 bit 6Enables/Disables ShapingWS_CONFx Block 1, 0x28 bits 12:7, 5:0Configures the ShapingWS_BUCK0Block 1, 0x29 bits 20:0Configures Queue 0 BucketWS_BUCK1Block 1, 0x2A bits 20:0Configures Queue 1 BucketWS_BUCK2Block 1, 0x2B bits 20:0Configures Queue 2 BucketWS_BUCK3Block 1, 0x2C bits 20:0Configures Queue 3 BucketMicrosemi HeadquartersOne Enterprise, Aliso Viejo,CA 92656 USAWithin the USA: +1 (800) 713-4113Outside the USA: +1 (949) 380-6100Sales: +1 (949) 380-6136Fax: +1 (949) 215-4996Email:***************************© 2005 Microsemi. All rights reserved. Microsemi and the Microsemi logo are trademarks of Microsemi Corporation. All other trademarks and service marks are the property of their respective owners.Microsemi makes no warranty, representation, or guarantee regarding the information contained herein or the suitability of its products and services for any particular purpose, nor does Microsemi assume any liability whatsoever arising out of the application or use of any product or circuit. The products sold hereunder and any other products sold by Microsemi have been subject to limited testing and should not be used in conjunction with mission-critical equipment or applications. Any performance specifications are believed to be reliable but are not verified, and Buyer must conduct and complete all performance and other testing of the products, alone and together with, or installed in, any end-products. Buyer shall not rely on any data and performance specifications or parameters provided by Microsemi. It is the Buyer's responsibility to independently determine suitability of any products and to test and verify the same. The information provided by Microsemi hereunder is provided "as is, where is" and with all faults, and the entire risk associated with such information is entirely with the Buyer. Microsemi does not grant, explicitly or implicitly, to any party any patent rights, licenses, or any other IP rights, whether with regard to such information itself or anything described by such information. Information provided in this document is proprietary to Microsemi, and Microsemi reserves the right to make any changes to the information in this document or to any products and services at any time without notice.Microsemi, a wholly owned subsidiary of Microchip Technology Inc. (Nasdaq: MCHP), offers a comprehensive portfolio of semiconductor and system solutions for aerospace & defense, communications, data center and industrial markets. Products include high-performance and radiation-hardened analog mixed-signal integrated circuits, FPGAs, SoCs and ASICs; power management products; timing and synchronization devices and precise time solutions, setting the world's standard for time; voice processing devices; RF solutions; discrete components; enterprise storage and communication solutions; security technologies and scalable anti-tamper products; Ethernet solutions; Power-over-Ethernet ICs and midspans; as well as custom design capabilities and services. Microsemi is headquartered in Aliso Viejo, California, and has approximately 4,800 employees globally. Learn more at www. .VPPD-01208。
ANSYS Release 15.0 Structural Mechanics HighlightsRichard Mitchell ANSYS UKAgendaAnalysis of Large and Complex ModelsMotivationMany users deal withalways larger models.Increased performanceand usability is requiredat each step of ananalysis in order toreduce the time fromgeometry to results.Submodeling for local refinementSubmodelingsaves time whenonly a portion ofthe modelmatters.Submodeling between shells and solids2D to 3D submodeling allows tocompute local detailed results that are not captured using a surface model.R15.0HPC and GPU•Linux workstation : Two Intel Xeon X5677processors (3.47 GHz, 8 cores total), 48 GB RAM, 2 NVIDIA Tesla C2075, Red Hat EL 6.12.1M DOF, Nonlinear Static AnalysisThe sparse solver now utilizemultiple GPUs to reduce solution timeHPC and Explicit DynamicsThe ParallelTrajectory Contact technology allows for fastercomputation of Explicit solutions.0.51.52.53.54.55.56.57.58.5024681012S p e e d -U p Number of coresR15.0HPC and Linear DynamicsA new proprietary Subspace Eigensolver accelerates the computation of normal modes on large models.R15.02.09 MDofs first 20 modesKeyboard shortcutsKeyboard Shortcuts are now supported in Mechanical forcommon actions such as: Select All Objects (Ctrl+ A),Body Filter Selection (Ctrl+B), Zoom to Fit (F7).R15.0Scoping entities to FE nodesAs with previous releases, R15 provides closer links to the finite element model as opposed to geometry only.Remote Forces, Remote Displacements, Joints,Springs, Beam Connections, Point Masses as well as paths can now be scoped directly to nodes.R15.0AssembliesMotivation for Mesh AssembliesGeometry is not the only starting point of a Workbench based structural simulation. Multiple finite element models can be assembled and leverage all Mechanicalfunctionalities, including contact detection.R15.0Mesh Assembly from CDB filesYou can now import mesh data (solids and shells) from CDB file into Workbench using the External Model system and also scale, rotate or translate parts.Contact detection will happen as if you are working with geometry data.R15.0Model AssemblyMultiple WB systems can also becombined. Geometry, Mesh andNamed Selections are retrieved.R15.0R15.0 MeshingMotivationWith R15.0, wehave pursued threemain goals forpreprocessing:increase theperformance,reduce memoryrequirements andimprove robustnessof algorithms.Performance increase SPAR To increase the user’s productivity, our meshing algorithms havebeen improved to reduce the meshing time as well as the memory requirements.R15.0Mesh Failure Handling Out of date mesh:When user changes mesh controls or updates geometry and mesh is out of date, the mesh is colored differently foreasier inspectionFailed mesh:When meshing fails, some meshis returned, but coloreddifferently for easier inspectionWhen meshing fails in surface meshing, valid surface mesh is returned. Edge coloring can indicate where problem is.Additional feedback is provided to the user in order to understand where failure occurred and which area is causing the failure.R15.0Hex meshing robustnessThe robustness of our automated hex meshing solutions has been improved for swept mesh along varying profiles as well as for complex geometries.R15.0Modeling 3D Composites ShapesThermal analysis of solid composites in MechanicalThermal analysis of composites is necessary to understand how thermal effects will affect the potential failure of composites products subjected to temperature changes such as fuselage parts.R15.0Advances in composites modelingProgressive damageProgressive damage techniques are required to understand the ultimate failure of a composites products.Such failure may happen because of successive plies failures or from delamination between plies.R15.0Customization for Structural MechanicsMotivationCompanies need toinclude best practicesin their simulationenvironment so as toprovide the ability touse and re-use expertknowledge, beyondstandard capabilities.ACT for Design Modeler –R15•Ability to create additional customized features in DM•New objects for specific geometry creation (pipes…)•«As native » integration•Build an API on top of Parasolid featuresACT-based propertiesCreation of one ACT-based object to encapsulate user-defined geometryR15.0ACT for DesignXplorer –R15Proprietary optimizer accessible in DX, as anadditional optimization methodSpecific settings of the proprietary optimizers presented as for any other standard DX methodR15.0Fracture MechanicsMotivationEngineers need to investigate theconsequences of cracks appearing in a productfrom themanufacturing process or from fatigue to avoid early failure of theproduct –possibly in an easy way.Material Cohesion FailureMaterial cohesionfailure can be definedin Mechanical usingcontact debonding orinterface elements tomodel for exampleadhesive failurebetween glued parts.R15.0Toward crack growth VCCT based Crackgrowth simulation isnow supported inMechanical to performdelamination basedcrack analysis.R&D is active on c rackgrowth simulation basedon XFEM and generalpurpose node releaseapproach.R15.0Importing External Data in Structural AnalysesMotivationExchange files arefrequently used totransfer quantities fromone simulation toanother.Efficient mapping ofpoint cloud data isrequired to account formisalignment, nonmatching units or scalingissues.Additional support for initial states Initial stresses (andstrains) can now beimported tointroduce residualstresses frommanufacturing orfrom a previoussimulation.R15.0Post-processingSummary table for resultsA table view of all theresults in the simulationtree is now available todisplay a text summary.This can be used to checkmultiple reaction forces atonce in a table rather thanbrowsing through eachsingle object.R15.0Post-processing Enhancements Contour plots can beaveraged across bodies in amulti-body part to displaycontinuous results when bodymaterials are the same.The visualization of resultsscoped to a body or face nowautomatically hide otherbodies are hidden (default)instead of translucent (noneed to hide parts in tree)Unaveraged Averaged R14.5R15.0R15.0Advances in Contact ModelingContact Technology Bolt Thread modeling without meshing the thread provides faster solutions while retaining a good level of accuracy.Thread characteristics are defined on thecontact region.True Thread Simulation Bolt Section Method10 times faster!R15.0my_secid = cidSECTYPE,my_secid,CONTACT,BOLT! SECDATA,Dm,P,ALPHA,N,X1,Y1,Z1,X2,Y2,Z2! where ! Dm = Mean pitch diameter, dm ! P = Pitch distance, p ! ALPHA = Half-thread angle, αVibroacousticsTechnology Enhancements Boundary Layerenhancements allows foraccurate modeling forsound flowing throughnarrow structures.Transfer Admittancematrix allows for simpleacoustic representationof complex structures eg.Perforated plates.R15.0Acoustics in MechanicalAn ACT Extension isavailable from theCustomer Portal thatexposes 3D acousticfeatures in Mechanicalwithout the need forAPDL, providing ease ofuse for acousticsanalyses.Frequency dependent propertiesFrequency dependentsupport for basicproperties (such asDensity, viscosity…),loads (impedance,velocity…) as well asperforated materialmodels are nowavailable.R15.0Uncoupled analyses Velocities from astructural harmonicanalysis may beimported on an acousticmesh to performacoustics analysis whenno strong coupling isrequired, allowing forfaster computation ofthe acoustics results.R15.0Material modelsCyclic behavior of metallic parts Accurately modeling thecyclic behavior of metallicparts for life predictionrequires to combinehardening/softening as wellas cyclic creep effects. R15implements a solution thatmixes implicit Creep withChaboche KinematicHardening.Curve fitting for thekinematic hardening is alsoavailable.R15.0Increased performance for thin SMA structuresShape Memory Alloy materials can beused for beamstructures, for fastermodeling andcomputation of thinmodels such asstents.Beam188Solid185Total Solution TimeBEAM188 : SOLID185=1:4R15.0Solver AdvancesNonlinear Adaptivity Some products in their operating conditions undergo severedeformation. Automatic mesh splitting andmorphing allow for local topology correction so that large deformations can effectively becomputed.R15.0。
Toward a Common Host Interface for Network ProcessorsAppearing in:Proceedings of the 2003IASTED International Conference on Communications,Internet,&Information Technology (CIIT),Scottsdale,Arizona,November,2003.Eric Hawkins Department of Computer Science California Polytechnic State University San Luis Obispo,CA 93407ehawkins@ Phillip L.NicoDepartment of Computer Science California Polytechnic State UniversitySan Luis Obispo,CA 93407pnico@Hugh SmithDepartment of Computer Science California Polytechnic State UniversitySan Luis Obispo,CA 93407husmith@AbstractSince their invention,network interfaces have generally been treated as special by operating systems because of their complexity and unique control requirements.In this paper we present a generic host interface through which an intelligent network interface or network processor can be managed as a simple networking device.To accomplish this,we push the complex network connection manage-ment and protocol processing code down onto the network interface.This new network processing platform is treated as a simple device by the host operating system.This model of host operating system interconnection provides for various network processor architectures to be handled identically using a well-defined kernel interface.Selection of the exact location for the kernel interface to the network processor was based on our goals to maximize the utility of the network processing platform,require no changes to existing network applications,and provide interoperability with existing network protocols (e.g.TCP,UDP).This pa-per documents the criteria and methodology used in devel-oping such a kernel interface and discusses our prototype implementation using Linux kernel modules and our own ASIC-based intelligent network interface card.Keywords:Information Systems and the Internet,Operat-ing Systems Support,intelligent NIC,network processors1IntroductionThe concept of offloading network processing from the host processor to a separate communication processor is not a new one.It has been discussed in the literature for some time,and several vendors have emerged to fill the newly created market niches for such devices.In order for such devices to be accepted into mainstream computing,however,a general interface is needed by which operating systems can offload network processing tasks to the co-Trapeze/Myrinet project[2]has shown impressive through-put across an intelligent network adapter,but it relies upon the Trapeze API to access the network adapter.Like-wise,the Nectar Communication Processor offloads pro-tocol processing as well as application specific tasks but does so through the use of the Nectarine programming in-terface which provides access to the Nectar message pass-ing facilities[1].Network processors based on the Intel I2O specifications which utilize a split-driver model to iso-late host functionality from network interface functionality are also bound to a custom API for the host-coprocessor interface[3].Since nearly all host-network processor inter-faces rely on custom APIs,the benefits of network proces-sors have not been realized on a broad scale.Incompatibil-ity with existing network software is a major impediment to the incorporation of these technologies.To address the issue of binary compatibility we have defined an interface to the network processor that works along with the socket programming interface.We have de-veloped a prototype system that uses a well-defined Linux kernel interface at the top of the protocol ing Linux kernel modules we have integrated support for the Cal Poly Intelligent Network Interface Card(CiNIC)[4] into the native Linux network protocol stack.Operations on CiNIC connections are dispatched through this interface in the host operating system to the CiNIC for protocol pro-cessing.Although the initial development has been done in Linux,the requirements and architecture of the interface can be applied to any operating system that supports the socket API.The rest of this paper is organized as follows:In Sec-tion2we discuss the requirements of the host-network pro-cessor interface.In Section3we describe the kernel level interface selection for our prototype implementation.In Section4we describe our implementation and prototype platform.In Section5we discuss directions for future work.In Section6we present conclusions from our work.2Interface RequirementsWe identified several requirements for the host-network processor interface.These requirements all stem from the primary requirement that our new OS interface be compat-ible with existing user-level interfaces so that existing pro-grams would not have to be altered.Use socket API:Since the majority of legacy network ap-plication code uses the socket API,the interface to the net-work processor must exist within the scope of socket calls. Figure1shows the traditional socket call interface.The socket API sits at the top of the network subsystem and provides user programs with an interface to the operating system’s network subsystem.The great majority of ex-isting network-based programs were written to the socket API,and so to ensure compatibility with existing programs the interface to the network processor must exist within the scope of the socket API.However,this requirement meansFigure1.Socket API and OS interface.that either the user-level socket library must be modified or support must be built into the OS.We chose the second ap-proach since OS modification is the best way to support the existing APIs and applications.Utilize native device management:The network proces-sor should be managed as a normal device by the host oper-ating system.Custom application-level code should not be required to manage the device.Rather,existing operating system support for synchronization and protection should be used.The justification for this requirement is that pro-duction operating systems use proved access management policies and procedures.With a well-designed interface to the network processor,these existing mechanisms can be utilized intact.Requiring network processors to be treated as special devices outside the scope of operating systems’existing device management facilities poses a potential se-curity and robustness risk.Look like a regular character device:To the host oper-ating system the network processor should appear to be a simple character device.The device should interact with the host operating system using a minimal number of oper-ations(open,read,write,close,etc.),and it should funda-mentally act like a simple device that raw data is written to and read from.This requirement is essential to preservingthe simplicity of the host-network processor interface.In implementation this requirement translates to locating the cleanest point at which to terminate host processing and in-voke the co-processor.Determination of the point at which this division should be made is driven by two considera-tions.First,the number of operations required for device support should be minimized in order to simplify the imple-mentation of the interface.Second,the data structures used by the operating system for network devices must be kept consistent on both the host and the co-processor with min-imum synchronization overhead.Many network related data structures are used at various points in the OS network-ing code and care must be taken to divide processing be-tween the host and co-processor such that minimal replica-tion of data is required.For example,the Linux kernel uses the socket data structure forfilesystem information such as the inode number while the sock data structure is used for socket-specific network connection information.It is nec-essary to have the sock available to the co-processor since it takes care of network processing.This requires the sock to either be replicated between the host and co-processor or available only to the co-processor.On the other hand, the socket is required by the host who takes care offilesys-tem management.However,due to interdependencies be-tween the data structures,separation of the two data struc-tures would require synchronization overhead,but replica-tion would require more.3The Socket Family InterfaceAs discussed in the previous section,the requirements for the host-network processor interface drove the design of the interface to be a kernel level modification.Several ex-isting interfaces within the Linux kernel appeared as poten-tial points to make the processing break between the host and co-processor.The host-network processor interface could be imple-mented by intercepting all socket system calls destined for network processor connections and redirecting these calls to the co-processor.The host OS’s system call table could be modified to redirect processing to functions capable of checking connections and dispatching calls appropriately. System call redirection minimizes the number of data struc-tures requiring synchronization between the host OS and network processing platform.Also,due to the high level at which the processing division is made,system call redirec-tion maximizes the amount of processing offloaded from the host to the co-processor.Unfortunately,the number of system calls and the requirement for catching all system calls makes this approach prohibitive in terms of imple-mentation and execution overhead.The mapping mech-anisms required to maintain network connections across multiple processes would also be complex and costly.Another possible OS interface is the Virtual Filesys-tem Switch(VFS).The VFS is a software layer within the kernel that handles system calls related to afilesystem.It provides a common interface to variousfilesystems through specification of the functions and data structures that must be implemented to support a particularfilesystem.The VFS seems like the natural spot to break host processing since it would allow network processor support to be im-plemented as a newfilesystem type.Operations destined for the co-processor would be redirected through the VFS interface and handled on the co-processor.However,the implementation of OS socket call handling makes the VFS an inappropriate point for interfacing to the co-processor. The primary reason for this is that not all socket process-ing proceeds through the VFS.The socketcall multiplexer is actually a parallel data path to the VFS through which network operations can alternately be invoked.For exam-ple,to receive data from a socket,an application can make a read call,which is handled by the VFS implementation of the read system call.Alternately,an application can make a recv call on a connected socket,which is handled by the socketcall multiplexer and does not interact directly with the VFS.The socket protocol family interface is a well-defined kernel interface just below the VFS layer.All socket pro-cessing converges from the VFS and socketcall multiplexer at the protocol family interface where it is dispatched to particular socket implementations.In the native network-ing code,this interface allows for the implementation of different socket types or protocol families.For example, with Internet domain sockets using the Internet Protocol (IP),this interface redirects socket processing to the set of data and operations defined for the Internet protocol family (PFCINIC,since our prototype implementation utilized the CiNIC as previously mentioned.Figure2shows the software architecture of the network processor interface us-ing the PFCINIC protocol family requires a minimal num-ber of functions to be implemented(17to be exact)due to the fact that the various possible data paths for socket op-erations converge at this point into the fundamental socket operations(e.g.create,release,connect,bind,sendmsg, recvmsg,etc).Another advantage of making the break in host pro-cessing at the protocol family interface is that it provides a low-level view of the socket based only on the kernel data structures.Integration of the socket into thefilesystem is handled by the kernel at a higher level,so all of thefilesys-tem maintenance operations such as allocating and main-tainingfile descriptors for sockets are automatically taken care of.This allows the network processor to function as a true networking device without the overhead offilesys-tem operations,which would be required if host processingNative Host Network Stack Network Processor StackFigure2.Protocol family interfacewas terminated at a higher level.The low-level view of the socket at the protocol family interface also limits the set of data structures affected by kernel operations on both the host and co-processor,providing for a clean separation of data between the host and co-processor with minimal syn-chronization requirements.Breaking the host network processing at the protocol family level allows multiple network protocols to be sup-ported by the co-processor.Protocol such as TCP/IP and UDP/IP are implemented at lower levels in the operating system,so processing destined for different types of sock-ets can proceed through the PFCINIC interface uses Linux loadable kernel modules, which are loaded prior to network processor usage much like a standard device driver.When host processing reaches the PFsocket_threads Figure4.Shared memory communication architecture.copies required for communication between the host and co-processor in our development platform.The current implementation requires data to be copied from the host to shared memory and from shared memory to the co-processor(and vice versa).Since data copy operations are a major bottleneck in network processing[7],we need to reduce the number of copy operations in order to get rea-sonable performance.However,unlike other performance-oriented research on network processors,our goal is not to enhance overall network performance,rather to pro-vide a standard interface to the network processor through which the network processor can provide various process-ing tasks.Eventually,we plan to investigate how our Linux im-plementation of the host-network processor interface ties into the structure of networking code in other operating sys-tems.We expect that other Unix implementations should coincide fairly well with the Linux implementation.The correlation to other proprietary operating systems may not be so close.We are also developing a next-generation CiNIC us-ing a FPGA design with an embedded soft-core proces-sor running Linux.This future platform will provide us with many hardware capabilities beyond that of the current Strong-ARM platform such as the ability to create auxil-iary processing blocks for special purposes.Along with development of our next-generation hardware,we plan to move from a polling communication protocol between the host and co-processor to an interrupt-driven communica-tion protocol.This approach will be facilitated by the new hardware and will relieve both the host and co-processor from supporting the busy-waiting kernel threads used in the polling protocol.6ConclusionsWe have described the implementation of a host-network processor interface that relies upon the traditional socket programming API.We implemented the interface in kernel space using loadable Linux kernel modules.The selection of the network protocol family fulfilled our design require-ments for the host-network processor interface by provid-ing a narrow point at which to terminate host processing. This interface allows network processing to proceed on the outboard platform with minimal synchronization overhead, and allows the network processor to look like a simple de-vice to the host operating system.References[1]C OOPER, E. C.,S TEENKISTE,P. A.,S ANSOM,R.D.,AND Z ILL,B.D.Protocol Implementation on the Nectar Communication Processor.In Proceedings of the SIGCOMM Symposium on Communications Ar-chitectures and Protocols(1990),ACM,pp.135–144.[2]G ALLATIN, A.,C HASE,J.,AND Y OCUM,K.Trapeze/IP:TCP/IP at near-gigabit speeds.In Proceed-ings of the USENIX’99Technical Conference(June 1999),pp.109–120.[3]G UTLEBER,J.,AND O RSINI,L.Architectural soft-ware support for processing clusters.In Proceedingsof the IEEE Int’l Conference on Cluster Computing (2000),pp.153–161.[4]H ATASHITA,J.,H ARRIS,J.,S MITH,H.,AND N ICO,P.An evaluation architecture for a network copro-cessor.In Proceedings of the2002IASTED Interna-tional Conference on Parallel and Distributed Comput-ing and Systems(PDCS)(November2002).[5]K AISERSWERTH,M.The Parallel Protocol Engine.IEEE/ACM Transactions on Networking1,6(1993), 650–663.[6]K ANAKIA,H.,AND C HERITON,D.R.The VMPnetwork adapter board(NAB):High-performance net-work communication for multiprocessors.In Proceed-ings of Sigcomm-88(1988),pp.175–187.[7]K LEINPASTE,K.,S TEENKISTE,P.,AND Z ILL,B.Software support for outboard buffering and check-summing.In Proceedings of the Conference on Ap-plications,Technologies,Architectures,and Protocols for Computer Communication(1995),pp.87–98. [8]S TEVENS,R.W.UNIX Network Programming.Pren-tice Hall,Englewood Cliffs,NJ,1990.。
