Sounds good.
The draw step can be reversed or stopped by deleting the group the draw is writing to, but I don't have it enclosed in an operation. I can add that in. That's the only thing that really needs to be undone; I'm not really crazy about a single undo step rewriting the CNC environment variables and outputting the gcode to a file is a single step anyway that can't be reversed short of deleting the files from the filesystem.
I made the edits you advised. Still toying with the code; after I've done some more testing I'll submit to extension warehouse.
Hi Sketchucation,
You guys helped me quite a bit last year, and after several revisions my CNC code is more or less fully functional. I never really had an interest in publishing it as it was for my own use, but if other people could benefit from it, it wouldn't be a bad idea. (It's months of work on my part and around 3,000 lines of code, including extensive unit testing.) I don't use GitHub and have just been using my Google Drive as basic version control.
The basic function of the plugin is to convert a Sketchup Group or ComponentInstance into "gcode" necessary to cut out the piece with a CNC machine. It will work with any Group or ComponentInstance that has a single flat base and I have covered all types of intersections I can think of.
Here's a gallery of the plugin in action (note that the lines are drawing the produced gcode after it has already been exported):
Discover the magic of the internet at Imgur, a community powered entertainment destination. Lift your spirits with funny jokes, trending memes, entertaining gifs, inspiring stories, viral videos, and so much more from users.
Imgur (imgur.com)
Here's a zip to the current version:
https://drive.google.com/file/d/0B22HAM7WzR-RWHluTTF5ekozdFk/edit?usp=sharing
Here's a sample of the exported gcode:
(Generated with Grays42_GPath)
(---------- HEADER ----------)
G90 (Absolute distance)
G40 (Tool Radius Compensation Off)
G20 (Inches)
G17 (All curves are in X-Y plane)
G94 (Inches per minute feed mode)
M03 (Motor on)
(---------- WORKPIECE 1 ----------)
(---------- WORKPIECE NAME; G1 ----------)
(Group x-y bounds; [6.000",4.000"],[8.000",6.000"])
(Group height; 1.000")
(Group base z; 0.000")
(--- WORKPIECE 1, PATH STACK 0 ---)
G00 X8.0940 Y6.0000 Z2.0000 F50.0000
G00 X8.0940 Y6.0000 Z0.5000
(--- WP 1, STACK 0, z0.350" -> z0.350" ---)
G01 X8.0940 Y6.0000 Z0.3500 F6.0000
G01 X8.0940 Y4.0000 Z0.3500 F30.0000
G02 X8.0000 Y3.9060 Z0.3500 I-0.0940 J-0.0000
G01 X6.0000 Y3.9060 Z0.3500
G02 X5.9060 Y4.0000 Z0.3500 I0.0000 J0.0940
G01 X5.9060 Y6.0000 Z0.3500
G02 X6.0000 Y6.0940 Z0.3500 I0.0940 J-0.0000
G01 X8.0000 Y6.0940 Z0.3500
G02 X8.0940 Y6.0000 Z0.3500 I0.0000 J-0.0940
(--- WP 1, STACK 0, z0.350" -> z0.200" ---)
G01 X8.0940 Y6.0000 Z0.3500 F6.0000
G01 X8.0940 Y4.0000 Z0.3151 F30.0000
G02 X8.0000 Y3.9060 Z0.3125 I-0.0940 J-0.0000
G01 X6.0000 Y3.9060 Z0.2776
G02 X5.9060 Y4.0000 Z0.2750 I0.0000 J0.0940
G01 X5.9060 Y6.0000 Z0.2401
G02 X6.0000 Y6.0940 Z0.2375 I0.0940 J-0.0000
G01 X8.0000 Y6.0940 Z0.2026
G02 X8.0940 Y6.0000 Z0.2000 I0.0000 J-0.0940
(--- WP 1, STACK 0, z0.200" -> z0.050" ---)
G01 X8.0940 Y6.0000 Z0.2000 F6.0000
G01 X8.0940 Y4.0000 Z0.1651 F30.0000
G02 X8.0000 Y3.9060 Z0.1625 I-0.0940 J-0.0000
G01 X6.0000 Y3.9060 Z0.1276
G02 X5.9060 Y4.0000 Z0.1250 I0.0000 J0.0940
G01 X5.9060 Y6.0000 Z0.0901
G02 X6.0000 Y6.0940 Z0.0875 I0.0940 J-0.0000
G01 X8.0000 Y6.0940 Z0.0526
G02 X8.0940 Y6.0000 Z0.0500 I0.0000 J-0.0940
(--- WP 1, STACK 0, z0.050" -> z0.050" ---)
G01 X8.0940 Y6.0000 Z0.0500 F6.0000
G01 X8.0940 Y4.0000 Z0.0500 F30.0000
G02 X8.0000 Y3.9060 Z0.0500 I-0.0940 J-0.0000
G01 X6.0000 Y3.9060 Z0.0500
G02 X5.9060 Y4.0000 Z0.0500 I0.0000 J0.0940
G01 X5.9060 Y6.0000 Z0.0500
G02 X6.0000 Y6.0940 Z0.0500 I0.0940 J-0.0000
G01 X8.0000 Y6.0940 Z0.0500
G02 X8.0940 Y6.0000 Z0.0500 I0.0000 J-0.0940
G00 X8.0940 Y6.0000 Z2.0000 F50.0000
(WORKPIECE 1 REPORT;)
(Workpiece feed distance; 38.3273 inches.)
(Workpiece seek distance; 13.5754 inches.)
(FINAL CLEANUP)
(FINAL WORK RUN REPORT;)
(Total feed distance; 38.3273 inches.)
(Total seek distance; 13.5754 inches.)
I'm posting while on lunch, so I'll follow up a bit later this evening. My question is, if I did want to go about publishing it, is there anything I need to alter in the code? Could someone who is experienced with writing and publishing plugins please take a look and offer me advice or recommendations?
As I said, I'm fine with how it works for now--it does exactly what I want it to do for my own use. This is just for anyone else who would find benefit from my work.
Thanks,
Brandon
Thank you both! I'm working on the code more later tonight, I'll try implementing that. It sounds like exactly what I was after.
Agh. Does that mean that in order to re-group the exploded ComponentInstance, I've got to pull construction information from every single bit of geometry and completely re-add them using the .add_face, .add_curve, etc. functions? That's quite a headache--are you sure there's no other way to drop them in?
The problem occurs on every single ComponentInstance; I can make a component out of two lines, and the same errors occur from the code I posted above.
I'm currently working on a workaround for now, but it would still be very useful to know how to quickly re-group; currently my workaround consists of exploding the clone and storing all of the exploded entities indefinitely until the logic is complete, then executing a cleanup routine afterward. The only problem with this approach is that I'm holding 50,000+ entities in some variables and calling .erase! on them after the whole thing is done is locking up the client for two minutes while Sketchup processes thousands of .erase! calls.
Here is what I'm trying to do in the plugin itself:
Sketchup.active_model.start_operation "Gcode Clones" selection.each do |s| if s.class == Sketchup::ComponentInstance then temp_instance = Sketchup.active_model.entities.add_instance(s.definition,s.transformation) loose_entities = temp_instance.explode parent = loose_entities[0].parent new_group = parent.entities.add_group(loose_entities) @workpiece_groups << new_group @workpieces << Workpiece.new(@environment,new_group) end end Sketchup.active_model.commit_operation
Workpiece accepts a group and does all of my complicated logic.
[edit:] Since that formatting is incredibly hard to read, here's pretty formatting of that snippet: http://i.imgur.com/Zuf2dGf.png
Problem Background/Context: Here's an example gallery of what I'm working with: http://imgur.com/a/Vfhjn
I need to perform an extremely complicated set of functions on a number of ComponentInstances that only correctly work when a piece I'm working with is flat in the X-Y plane. (They are pieces of wood I'm going to cut out.) However, the components have other axes, and in order to perform the operation I have to explode the component and re-group it. I cannot quickly rewrite the process to correctly adapt to different axes. I need to use explode/group as a workaround until I have more time to rewrite everything.
Problem: I am unable to use the existing functions to correctly explode/group. I need to be able to explode the ComponentInstance, then take all of the resulting entities and put them into a group, which I will then use with the functions I've written and delete the whole thing when I'm done.
Here's a sample of what happens if I have a single ComponentInstance selected and try to perform the operation in the command line (trimming irrelevant output).
ci = Sketchup.active_model.selection[0] #<Sketchup::ComponentInstance:0xbc75758> ents = ci.explode g = Sketchup.active_model.entities.add_group(ents) Error: #<ArgumentError: (eval):0:inadd_group': All Entities must have a common parent>`
However, I can verify that all of the exploded entities do indeed have the correct parent:
parents = {} ents.each {|ent| p = ent.parent; parents[p] = 0 unless parents.keys.include?(p); parents[p] += 1} puts parents #<Sketchup::Model:0xbca10d8>5711
That means that of 5711 entities, all of them share a parent, but I can't get it to regroup correctly.
The problem gets worse if I actually try to do the above within my plugin instead of just the command line: not only can I not group them because they "don't all share a parent", but if I check the parent immediately after exploding, it is not showing that the parent is a Model object; the parent of the exploded entities is the ComponentDefinition!
So, I'm completely stuck. I'd have to rewrite a significant bit of my code to hack it to work with just open ungrouped faces, and that would completely destroy my future plans at scaling up the capabilities of the code to work with ComponentInstances and more complicated objects. Any suggestions on how I get this particular function to work?
Oh, hell, I'm an idiot. I understand what you mean now, and I'm not sure why it took me this long.
Okay, I've rebuilt almost all of my functionality into its own class (class GcodeEdge in module Grays42_Gcode_Paths) that stores a single reference to the associated edge as an instance variable. All of the actual toolpath building is done by a container class, GcodeRoute, that stores a stack of GcodeEdges and never actually touches the edge entities themselves. Everthing works so far.
That should resolve any potential conflicts. Sorry about that.
@thomthom said:
That's a mighty interesting find! I'll try and play with that myself.
Thanks! Just remember: the real entity's base instance methods do not work even if you've retrieved the correct entity, only the mixin methods and data work. Calling something as simple as entityID on the real entity within onEraseEntity will throw an error, but if I've mixed in module functionality, all of the module's functions and variables work fine.
That's given me enough to work with that I have completely solved my cleanup problem.
@thomthom said:
I'm still concerned about extending base class. It's so many ways there can be unforeseen trouble. I'd have to say it'd have to be last resort and the names needs to be very unique. (Remember that the API could add new methods in new releases.)
... I have to say - I don't quite understand how your extend module works...
I thought one passed a module to #extend() - and the module methods could be added to the instance you extended. But you have a class within your GcodeEdge module.... ?
I'm still fumbling around with module as it is, my priority right now is to get everything to work. I'm building a pretty robust unit testing suite as I go and I test every other line or so, so if I mess up the module and break something, I'll know it. The entire point of this is for personal use, I'm not focusing on release...but I don't mind future-proofing it either, if there's a way to get what I want done.
By now we've discussed it enough that I believe you have a pretty good idea of what I'm trying to do...if you have a suggestion for a different way I should implement this so it plays nicely, I'm open to suggestions.