SYNCHRONOUS TORCH FIRE "MODE"

[beefy]

Hi Balazs,

this would be a great practical feature for plasma cutting. Refer this thread: posting.php?mode=edit&f=16&p=897

To switch a plasma torch on or off synchronously with motion we need to use M10/11 but that is the laser output configured to it's own output pin.

Normal operation of the plasma torch uses M3/5 which operates the output pin configured as the spindle on/off.

Could we have a "synchronous plasma fire mode" where M3/5 and M10/11 are both using the SAME OUTPUT PIN. With default cutting "mode" M3/5 operates the output, but if the user manually (or via gcode command) puts UCCNC in this "synchronous plasma fire mode", then M3 does NOT turn the output on. Only when M10 arrives then the output is switched synchronously and likewise M11 will synchronously switch it off. Of course M5 will turn of the output in any mode.

There is another situation where the user wants a normal M3 start but needs a synchronous torch off with motion (M11). Therefore this "synchronous plasma fire mode" could be enabled in the middle of a cut when the torch is already lit, then a preparatory M10 could be issued (which does nothing because the torch is already lit), but when M11 arrives the torch turns of synchronously.

However, I don't know if UCCNC can use the same output pin designated to both M3/5 and M10/11.

Keith.

[Robertspark]

+1 please, thanks

[cncdrive]

It is not possible to assign the M10/M11 to the same pin as anything else, because to make it fully syncronous this pins has to be masked out of the pins array, so they can't be used for anything else.

We could make it assignable to other things line M3/M5 only with introducing delays like it is with Mach3/4, then the M10/M11 could work with the same precision (delays) as it worked before we converted them to fully/precisely syncronous.

[Robertspark]

Does that mean a hardware solution like I posted in the other thread is the only way forward?

What sort of delays are we talking?

If we set the uc clock (motion controller) loop frequency on 400khz, does this buy us anything time wise to carry out the OR and AND gate principal internally.

Hence we still drive everything from the m10/m11 laser assigned pin, it's just the start of the motion (torch fire + arcOK wait and pierce delay) we are trying to achieve with the m3 part of the code?

[cncdrive]

It's not possible to carry out Or operation internally, this is what I'm trying to describe a few times now, because there is a logic contradiction between the sync pin and the other pins.
The working of this is not as simply as you probably think it is, there is a DMA buffer which has to be filled and then it is output directly to the pin by the DMA controller,
There is no inbetween state where this data could be further modified, so it is not possible to add an OR gate internally for the syncrounous pin, because the state of the pin has to be known and filled in prior to the time it is switched.
So, OR or AND wiring to another signal which is not syncronous to the motion buffer like M3 is not possible.

I now can't recall the time delay amount with the original M10/M11 method, it should be in the range of milliseconds, maybe ten milliseconds, but Keith could tell you more about this, because he measured this out in details and he told us that we should not have that and then we converted the working as it is now to remove the delay.
Now there is no delay at all, but with having no delay the pin can't be assigned to other things.

[shad]

I guess for this future we need additional Gcode command (for example name is M216) for disabling the spindle output synchronous with motion without motion stop.
Something like this:

Code: Select all

N3980 M03 (spindle on)
N3990 G01 X1180.0000 Y11.0000 F1000
N4000 M10 (THCON)
N4010 G01 X1180.0000 Y1499.0000 F1000
N4020 M11 (THCOFF)
N4021 M216 (Turn off spindle output)
N4030 G01 X1180.0000 Y1504.0000 F1000
N4040 M05

[cncdrive]

The spindle output is not syncronous, because it has to be executed from onscreen buttons for example even when the g-code is running.
And when code execution gets to for example an M3 because the function is not syncronous to the motion buffer the software has to wait for the buffer to empty and then can execute the command and continoue with the rest of the motion code, otherwise the M3 would not switch in the proper time when executed in a g-code code line.
If we convert the spindle to syncronous command then the same problem arrises which I described a few times now is that pins engaged for syncronous commands must be masked out, so they can't be used for anything else.

The other problem with spindle macros is that they are text macros, so their code compile on the run.
The software looks ahead and precompiles the macro though and triggers the "Run" command on it when execution gets there,
but in case the motion buffer is yet empty or only has a short motion period loaded when an M3 text macro is reached then the compiling time will overlap the motion code execution and will stop the motion,
because the buffer will run empty before the macro code compiles and will be ready for execution.

[Robertspark]

Thanks Balazs, I didn't understand it before, but I do now.

Sorry, sometimes it takes a little more explanation before us non programmers who dabble in development boards (arduino, and similar) begin to understand the motion controller hardware and whilst some of us understand the principle of them we have never and are likley to never programme one

With plasma, delay comes down to distance, I think the fastest cutting speed I've seen with hyperthem is 600in per minute.

The quickest with my powermax 45 is I think 400 inch per minute.

But I try to keep my cutting speed at under 200 inch per min, by using 30a cutting accessories and 45a cutting accessories as appropriate (acceleration limitations of a 4x4' home built belt driven table)

So... (cutting speeds)
600 ipm > 10inpSec > 15240mm/min > 254mm/sec
400 ipm > 6.67inpSec > 10160mm/min > 169mm/sec
200 ipm > 3.33inpSec > 5080mm/min > 84.6mm/sec

It's useful to consider delay in distance... hence 10miliSec could be 1" 25.4mm of travel... but at I guess average cutting speeds (250ipm at a guess) 0.4in 10.6mm which I think everyone will agree is too great....

I'll look at breadboarding my hardware solution....

[shad]

Balazs, it's only turn off spindle output pin synchronous with motion. No need to execute "M5".
All could remain as they are and controller will finish code.

[cncdrive]

Balazs, it's only turn off spindle output pin synchronous with motion. No need to execute "M5".
All could remain as they are and controller will finish code.

That is not possible is what I'm trying to describe.
If the spindle pin is engaged for syncronous switching then it could not act anymore the non syncronous way, so the spindle on/off buttons could not work then.
To turn a signal off in a syncronous way there is the M10/M11.