VeSys Classic Design to VeSys2/CHS migration considerations

Document created by Vincent_Pinto on Jun 18, 2010Last modified by Vincent_Pinto on Jun 24, 2010
Version 4Show Document
  • View in full screen mode

The following observations are suggested to help you pre-clean up your VeSys Classic(VC) design prior to exporting the xml for use in VeSys2(V2) or CHS. I have been able to glean these thoughts assisting a customer with their migrations.  Doing this VC upstream clean-up helps reduce downstream cleanup work in V2/CHS.


If you eventually plan to migrate your designs, these observation below help suggest how you might alter your methods right now with current designs, knowing that you will need to minimally clean-up prior to eventual migration. This document is WIP, so feel free to add you own suggestions for us to consider. I am sure VC experts will have many more.


In an effort to eventually have the software automatically do most of these, an enhancement list is posted here.   It intended to be read with what follows below.  The points below will become redundant if/when those enhancements are implemented into the software.





The following point is written in upper-case for emphasis [I am not "shouting" ;-) ].  When you are ready to migrate a VC dwg, MAKE A BACKUP OF THE ORIGINAL DWG. YOU WILL BE MAKING VERY SIGNIFICANT CHANGES TO THE COPY. MAKE A BACKUP OF THE ORIGINAL DWG.


In all that follows, in everything you do to the VSys dwg, you understand, and are working with THE COPY OF THE ORIGINAL DWG.





3.jpg1. If there are pins as connectors that are not connected to wires, erase these.  If not, they will be imported in V2/CHS and you can delete them there.  But this is a minor point, which is better handled as in 6. later.





















































2. The way VeSys works when inserting an inline pin is to retain the same wire ID on either side of the inline. This typically is not a good idea in V2/CHS where we recommend each wire be named uniquely, unless they are optioned differently.  <<Thanks, Sledge_Hammer, for your correction below.  I've done a strikethrough of the sentences above.>>


Some users may prefer to erase all inlines and insert them again in V2/CHS depending on new MCAD routing issues etc. If this is the paradigm you expect to work with in V2/CHS, manually erase each and every inline. The merged wire will get a common wire ID.

If, however, you want to retain the inlines, then I strongly recommend that you rename the wires on either side of the inline to be unique.  This is because if they are the same name, they may be interpreted to be shared, which is what we had never intended. To be sure, it is meaningless to share a wire on either side of an inline pin! Consequently, if you had a wire ID W1 which another designer had named the wires on either side of the inline, they should be renamed something to the effect of W1A and W1B. It is entirely possible, that what is now W1B (which was W1 before renaming) itself has been inlined with another connector. The original designer might have named the third wire to be W1 as well.  This third wire W1 should be renamed to W1C.  However, consider now that W1C is page-broken to a new sheet.  This will typically be part of another design, and so we do want to represent the W1C on the new sheet to be a shared wire.


3. VC allows you to instance a single device, say a motor. However, there are times you will want to create a custom Component and then insert the motor inside that custom component, possibly along with other standard VC devices all hooked up with virtual wires/links/etc inside the outline of the custom component. This works well for simulation. However, when this custom component is imported into V2/CHS, all of the internal objects will also be imported and the virtual wires will be created as wire objects. Typically, in CHS/V2 we will have represented the internals will CAnalysis models, and so we don't need explicit objects and wires "inside" the outline of the device.


Therefore, within the Outline of the Device, delete all the graphics and objects so that you are left with a device represented by empty outline.  The objects and virtual wires, etc will not be imported into VeSys2/CHS.


What was deleted will need to be represented with a Symbol to provide a graphical context.  In addition, once the CAnalysis model is attached to the symbol, you have now effectively replicated the VC situation.


This step requires careful attention which creating the symbols and the CAnalysis model. In fact, it may well be worth it to create and export blocks/dxf of the populated customComponent while in VC, and then import these dxfs into Symbol Library.


However, if you did have a device not inside a customComponent, no harm done. This suggestion is more for customComponents which have two or more instances of VC objects inserted into them.


4. The complete platform dwg is broken up into individual sheets/frames. Your design may have say 50 sheets/frames/borders, and inside each of these you eventually populate objects to complete the platform design. For the sake of ease of organization, some users may choose to place the frames horizontally. Each of these frames are typically individual designs. For example, frame 29 might contain the wiring for ABS, frame 30 might be for Transmission, and so on. However, some designs require an ECU which extends beyond the borders of the frame or the design itself is so large that you need many sheets for that one desgn. In this case, the user stacks vertically the sheets comprising that one design.


Alternatively, a customer might choose to stack the designs/sheets vertically, and the individual sheets of a given design horizontally.


However, if the xml from VC is imported into V2/CHS, we have a single diagram/single design that can contain a very large number of objects.


I suggest that you plan out which sheets will belong into designs.  For example, you might decide that sheets 1 thru 4 belong to the Power design; sheet 6 is a design by itself, say Wipers; sheets 7 thru 9 might belong to Lighting, and so on.  Make a note of this.  Even before you import the design xml, I recommend that the CHS Project preference for a diagram grid be 2.5mm per grid.  Most customer will use this grid in VeSys Classic.  Or something suitable.  Then as you create each empty diagram, your grid will be set up the way you want.


Also, important is to set in the Project preferences to use the Style Set CrossReference, and to define a suitable template for the xref in the StyleSet.


Now create a design Power, and create five sheets 1 thru 5.  Then create another design Wipers containing just one diagram say sheet 6.  A third design Lighting, containing sheets 7 thru 9, and so on.  The UI is fairly quick when working with these empty designs, although I have found that when you have created 5 diagrams and attempt to create the 6th one, the UI spped seems to slow down.  I have found it helps to close all the open diagrams.  At this point, you have all the designs you intend, with empty diagrams in the designs.


Import the VC xml into V2/CHS.  Drag select all those sheets that you intend to copy into the Power design, then press Ctrl-C to copy.  Open a diagram in the Power Design, and press Ctrl-Shift-V (Thanks, Josef Fischer) to preserve the wires and other object names.  Then go back to the main diagram, and delete what you just copied over!  Likewise, gradually copy over all the circuitry into their respective designs, making sure that you delete what you copied from the main diagram.


At this point, each design has all the circuitry that belongs to that design.  However you may now want to move the portion that belongs to say sheet 5 onto a diagram named sheet5.  Drag select the objects you want to move to a new diagram, rightclick, Move to, select the sheet, and the objects get moved over.  Eventually, after this sequence of organization, all your designs (and their diagrams within the designs) will be populated from the original main diagram you imported from the VC xml.


Next, start with the first diagram and manually share each wire object which crosses a design boundary.  Let's say I share a wire 1 which crosses from design A to design B.  When I share it in A, it simply gets shared. When I share the same-named wire in design B, I share it into the Existing object (Thanks, Josef Fischer).


5. If you had structured your dwg as an M x N array of sheets, I'd recommend if you can use the restructure them to use the horizontal or vertical layout described in 4. Just makes the work in V2/CHS easier.


6. Each of the pins as connectors in VC have been imported into V2/CHS as design-wide-objects.  Expand one of the dwo's where possible and drag the pins from adjacent dwo's to merge into a larger dwo. This is best seen in an AVI, so I will post one as soon as I can create one.


7. Where possible, you can replace the empty device rectangle with symbols that depict the internal content of the device.  You might have saved a dxf of a block while in VC, or might have manually created the symbol.  Likewise, the CAnalysis model will need to have been created and possibly attached at the symbol level.



Please add more thoughts that you think may make this manual clean-up simpler...