Torch height control for Plasma - just playing around

[MeJasonT]

Hi Gerrit,

Still using this fantastic app, hope all is well with you. I have been playing around with the possibility of using a virtual serial port and another arduino to inject commands into the stack whilst a job is running. The virtual serial port does let me send commands which GRBL responds to http://eterlogic.com/Products.VSPE.html The port that GRBL is connected to is split to a virtual port which accept RX/TX from both GRBL GUI and at present Arduino terminal at the same time. I have not written and THC code yet, just sending raw G-code commands ie. G1 Z0.06, G1 Z0 etc. Took me a while to realise i couldn't just send Z2 as a command like i can from Grbl panel command window. I'm still getting G Code command errors (as expected) when its in the middle of an arc command and i decide to correct the height. Im currently messing with poll speed and stack size to see if i can find a happy medium instead of overflowing the stack. The plan is to build a diy capacitance sensor or use an industrial optical sensor for setting the target depth.
Another method of sensing could be a divider circuit measuring the plasma arc voltage as used in the pro controllers. I have both a disadvantage and an advantage, the disadvantage is the plasma cutter is a cut 50 from china and not a Lincoln with dedicated output connector for a torch height controller. But, i have a relay which is connecting the table earth to the plasma torch tip to turn the cutting head into a pilot arc head instead of the HF scratch start which it is. So as if by magic the relay terminals can be used to measure the plasma output between the tip and earth. That's where my heads at anyways.

The signal will then be fed into a second arduino and a coded PID loop, the output sent out as a G-code Z command correction. To initialise and disable the THC I thought that I would monitor the comms and look for M3/M5 commands. Im looking for inspiration and advice. I think the advice may be something along the lines of stop wasting time, the command structure of GRBL wont appreciate you sticking commands in here and there.

It all sounds possible and easy But... watch this space or look for a large plume of smoke on the horizon, it may not be the North Koreans.

[gerritv]

This sounds very interesting!

I remember using a plasma cutter to make aluminum panels for a race car underbody. Very interesting devices. Cutting by hand so had to learn to support my cutting hand to keep the distance constant.

I wonder if you would be best to connect GrblPanel to your PID device and not directly to Grbl. That device could then inject codes into the stream at appropriate time and send It on to Grbl itself? You would have to eat the Ok response for that extra command, pass everything else back to GrblPanel? That way you are not trying to guess when to inject your codes. The comms path would look like: GrblPanel <-> YourDevice <-> Grbl.

[MeJasonT]

I realised after sending the post that what i wanted to do wasn't going to work unless commands could be sent to GRBL-panel to inject into the buffer/stack in a timely manner. The second arduino/micro has to be the right solution and i think it is easier to do as you suggest. My line of thought is to Break into the circuit after Grbl and before the stepper driver now, OR listen to TTL/serial commands and when the M3/M5 command is sent the 2nd Arduino/sniffer can then take control of the step and direction commands. i will need a delay after an M5 command in the Gcode/job so that the second arduino finishes with the THC and hands back control of the Z axis to GRBL. I would probably need help from Sonny to understand how to receive the step pwm signal and pass it through under one condition or bypass and inject moves in the other condition. Iv'e got the basics of the arduino PWM but its nothing like the speed and complexity of the code used to drive the GRBL machine axis. I know enough about programming to realise that using the pre-built sketches are not the same as efficient direct code, i can do one but not the other. If i write some code that uses the adafruit pwm sketch then i'm leaving myself open to ridicule, nothing new there.

[MeJasonT]

Ps. Ive not heard too much about the new GRBL platform on the super duper fantastic processors.

[gerritv]

There are too many not-really-code-related issues being raised on Gnea, distracting Sonny from what we are all most interested in :-) But he is working on the ARM version.

[gerritv]

BTW my suggestion was to intercept GrblPanels gcode data (not the Step/Dir signals) before it gets to Grbl. You would either pass the line on as-is or inject what you need based on the height sensor. Just replacing the Z value is not difficult. Any data coming from Grbl would be passed unaltered back to GrblPanel. Fairly straight forward serial buffering and a bit of parsing.