Something wrong

[shad]

The basic idea behind the anti-down is that CAM software's can be coded to insert the anti-down on/off macros to problematic points of the path, e.g. small circles and cross-sections.

Balazs, If CAM software can insert code to the problematic points, why turn on/off MAKROS which will be turn on/off automatic control - too much events? Just put command to enable/disable automatic height control (freeze/defreeze torch and(or) set hardware output pin). For this will be sufficient only two commands, for example M62Px/M63Px.
By the way, this commands uses in any CNC (Linux and Mach4).

M62 P- - turn on digital output synchronized with motion. The P- word specifies the digital output number.
M63 P- - turn off digital output synchronized with motion. The P- word specifies the digital output number.
The M62 & M63 commands will be queued. Subsequent commands referring to the same output number will overwrite the older settings. More than one output change can be specified by issuing more than one M62/M63 command.
The actual change of the specified outputs will happen at the beginning of the next motion command. If there is no subsequent motion command, the queued output changes won’t happen. It’s best to always program a motion G code (G0, G1, etc) right after the M62/63.

[cncdrive]

I see you thinking in the logic of your device, but you know there are THC control electronics which do not have a THC on/off input.
Especially when it comes to DIY and when the THC is built from a simple isolation and a comparator circuit.
The UCCNC can then still disable the THC, because it can do it internally.
And sure, you can do it also with M10/M11 in UCCNC just like you mentioned, but for that you need to have an enable/disable signal on your THC electronics which I'm sure you have.

[cncdrive]

And as mentioned we will add a configurable THC on/off signal, so you could use that also, but it will take some time for us to make it.
Also there was a discussion earlier where I mentioned the issue with making all outputs freely configurable for syncronous outputs,
there is a logic issue making that. In Mach3 it works with LPT port because it has direct access, but with motion controllers it is not perfectly syncronous, there are delays if used with any motion controllers (buffered motion), and with LinuxCNC it is possible, because it works directly on the port on realtime OS, however I would not trust an OS anyways that it can act realtime in any circumstances.
So, this thing is more complicated and more problematic than you probably think is.

[shad]

Balazs, I am not say about only my device. I mean that current M205/206 implementation IMHO is illogically. I am not understand why M205/206 macros enable/disable "wait for ArcOK" future? For all systems I think it's must be turn off/on automatic height control from THC inputs (for example Torch UP/DOWN signals from THC).

The UCCNC can then still disable the THC, because it can do it internally.

Please explain, what you mean when say - "disable the THC"? Wait for ArcOK or Automatic height control (torch freeze and defreeze when this commands issue) or both?

[shad]

I think I begin to understand UCCNC THC logic for macros which issue from gcode. UCCNC just execute macros for on/off THC futures. For me this is a bit illogical, because I do not see any reason to do it from the gcode. If you already have this internal thc function, why they turn on / off from gcode???
About me - still wait implementation for the THC on/off synchronized with motion commands about which you wrote above. Because in this case (disable "Wait for arcok") by M205/206 will not suitable for any external plasma THC devices.

[Robertspark]

Andrew + Balazs,

With regards to M62/M63 and Mach4 I am not aware of a single motion controller that currently can implement M62/M63 for Mach4. The Hicon maybe but the cost of that is exceptional, especially considering you pay extra for the THC function.

even darwin (Mach4 PP plugin) I do not believe implements M62/M63 when I last asked Art about it via the forum (~4 months ago)

With regards to Mach3, M10Px/M11Px, The smooth stepper could only implement 1 pin. The SS at present cannot do THC for Mach4, only mach 3 and only the ESS can do THC for mach3 (not the USBSS) .... thats why I'm here using uccnc....


For those interested in plasma + THC developments, I am aware of Texas Micro circuits who have developed in conjunction with warp9 a direct plugin module that uses the expansion port SPI for direct THC control via the interface board.... the software has taken ~1 year to develop and despite being released formally on the warp9 forum a few months ago now... they have spent the last few months sorting bugs
Unfortunately it only operates on Mach3...... another reason I'm here as I cannot undersand anyone developing anything for mach3 now!
I found a copy of the manual here
http://cnc4pc.com/Tech_Docs/Hardware%20Software%20Setup%20for%20the%20TMC3in1%201.02.pdf

Andrew, I suspect would could use direction pins on ports B&C to accomplish what you want possibly by editing the post processor to add in B and C axis motion.... its a hack and an un-nessesary one but it would probably work for your short term needs....

[cncdrive]

I think I begin to understand UCCNC THC logic for macros which issue from gcode. UCCNC just execute macros for on/off THC futures. For me this is a bit illogical, because I do not see any reason to do it from the gcode. If you already have this internal thc function, why they turn on / off from gcode???
About me - still wait implementation for the THC on/off synchronized with motion commands about which you wrote above. Because in this case (disable "Wait for arcok") by M205/206 will not suitable for any external plasma THC devices.

Unfortunately I don not understand the problem.
The M205/M206 switches the THC control on/off.
I can only compare to Mach3, because for plasma I did not use anything else to compare and in Mach3 there is also the THC on/off macro and the button codes which switches the THC on/off and when switched off then it does not wait for arcOK, because the THC control is off and if it is on then it waits (if that enable THC bla bla setting is off).
The only difference between how it works in the UCCNC compared to Mach3 is that in Mach the THC command is not perfectly syncronous, the execution waits while the g-code gets there in the code, emptying the motion buffer and then turning the THC and then continoue the motion with refilling the buffer with motion data.
In the UCCNC the only difference is that the motion does not stop for a sub-second, but the THC on/off is syncronous to the motion buffer, there is no small stop, but the command happens instantly.
Basicly the 2 systems work the same, just the UCCNC does not cause a motion stop when you switch the THC and that's all.
So, I really don't understand what the problem is?!

[cncdrive]

With regards to M62/M63 and Mach4 I am not aware of a single motion controller that currently can implement M62/M63 for Mach4. The Hicon maybe but the cost of that is exceptional, especially considering you pay extra for the THC function.

even darwin (Mach4 PP plugin) I do not believe implements M62/M63 when I last asked Art about it via the forum (~4 months ago)

Rob, I'm sure they encountered the same problem that we did.
There is some logic anomaly around this and the cause is the buffered motion which is a must and with that this issue can't be resolved or at least we could not figure out the solution and as seems others also did not, the only solution we see is how we implemented the M10/M11 is to mask out dedicated pins for syncronous control.
With Mach4 and the LPT port it would be possible probably just like it was with Mach3 with LPT, because there is direct port access, so you can toggle any pins without the buffer involved.

I would like to get some explanation from Andrew about what the issue is, because we can probably solve that, but so far I do not understand the problem.

[shad]

Thank you for reply. I wrote that I was starting to understand UCCNC THC logic. Just first time I was confused how works M205/206 commands. I hoped that these commands just turn off/on automatic height control synchronized with motion from thc inputs (in addition to antidive and antidown futures). But I was surprised that turned off the main THC wait for arc function.
If say globally, wait for ArcOK never turn off on the plasma cutting system (except only if simulation mode used and we not need to wait arcOK).
For example Mach4 currently not have THC futures and wait for ArcOK hardly inserted to the M3 macros for my system.

Rob, You right - now only HiCON has support for the M62/M63 commands in Mach4. Greg and Andy still promise to add this future in the ESS for Mach4, but.....

Balazs, it's will be great to have at least ONE hardware output for synchronized with motion Mxxx command for THC control. Also I like your antidive future, may be there is a way to connect this future to this output (OR logic, with ability to connect or disconnect antidive event to this output). We can hope for this?
Thank you!

[shad]

Balazs, please explain - if I will set command M10Q255 - it's will be 100% duty cycle similar 5v dc? If yes, I think it's will be suitable for me.