Sheetcam and trying to generate spotting gcode.
28 Apr 2021 05:02 #207288
by rodw
Funny that you've been wrong all these years and your PP has worked perfectly for me all that time.
Replied by rodw on topic Sheetcam and trying to generate spotting gcode.
I read the thread on the sheetcam forum and saw that my pp is wrong so to cover my butt I have removed it.
Funny that you've been wrong all these years and your PP has worked perfectly for me all that time.
Please Log in or Create an account to join the conversation.
28 Apr 2021 12:24 - 28 Apr 2021 12:24 #207302
by rodw
Possibly but I don't think so as my guess is the magic comments are parsed in the python filter that processes the gcode.
When Gcode communicates with plasmac non-real time components (Like the feed rate), it does a M66 and waits for Plasmac to acknowledge the tool change. Because it uses a sequential search, with a lot of tools, I found I had to increase the Q parameter or it timed out in a similar way.
In fact, use of the feedrate pin was a kludge because Linuxcnc's motion controller had no knowledge of the feedrate set in gcode at run time so there was no reference velocity available for velocity antidive. In v2.9 with the inclusion of state tags, the motion.feed-upm pin (ref linuxcnc.org/docs/devel/html/man/man9/motion.9.html) could be used for VAD if Plasmac altered its behaviour. If this change was done in Plasmac, sheetcam could set the feedrate itself which would be much more efficient.
Pehaps you could convince Phill to make this change in V 2.9
Replied by rodw on topic Sheetcam and trying to generate spotting gcode.
[
I got an error loading the magic comment version about it taking too long. But I don't think thats a post issue.
Does this have anything to do with M66 P3 L3 Q2? The magic comment version does not use this.
Possibly but I don't think so as my guess is the magic comments are parsed in the python filter that processes the gcode.
When Gcode communicates with plasmac non-real time components (Like the feed rate), it does a M66 and waits for Plasmac to acknowledge the tool change. Because it uses a sequential search, with a lot of tools, I found I had to increase the Q parameter or it timed out in a similar way.
In fact, use of the feedrate pin was a kludge because Linuxcnc's motion controller had no knowledge of the feedrate set in gcode at run time so there was no reference velocity available for velocity antidive. In v2.9 with the inclusion of state tags, the motion.feed-upm pin (ref linuxcnc.org/docs/devel/html/man/man9/motion.9.html) could be used for VAD if Plasmac altered its behaviour. If this change was done in Plasmac, sheetcam could set the feedrate itself which would be much more efficient.
Pehaps you could convince Phill to make this change in V 2.9
Please Log in or Create an account to join the conversation.
29 Apr 2021 02:55 #207348
by rodw
This is the error I'm getting on loading the file with magic comments
Using the post above
which does:
Replied by rodw on topic Sheetcam and trying to generate spotting gcode.
I found the result from when we tested this some time back, with 500 materials the maximum time to change was 0.16 seconds. I don't "think" anything has changed in the meantime.
This is the error I'm getting on loading the file with magic comments
Using the post above
which does:
;begin material setup
T0 M6 (select plasma tool)
G43 H0 (apply tool offsets)
(o=0, ph=4.1, pd=0, ch=4.1, fr=100, pe=0.5)
F#<_hal[plasmac.cut-feed-rate]>
;end material setupPlease Log in or Create an account to join the conversation.
Moderators: snowgoer540
Time to create page: 0.122 seconds