M10 / M11 FOR SYNCHRONOUS TORCH ON/OFF

[Robertspark]

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.

Why? ... M10/M11 is the laser output.... synchronous with motion (i.e. only active when movement is present), I may be wrong (won't be the first / last time) but the two are not related (although we are trying to make them related to make use of arcOK if M205 is active.

By the way if you Google about "GOTO" in C programming there's a zillion hits about it being a bad way of programming.

.... forget about C to a point, microprocessor does not really read c, code is interprited (to assembly) and compiled.

hence the "goto" just ends up being a jump statement in assembly when you decompile the hex file (that was interesting).... [still learning at Atmel Studio there is probably a way I've not looked for, stumbled upon or found to read the assembly from an interprited c project yet]..... installed AVR Simulator in demo (just ran it the once, looks interesting, you get 30 sessions of 1hr in demo, it was just interesting to look at).

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.

Yeah, I did think about that, but it's a quick change in the code, and I was looking at a THC interface board at the same time too [it's only been breadboarded as yet, and I wanted to add a bit more to the circuit board so that I've just got one board with a reed relay for torch on, plus direct interface with the uc300, so I'll probably put a 26in IDC connector on the circuit board, but would like to circuit up the other I/O's too as it would be a waste of an output [bit more work to do hardware wise for me]

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.

Not used codevision, only just started using AS, expert at neither. are you running the licenced / free version? I'll have a look this evening.

[beefy]

Hi Rob,

I have forgot the exact reasoning why M10 laser output will not come on without first issuing M3 but that is the way UCcnc is programmed. I've also mentioned about it in this thread:
viewtopic.php?f=2&t=65
So they are inter-related in the sense that if M3 is not active you can't have M10. It's some sort of safety feature I believe. So the sequence is (taking out the other gcode that would be present):
M3 Spindle output on
M10 Laser output on
M11 Laser output off.......BUT if you do M5 before M11 then the laser output will turn off anyway.
That's why I went the "mode" way and added the extra input to the AVR programming. Your AVR can just "ignore" the M3 if the "synchronous mode" input is active.

Regarding what you said:
"although we are trying to make them related to make use of arcOK if M205 is active".
You've lost me on that one and I'm not sure what you are saying. M10 cannot wait for Arc OK otherwise it won't be synchronous. To use M10 you'd have to turn off THC (M206) so that motion is allowed without Arc OK. Then issue M3. Then depending on WHERE/WHEN you'd want to fire the torch synchronously, either issue M10 before XY moves, or issue M10 just after XY moves started. Shortly after that (but allowing enough time/XY distance for the Arc OK signal to be present) you'd enable THC (M205), by which time Arc OK would be present. If the torch had misfired when the M10 was issued then you would not have the Arc OK signal and when THC is turned on, motion will stop.

As for the GOTO statement I am only repeating what the top AVR programming guys are saying. Like I said I don't know the reasoning behind it but after seeing your code today I remembered lots of bad things said about programming in C (including the AVR) and using the GOTO statement. Just passing that info on, not condemning your coding. Like I say you can check out the reasons why on Google and AVR Freaks.

Just using the evaluation version of Codevision, which is fully featured but size limited. I think what I'd really like is Imagecraft which has it's own simulator but it costs a lot more than Codevision and you only get a full working evaluation for a few weeks. Heck I could go a few weeks without touching an AVR.
AVR Freaks have info on dealing with the optimisation issue in AS but I feel I shouldn't need to become and expert at assembly language just to work out what and why my optimised code is doing weird things. The simple code I've just submitted for example, in the if/else blocks the code would endlessly loop inside the bracketed blocks so I was perpetually stuck in the block and I couldn't simulate different inputs. And the top guys on AVR Freaks always say never compile your code with optimisation off, so you just can't win LOL.

With Codevision I set the compiler to speed (vs size) and the lowest optimisation level. I do the coding in the actual CV IDE but bring the .COF file into Atmel Studio for simulation and final programming of the AVR. I'm no expert but that seems to be what is working reliably for me.

Keith.