See ComponentReporter++, CutList etc for examples of CSV export... There are also several similar tools that allow you to choose a folder/filename with UI.openPanel. You can insert a consistently named CSV into an Excel XLS and format it, any changes in the CSV are updated in the XLS... If you structure your CSV logically so that the data in each line is readable then exporting it back into another Ruby should be relatively straightforward... So, for example you have a face that's exported, list its corner vertex xyz positions, layer, layer_name, attributes etc etc. When you import it you dread it line by line, the first field of the CSV tells you its a 'face', so then you expect vertex-positions so read those, turning them into numbers with to_f, each set of three of these gives a point [x,y,z], next when you get to a field called 'layer' you know the point sets are done and the next point will be a layer-name etc etc... face=entities,add_face(points_array) face.layer=layer_name etc etc

Then I put these guides on a separate layer whose visibility you can turn off any time. Guides are handy for other reasons, too, as their visibility can be toggled on/off in the View menu globally as well as you can delete all construction geometry (when finished and they are not needed any more) in the whole model from the Edit menu (although keeping them on a separate layers can always be better as you may need to revise your model later) That gives me an idea, I could add something (on a separate layer) to aid the layout process and turn off that layer later.... [attachment=3:756gjb1f]<!-- ia3 -->PanelsWithGuides.png<!-- ia3 -->[/attachment:756gjb1f] Still not sure if this is what you need however... [/quote] (One hour later) Brilliant! The simplest things are always the best! The ovals are on their own layer for final presentation, etc. Check out the .skp, works best in Front View. Thank you! It would be interesting to be able to prevent a surface from passing through another, make it literally solid. Perhaps in Version 12. [image: ppOR_panels_registrationpoints.jpg] panels_registrationpoints.skp

@whit said: I may be going about this all wrong, but I'm trying to make something very specific. What I want is: to generate copies of a component which land in the model on the same plane as the original and equally spaced apart. I see how to do the stretch function, but I need individual copies, in AutoCad it is the array function. Can you point me in the right direction? I think what you want is to add 'Position' attributes X and Y and define them based on the 'Copy' variable. Attached is an example that creates columns and rows of a fixed size solar panel by scaling the frame that wraps around it. X and Y for each copy of the panel are defined as follows: X=solar_array!frameThick+(rowXLenX) Y=solar_array!frameThick+(rowYLenY) 'rowX' and 'rowY' are custom attributes of the panel, defined as follows (note use of 'Copy'): rowX=FLOOR(Copy/solar_array!numY) rowY=Copy-(rowX*solar_array!numY) 'numY' (and 'numX', which is not used here for positioning) are computed at the top level of the component hierarchy, along with the exact dimensions of the surrounding frame, based on the number of panels that will fit within the re-scaled frame (by dragging its edges): LenX=CEILING((current("LenX")-(2frameThick))/sun_power305_single_crystalline!LenX)sun_power305_single_crystalline!LenX+(2frameThick) LenY=CEILING((current("LenY")-(2frameThick))/sun_power305_single_crystalline!LenY)sun_power305_single_crystalline!LenY+(2frameThick) And some code to make sure the minimum size contains one panel (not zero!). I now frequently use DCs like this instead of move/copy; there are advantages. Solar array will scale in two dimensions by replicating a single panel as needed.