Moveback on arclost and THC on/off state

[beefy]

Reverse run can't be done now, because we working on other things and that would require lots of changes in code which we can't do now, because we don't want to mess up the software core code with doing so many changes in the codes the same time. What we could do now is minor changes or additions and this is not something like that unfortunately.

Apologies Balazs,

I think you did mention that before. Guess I got a bit excited when Andrew started talking about mid cut restarts.

Bit of ambitious thinking but I'm hoping I can delve into the depths of gcode and the 4 quadrants of a circle (arcs & IJ stuff) so I can automatically create my own mid cut restart gcode. Nothing like a good bit of trigonometry on a weekend

[Robertspark]

Does anybody know how.reverse run works in mach3?
(Code wise)

Linear motion i can understand how to do it.

G03 g03.... I'm at a loss, as you will need to use XY from the previous line, and offset new ij from previous ij allowing for the offset relative to the previous line XY and use g03 for g02 and visa versa

And if someone has use the motion as modal... Complexity increase as you will need to reverse trawl the previous lines to fing the last modal motion controller

Feedrate could be ignored as you could use the jog feedrate to do the reverse run...

I've tried searching for various things in the hope of finding a macro or some code and am at a loss for some example code that could be ported to c# plus uccnc

[Robertspark]

Andrew please do not use M10/M11 for AVC for the neuron.

Please use m205/m206 for AVC (which is the on/off anyway...) If you are going to use it within the neuron plugin

I am trying to use M10/M11 for sync torch control so that I can turn the torch off on the fly via a high speed torch on/off circuit external to the neuron

[beefy]

Andrew please do not use M10/M11 for AVC for the neuron.

Please use m205/m206 for AVC (which is the on/off anyway...) If you are going to use it within the neuron plugin

I am trying to use M10/M11 for sync torch control so that I can turn the torch off on the fly via a high speed torch on/off circuit external to the neuron

+1000

Andrew the M10/11 is meant for synchronous control of laser during motion, but instead I will be using it for synchronous control of plasma torch on/off during motion.

I've recently bought your Neuron Lite and have built my control board with a microcontroller and high speed relay added for using M10/11. I asked you about the Neuron synchronous torch operation during motion and you asked me for more information. I then explained to you the reasons and usefulness in plasma cutting for synchronous operation of the torch, but I got no reply after that. I believe the Neuron has no way of doing this so had to come up with my own external solution to "trick" the Neuron.

M10/11 is the closest built in function in UCCNC to synchronous torch operation, so I hope you won't change that. I would not have bought the Neuron if I thought the M10/11 function built into UCCNC will be taken away from us.

[shad]

Guys do not worry. You can use any command for this, because the hardware THCOFF input of the controller is used and it does not matter which command you activate it with. The plugin does not know anything about this too.

Balazs, I think we still need one more synchronous digital output control command Please think about this and we will not torture you anymore.
Thank you!

[Robertspark]

Andrew we have 3 or 4 don't we each with access to a defined port and pin that you can use as they will have no effect on the neuron
M10/11
M205/206
M209/210
M211/212
(From memory.... I may have got the numbers wrong.....)

What about doing what linuxcnc do?
M62 Px.....
http://linuxcnc.org/docs/html/gcode/m-c ... de:m62-m65

Mach3 does M11 Px... Too but it only works with the parallel port like that,.. all motion controllers only have one pin

[cncdrive]

Rob,

I'm not sure where in which thread did we discuss this earlier, but this was discussed some time ago somewhere on this forum, I just can't locate it now,
but it is not possible to make all outputs available as motion syncronous outputs like M62 Px... like how it is mentioned in the document you linked.
The reason why there is maximum only one sync output in motion controllers is because the data is buffered and so it is only possible to make outputs precisely syncronous with the motion buffer is if that output is masked out from all other activity. And so this means that if we want to use all as sync outputs then all outputs have to be masked out which means that the outputs could not be used for anything else than motion sync output functionality and so the whole system would not work anymore.
With a parallel port it is possible to do all outputs motion syncronous because there is no motion buffer in between, but direct access to the port pins.
It should be also noted that doing one syncronous output eats up about the same amount of communication bandwidth and resources as controlling one axis.

So, we could add more dedicated motion syncronous outputs, like adding a second and third etc. outputs, but to make it generic with giving N number of outputs where N equals the number of outputs of the motion controller is not possible, because that would require the resources of controlling N axis which is 36 in case of for example the UC300ETH-5LPT, because it has 36 outputs.
It is also not possible, because the output then has to be masked out prior to a sync switch command occuring, in other words the controller has to know before the command occurs that it will occur which is also not possible to implement.
I think adding a 2nd and even a 3rd sync output could be done just like it is done with the laser sync output with preconfiguring a port/pin number for the output, I mean then those additional pins configured could be masked out just like the laser pin now and it would probably not require excessive amount of resources if talking about the ethernet controllers. For the USB controller the 1 sync output is already too much, the C axis already has to be turned off in the USB controllers if the sync output is used, because there is already not enough data bandwidth to throughput the 6 axis data + 1 sync output data.

[Robertspark]

Balazs,

For me 4 outputs are enough that can be toggled {I was just pointing out the way that LinuxCNC does it}

I'm not sure what andrew is trying to do with using more than that?

If he is trying to control many cnc things on the cnc table {laser, plasma, oxy/acetylene} then I would run the 4 synchronous outputs through relays which are toggled when changing between each tool..... you then have an infinate number of possiblities available then...

[Robertspark]

For me 4 outputs are enough that can be toggled

more correctly known as a demultiplexer circuit

https://tams.informatik.uni-hamburg.de/ ... demux.html

https://tams.informatik.uni-hamburg.de/ ... -demux.gif

[shad]

Balazs, I think one more synchronous digital output will be enough.
I'll try to clarify: need a digital output that could be controlled by commands from the gcode. Like M205/206.
Just we can't use M205/M206, because moveback on arc lost future does not work when THCOFF.
And we can't use M209/M210, M211/M212, because this macros just enable/disable antidive and antidown futures, but not digital output directly.