Summary: Inventor Routed System to AutoCad Electrical Integration

Description: The issue is BOM “connectivity” and/or "associativity" between ACE (AutoCad Electrical) and Inventor Routed Systems. Autodesk claims this feature is there but, at best, only works on wiring to common pin/contact numbers. Otherwise it is only one way and doing anything more than wire and pin numbers that don't include their component data takes a lot of external data manipulation in Excel or Access in conjunction with feeding results into and out of both the parent programs.

To be the kind of collaborative useful tool it claims to be, the communication between the two programs needs to be bi-directional and based on a part reference designator and while it starts with the associated pins/contacts and wiring, it must include all pertinent BOM data as well. When the two packages (ACE and IRS) are used together, layout in ACE should be nothing more than a reference for the Electrical designer and/or a place for the mechanical designer to start. If ACE is used stand alone what is there is fine but in the collaborative design environment where controls and mechanical systems are being developed on parallel paths the current situation is an impediment to digital prototyping NOT and advantage.

In standard machine design or the complex product environments I have worked in, physical component placement, size, system cooling requirements, member part list complexity, and many other physical criteria such as internal and external interconnects and/or actuation, need for proximity to other components and alternate vendors/components combine to make fully modeling controls an integral part of the design. Control components are fully modeled inside the product or inside control cabinets as their mounting, actuation and cooling are all part of how they interface with the user's world. Especially in the machine design world things like sensors, heaters, actuators, motors, switches and so on are selected in mechanical design but are an integral part of the electrical and control schema. As things are now this requires the BOM in both InventorRS and Acad-E to be completely redundant for the vast majority of control system components as all these parts are modeled in Inventor and in Inventors BOM because they are an integral part of the mechanical design. Because of the complexity of the systems we typically try to control the entire product or machine BOM in Inventor then export that to an ERP. (ERP integration is a secondary issue but in most cases one of the upper tier Vault products or a competitive PDM/PLM are used for this.) We use AutoCad Electrical for all the control component connections, schematic and logic design but as a physical layout tool it is all but useless at the level of complexity we deal with; that work must be done on Inventor in 3d and often with CFD for cooling. Accordingly the Inventor platform, driven by the system's physical layout, component size and interconnect requirements usually drives final component selection even though the component functionality and schematic specification are driven by ACE. Unfortunately ACE is set up to drive its own BOM and has no good provision to work with or interface with Inventor to address an iterative process of component selection based on the physical requirements Inventor lets us analyze and address. These things must be bidirectional in a machine or complex product design environment.

Recently there has been a long discussion on this topic on the LinkedIn AutoDesk Inventor forum Will SWX do it again? <http://www.linkedin.com/news?viewArticle=&articleID=5571963736677154884&gid=130938&type=member&item=93231909&articleURL=http%3A%2F%2Fwww%2Elinkedin%2Ecom%2Fgroups%2FWill-Solid-Works-do-it-2464910%2ES%2E93178022%3Fqid%3D30172e2e-049d-4253-a612-584c7a7db8a5%25> and an older discussion on the same topic was Does anyone Interface electrical schematics with Inventor Mechanical Drawings? <http://www.linkedin.com/groupItem?view=&gid=130938&type=member&item=78797310&trk=group_search_item_list-0-b-ttl&goback=%2Egna_130938>

In a nutshell what we need is full "associativity" Acad-E and Inventor RS. Think about the following scenario in either products or machines. However, here is a real life example from some of my large machine design as an example. Working on large machine control panels, we design the boxes to hold the components and to do so end up with virtually every component modeled including the wiring. The layouts which were done in the 2d world of ACE most often don't fit in the 3d world modeled with Inventor. So the mechanical designer will find a suitable replacement components, get it approved by the EE and work from there. Often the Reference Designator (ex. K13) remains the same but contact numbers change and certainly all the BOM data changes; of course that means all the stuff in ACE (including schematic contact numbers) changes too. Once we get this far we manually reconcile the two systems (of course, manual processes are both error prone and take hours from at least 2 experts to do, but it does get done). As the iteration goes on, we now get a design change because that relay is no longer large enough to handle the load and the new one EE specifies is physically different and again contact numbers and BOM's are affected. In the iterative environment of collaborative design on a large system this can happen hundreds of times and changes can be originated by either side of the team yet it is ONE team. Why is the data in TWO systems? In the more sophisticated environments the BOM is directly imported into the ERP (or similar) system for Production Control to work with; why should this have to be done twice and why should a company have to buy two post processors to accommodate this? The engineers are one group using two tools, why don't the two tools work in harmony instead of a situation where having two tools creates chaos?



Product & Feature: Inventor

Submitted: Sun, 19 Feb 2012