I looked at this a bit. This is what I understood from the DressUpHoldingTags:
-The additional move to 0,0,0 comes because for creating the tags, the Path "G-code" commands are transformed to a wire object representing the Path. (by PathGeom.wireForPath() )
-Because the Path object does know anything about what happens before it, it has to assume some starting position of the first edge and it seems to assume 0,0,0.
-After the tags are done and the wire is transformed back to "G-codes", the initial wire from 0,0,0 to the actual starting position gets included.
An idea I got was to modify the PathGeom.wireForPath() so that it does not generate anything additional. Instead it should create edges only after it is 100% sure about the actual position. For example a path:
Code: Select all
G1 Z-1 F100
With the current implementation, the first edge would be generated from (0,0,0) to (0,0,5) and then from (0,0,5) to (10,10,5). What I did was I changed the wireForPath() so that the first edge would be from (10,10,5) to (10,10,-1) because that is the first edge which can be said for sure where it actually is (G-Code modality sucks in that sense
) The function also returns the commands which are ignored from the beginning. Now the holding tags are generated normally. When generating commands from the wire, the initially ignored commands are returned back to the beginning of the path.
I got it to work with my very limited test case. But the solution smells lika a disgusting hack to me.
Any better ideas?