Another plasma component...

phillc54 wrote: pl7192,
Yes, that is the intention. It just needs a bit of a tidy up and some better documentation before that happens.

Just to clarify, once tidied up, this will be part of the current master branch so it will be available from buildbot without needing to compile anything.

Phill, I updated my config today and the configurator was flawless. I just navigated to the configurator script, and it was perfect even when I had some custom code that needed hand edits in earlier versions. And I have red and green buttons again! Can't wait to play with the new gcode features.

I am not here, but anyway
Did a quick browse through the documentation and found this
M67 E3 P0 would set the velocity to 40% of requested speed
M67 E3 P40 would set the velocity to 40% of requested speed.
M67 E3 P60 would set the velocity to 60% of requested speed.
M67 E3 P100 would set the velocity to 40% of requested speed

Regards

I have a question about program flow :

M67 E3 Q0 sets the velocity to 100%
M67 E3 Q10 sets the velocity to 10%
M67 E3 Q50 sets the velocity to 50%
M67 E3 Q100 sets the velocity to 100%

Doc's info:
M67 - set an analog output synchronized with motion.
E- - output number ranging from 0 to 3.
Q- - is the value to set (set to 0 to turn off).

The number of I/O can be increased by using the num_dio or num_aio parameter when loading the motion controller. See the Motion Section for more information., oke this is nice to know.

Question :
Is this calculated back into the component? Or maybe i miss something here. Is there a short program flow available how i can understand the interpretation of the M67 codes. So far i think. The M67 values are predifined at program load, are they corrected and calculated real time during program execution?

My opinion :
When the I and J value's of small circles below 50mm (real time user input) are read into the component during cutting. The adaptive speed can do a 75% job (real time user input). Then you are independent of using M-codes, unless the M3 and M5.

Grotius wrote: I have a question about program flow :

M67 E3 Q0 sets the velocity to 100%
M67 E3 Q10 sets the velocity to 10%
M67 E3 Q50 sets the velocity to 50%
M67 E3 Q100 sets the velocity to 100%

Doc's info:
M67 - set an analog output synchronized with motion.
E- - output number ranging from 0 to 3.
Q- - is the value to set (set to 0 to turn off).

The number of I/O can be increased by using the num_dio or num_aio parameter when loading the motion controller. See the Motion Section for more information., oke this is nice to know.

Question :
Is this calculated back into the component? Or maybe i miss something here. Is there a short program flow available how i can understand the interpretation of the M67 codes. So far i think. The M67 values are predifined at program load, are they corrected and calculated real time during program execution?

My opinion :
When the I and J value's of small circles below 50mm (real time user input) are read into the component during cutting. The adaptive speed can do a 75% job (real time user input). Then you are independent of using M-codes, unless the M3 and M5.

I have not had time to implement this yet as I only updated Plasmac yesterday but motion.analog-out-03 is connected to the motion.adaptive-feed pin. So if adaptive feed is enabled with M52, then Will set the speed to 75% of the feedrate.

So from here, if you create a Sheetcam code snippet called "Slow 75% with that code and another one called "Slow Off"with
So then create similar "Slow 80%", "Slow 60%" etc snippets, you can create a Sheetcam Cutting rule that progressively applies this to different hole sizes as per an earlier example screen dump I posted on this thread. I think the problem may arise how to turn off the reduced speed as the Sheetcam cutting rule can't turn this off as there is no "After Arc" rule. It might be possible to add a M67 E3 Q1.0 in the Sheetcam onMove() method to reset the speed to 100%. I'll go back to Les Newell at Sheetcam and see what he can come up with.

@Rod,

Thanks for your explanation !

To make a linux code snipped, instead of a Sheetcam code snipped, it's maybe easy to read in g-code lines into the component as a character.

Then the component fragment's out some I and J value's trough the c coded string manipulation.

And it has real time behaviour at once, just what we expect it is supposed to do !

If there is interest i can write some code coming time for this.

Poor old Phill will never get to build his machine.. He is already parsing the gcode looking for invalid toolsets so now he needs to look for arcs as well!

Actually, Sheetcam has an onArc() method which by default calculates the radius, so it could be done without the code snippets very easilly.. I still have an idea to try to do it in real time via a component.