How to use M10/M11 ??

[beefy]

Hi Rob,

here's that question for you I mentioned:

OK, to use M10 / M11 we must first issue M3 otherwise M10 just ignores us. So that brings up a situation, M3 is used to turn on the spindle relay output which is used for firing the torch. M10 is the laser output and is designated to a different output pin.

So how are you using the combo of M3 and M10. Do you have your Torch On permanently wired to the laser output and always use M10/M11 to turn the torch on and off, but just do an M3 before using M10.

Keith.

[shad]

Very interesting question.
Hmm... I realized that we can't to disable torch before end of cut from gcode without motion stopping.
Balazs, is it really hard to add M62/M63 commands? Currently M10/11 and M205/206 commands works very good or there are more differences in implementation?

[cncdrive]

Andrew,

I don't know what M62/M63 is. Could you explain?

[shad]

M62Px/M63Px - this is synchronized with motion Digital Output Control commands. We told about this commands early.

[cncdrive]

OK, I don't know in which software is this command implemented in, but in Mach3 there is M10Px and M11Px, where P is the pin number,
which is then probably the same command as this M62Px and M63Px.

As I meantioned before it is impossible to implement a syncronous switch which can be used for any pins and the reason for that is the buffered motion (motion controller).
Our M10Q/M11 is implemented with a selectable pin which is then masked out from the other pins, so that pin can't be used for anything else when configured.
If all pins could be used for syncronous output then non of the pins could be used for anything else, so it is not a solution, it can't work.

It would be only possible to implement to all pins with introducing delays, so then it would be no more perfectly syncronous anymore.
In Mach3 it is only possible with a Printer port, because then there is direct port access, so there is no buffer between the device which generates the motion and which generates the signals.
With a motion controller it can still work, but not perfectly syncronous.
We prefered to have only one sync output, but that is really syncronous then.

Also it would be possible to add more dedicated syncronous pins with again the limitation of that pin if selected for sync output then it could not be used for anything else.
I mean we could add a second and third etc. syncrounous output pin configuration, but so far we did not see any applications where that would be useful.
A laser machine requires only one laser control pin and you guys finally said that a second laser output is not needed because there is the syncronous THC on/off M205/M206 and we will add an output pin for that, we working on that currently...

[Robertspark]

M62Px/M63Px - this is synchronized with motion Digital Output Control commands. We told about this commands early.

M62Px & M63Px are for / from Mach4 (they are not documented.... in manuals) basically Mach4 does not have M10/M11 (which work the other way around in Mach3 [should anyone else be reading this] to uccnc i.e. M10 = outputOFF, M11 = outputON) .... it kind of makes sense as the second digit indicates the binary output.... (well it makes sense to me )

Keith
I presently use the same output pin for M3 + laser (m10/m11) .... but I've been having a problem with g31 of late with a uc400..... (I've not had the time to test it out in any detail so it may be me.... I'd like a small test rig next to my inside laptop..... )

[shad]

Thank you for this information! I think I understand you.
M62Px/M63Px commands now used in the LinuxCNC and Mach4. Now only HiCon motion controller has full support for this commands in the Mach4.
I just recently began to understand how the M205/M206 commands works (I mean disabling wait for arc future) and I think for external devices like proma or other Up/down driven THC the hardware output for M205/M206 is not needed. In Any case this command will enable/disable THC control inside UCCNC kernel and torch will freeze.
For full stand alone controllers M10/11 commands enough. Now I use M10/M11 and it's work perfect.
But what I like is the antidive future based on the motion acceleration/deceleration control! May be now replace M205/206 hardware output to the "antidive hardware output" and name this signal 'Corner' . I think in this case we can not use Sheetcam rules for corners, end of cut....

Also Keith, what you think about this?

[cncdrive]

But what I like is the antidive future based on the motion acceleration/deceleration control! May be now replace M205/206 hardware output to the "antidive hardware output" and name this signal 'Corner' . I think in this case we can not use Sheetcam rules for corners, end of cut....

We will make an assignable output pin for the Antidive, as mentioned we currently working on that.
What we doing is adding outputs for the THC enabled, the Anti dive active and the Anti down active signals,
these are handled in the motion controller, so the outputs will be instantly available as soon as they happen.

[cncdrive]

M62Px/M63Px commands now used in the LinuxCNC and Mach4. Now only HiCon motion controller has full support for this commands in the Mach4.

OK. So they are the same commands then as M10/M11. I have never used Mach4, only took some quick looks yet, so I did not know about this command yet.

In LinuxCNC it is probably easy to implement syncronous outputs because there is no motion buffer, the PC is the motion controller with the realtime linux kernel which I would not trust too much though as it still timed then on a PC.

In Mach3/4 there is still buffered motion, so if the HiCon motion controller handles these on any pins freely is possible, but then it is sure not fully syncronous.
We could also implement that just like we did with our Mach3 plugin, but then there can be a few milliseconds delays, unfortunately that is the limitation caused by the buffering.
With plasmas this small delay in the syncronity would be probably not a problem, not noticable, but with lasers it can be a problem and we saw the difference clearly when compared laser engraving with Mach3 and UCCNC.

So, we went the other route with the UCCNC, used a different technic to make the signals perfectly syncronisable, but with this technic the limitation is that the signal is however perfectly timed in sync, but the assigned pin has to be masked out from the other pins array, so with this technic what pins are used as sync outputs can't be decided on the fly, they must be configured prior to filling the motion buffer with data.

[Robertspark]

There are two Proma THC devices....

The Proma THC 150 (the original proma) which sends signals (ArcOK, thcUP & thcDN) back to the motion controller.
http://proma-elektronika.com/index.php/en/products/thc-torch-height-control/compact-thc-150
With this THC, M205 & M206 which are internal functions to turn the THC on and off will work and be useful. The output hardware pin is of no use. But the software (internal function) is very much needed.

And
The Proma SD which ignore the step and direct signals for the Z axis and directly drives the Z axis relative to the arc voltage + Arc Ok
http://proma-elektronika.com/index.php/en/products/thc-torch-height-control/compact-thc-sd
This one has no use for M205 & M206 ..... given there is no Z axis motion output from the motion controller during cutting motion.

[please anyone considering these, please consider others in the market and read as much as you can as you may be disappointed with their response speed and deadband, and be longing for something else in a short while].

But what I like is the antidive future based on the motion acceleration/deceleration control!

I've always thought about a tuned response (i.e automatically adjust THC response) to the blended trajectory .... but I know that the responses I was given over on the Mach3 forum was basically if the torch needs to go up.... it needs to go up now..... and if it needs to go down.... it needs to go down now.

May be now replace M205/206 hardware output to the "antidive hardware output" and name this signal 'Corner' . I think in this case we can not use Sheetcam rules for corners, end of cut....

I don't think changing it to "corner" is a good idea personally...... M205/M206 = THC on/off.... without M205/M206 how are you going to over-ride the THC on / off....
The output is really "THC hardware output control"

There are other corner THC inhibit M-codes which are:
M208/M209 - anti-dive on / antidive off (synchronous)
M210/M211 - anti down on / anti-down off (synchronous)

But I know that they are no help to you.... unless you feed their change in state of the LED's out your Ethernet connection to inhibit for corners
LED 240 - THCantidiveenabled - On when the THC anti dive function is enabled. [ok this one only toggles the anti-dive feedrate % control, i.e. feedrate below 60% or 80%, inhibit THCDn, not much use to the Neuron, given you won't know what the blended tradjectory actually is fast enough to inhibit motion relative to the target feedrate]
LED 242 - THCantidownenabled - On when the THC anti down function is enabled. [this on you could use and the latency of LED updates + ethernet should not affect it (i.e. you can use a sheetcam corner snippet to add M210 (at the start of corners / circles ~-10mm [minus = before]) and M211 (at the end of corners / circles ~+10mm [plus = after] )


Here is a bit of a suggestion..... what about kerf crossing?
I have wondered about the cnc controller software being a little more intelligent given it shows the toolpath..... is there no way for it to detect when the tool paths cross (or are in close proximity) and can toggle M210.... it's not something which affects me, but I guess if you did artwork with a plasma it may be a useful function?
[Sorry bit off topic from M10/M11, but related to the other commands denoted above]