The thread I previously started about this matter seemed to drift onto other things so I'm starting a new thread about it.

So at present is it safe to say we don't have a way of taking advantage of the laser output for synchronous torch on/off control during motion ??

I can work out a way to accomplish this with "external intelligence" (boy that sounds hi-tech ) but first wanted to make sure I'm not wasting my time if there's a way I haven't thought of using just UCCNC as it stands.

I was going to use an attiny85 set as an OR gate, and then change its state once both pins were active to an AND gate.... would require the use of two output pins though... but I've got spare on the uc300eth

(The same thing could be done internally within uccnc if we had a checkbox telling uccnc it was setup as a plasma.... that way the code could take the shared pins and change their operating mode from an OR gate to an AND gate once both m3 and m10 were active....)

Sorry hope this isn't tainting your thread

RobEinstein ― “If you can't explain it to a six year old, you don't understand it yourself”...working my way through the 1000+ ways things don't work to find the one that doesUC400eth, UC300eth, UCCNC v1.2106, Neuron LiteUCCNC v1.2105 Macro Manual

Here's an Arduino Sketch for the ATTINY85 I've done (in the last 1/2 hr), not tested it yet, bit to add as I like some debounce + deal with timer rollover, but the general arrangement is there of my ideas for external hardware.

RobEinstein ― “If you can't explain it to a six year old, you don't understand it yourself”...working my way through the 1000+ ways things don't work to find the one that doesUC400eth, UC300eth, UCCNC v1.2106, Neuron LiteUCCNC v1.2105 Macro Manual

I started off with Arduino but then went to AVR and "normal" C. If you ever do that Atmel Studio / GCC may drive you potty when debugging (one of the reasons I left Arduino) and single stepping. The optimisation causes the single stepping to do plain weird things. I'm now looking at migrating to Codevision AVR which single steps nicely in the debugger at low optimisation.

Just a thought in case you ever move to AVR/C too. You'll also get much more compact code than what the Arduino spits out, especially if you have the compiler set at optimise for size.

RobEinstein ― “If you can't explain it to a six year old, you don't understand it yourself”...working my way through the 1000+ ways things don't work to find the one that doesUC400eth, UC300eth, UCCNC v1.2106, Neuron LiteUCCNC v1.2105 Macro Manual

If you are not very familiar with PIC microcontrollers yet then avoid the PIC32, it is a very complex microcontroller with lots of pitfalls, especially the MZ series.It was basicly designed to be programmed with modules with a software called Harmony which I would say is totally useless if you want to really understand what you doing and what is exactly happening in the micro, and programming it in C is hard because of the complexity of this micro.If you need a fast microcontroller then go with the 30F or 33F series, they are 16bits micros, not as fast as the 32 series, but is light-years easier to learn and use it.

Balazs, thank you very much for that, very much appreciated, it's just a learning journey for me

RobEinstein ― “If you can't explain it to a six year old, you don't understand it yourself”...working my way through the 1000+ ways things don't work to find the one that doesUC400eth, UC300eth, UCCNC v1.2106, Neuron LiteUCCNC v1.2105 Macro Manual

RobEinstein ― “If you can't explain it to a six year old, you don't understand it yourself”...working my way through the 1000+ ways things don't work to find the one that doesUC400eth, UC300eth, UCCNC v1.2106, Neuron LiteUCCNC v1.2105 Macro Manual

here's my take on it using a mega328p but the code will be easily modified to any other AVR.

I'm using the idea of a mode output from UCcnc (input to the AVR). Then you can use gcode (macro), plugin, screen button, etc to put the AVR in "normal" mode or "synchronous" mode where it only listens to M10/11.

Now remember, in UCCNC, loss of M3 (i.e. M5) will also take away M10. And also in UCCNC you can't have M10 without first having M3. My code takes advantage of that to simplify things. So basically if the AVR is in "synchronous" mode it's only listening to M10/11 and ignores M3.

By the way if you Google about "GOTO" in C programming there's a zillion hits about it being a bad way of programming. I haven't looked into the reasons why but I just take the clever guys word for it, got enough on my plate at the moment without hurting my brain any more.

This code is based on active high inputs and outputs so if I made this circuit I'd use "pull DOWN" resistors on the inputs. With a noisy plasma environment I prefer external pull up/down resistors that allow plenty current to give better noise immunity.

I did this code with Codevision so it's got some slight differences from Atmel Studio. I initially tried in AS but when I did the single stepping the execution went stupid as usual. I put the optimisation to off in AS then it single stepped fine but that generates really crap lengthy code and I've found sometimes it just doesn't work. I do the same code with Codevision on low optimisation and it just works. Maybe I'm thick or something but I don't know how others survive with AS.