Torch Height Control

[Guusggg]

Hi,

Recently I found about this very awesome project. I'm currently designing a plasma CNC which has been using MACH3 since forever. It works alright but there's a lot of issues that I would like to address and since I don't own the source of MACH3, my annoyances with the machine will never change. I was very excited when I found that there's 32bit boards running CNC software, even more so by learning that this project is trying to be 100% compatible with GRBL.

As a huge fan of open source projects, I would like to offer up my help for the project. I think I'll do fine in general, but I was just wondering if we could talk about some implementation specifics?

I checked out the source in a local git repo and it looks very readable and understandable. To achieve the THC functionality, I have these ideas:

• I found there is a sort of "real time" loop happening in this firmware, which is fantastic as I think that is the best way for the THC functionality to run. I'm thinking about implementing the THC loop in protocol_exec_rt_system(). Or would a better place be in protocol_execute_overrides()?
• For detection of the voltage of the Plasma Cutter, I want to use a single pin that will be analog read from to determine the voltage of the cutter. I'm not completely sure, but for a microcontroller with 38 pins, there has to be one pin that is free and can be read from analog? Is there certain logic to choose a pin? Can I see somewhere which pins are in use by the firmware already?
• I have a plasma cutter that has a voltage divider of 50, to get in the range of 0v - 6v. This means I have to divide another time by 2 to get to 3v so the ESP32 can read it without magic smoke appearing.
• I want to communicate the currently read voltage from the microcontroller to the interface. I assume I need to use the serial connection for this, but what would be the best way to implement this? Should I create a custom command on the GRBL protocol? It doesn't need to be 1000 times per second but maybe like 10 or 20 times per second.

I've read through the project ArduinoTHC at https://github.com/regeg/ArdunioTHC and I don't see why I would not be able to combine these two projects together. I have a lot of experience in programming, but I'm an beginner in the world of electronics.

Please tell me if my assumptions are wrong and I appreciate all other (asked or unasked) advice!

Edit: I'm using this board: https://www.makerfr.com/en/cnc/grbl-32bits-board-v2/

[bdring]

THC has been on the wish list for a long time. It is a big project and we are too busy with basic stuff, support and implementing version 3 of the WebUI. It is unlikely we would be able to help too much on this at the beginning.

I would suggest researching the the most popular low cost THC modules to see what output they use. We would want to support that. The ESP32 ADC is not very good. If you want a full open source THC, you might make a module that does some of that work and presents itself like a commercial module to the ESP32.

I think an interesting way that might work is similar to the feedrate override system. That loop probably runs fast enough to do the job and is tightly integrated with the planner, buffer and other internal systems. You will still want the Z to do normal things like homing and probing.

I suggest joining the Discord server and starting a thread. Please join and DM me.

[MitchBradley]

To amplify what Bart said about the ESP32 ADC not being very good:

1. It has a fair bit of nonlinearity at the ends. That can be calibrated out.
2. It has a lot of noise that can be averaged out by oversampling and filtering.
3. From time to time it tends to give a few sample values that are wildly incorrect, as if there is a voltage shift somewhere in the silicon based on other activity in the very-complex system-on-chip. Those bad values are very difficult to handle with normal linear noise reduction math.

There are threads about this on the internet where people complain bitterly, and nobody has yet come up with a good solution for 3 - short of averaging over a ridiculously long interval.

Based on the fact that the ESP32 ADC is effective unusable, it makes sense to add an external ADC. Considering that you can get a small microprocessor with a good ADC for less than a dollar, the system solution that appeals to me is make an external module that does the real time thinking about the plasma, and sends Z height modification commands back to the ESP32 over I2C or serial.

[eccle]

Also interested in THC we are using a modified 6 pack controller with an additional espp32 to run this controller https://openbuilds.com/builds/standalone-torch-height-controller-for-cnc-plasma-cutting.9571/ we are using a 2 input multiplexer to handover Z axis control from the 6 pack to the THC. Still working out the bugs.

[imechura]

Some feedback from someone who has developed and implemented a few torch height controllers.

When implementing a THC, you must be very careful not just of the voltage but of the current. Many plasma systems do not come with a CNC output/control board. Many people work around this by tapping into the raw voltage with a 50:1 voltage divider because its a fairly easy concept to implement. What people often fail to understand is the need for full galvanic isolation between the plasma system and the THC/CNC controller else the current will eventually seek ground through the ADC input pin. Implementing this level of isolation is far from trivial and requires many trade offs to be considered in the design of such a device. Failing to implement the galvanic isolation in this scenario will lead to many burned up smoking dev modules, burned wires, fires and potentially injury to the operator. Please take this into consideration.

On another note, the cnc controllers I have worked with on plasma systems do not include THCs. THCs are typically implemented as external modules for the reason I described above and others such as locating the module local to the plasma cutter to reduce line noise, etc. I think you would end up creating a separate piece of hardware to handle the isolation/noise issues anyways so then you might as well implement the THC externally as well.

BTW, I am very impressed with the work y'all have done on this project. Thanks for all of it. If you have any more questions on the implementation (hardware/software) of THCs, please feel free to reach out to me.

[MitchBradley]

+1 for external THC control.

[Guusggg]

Hi guys,

Currently I have a prototype of the ESP32 communicating with an Arduino NANO as a sort of test, using the TwoWire protocol. I want to be able to replace the Arduino NANO later for a dedicated Analog To Digital converter and I figured ADC's would be able to support that using TwoWire. The loop runs in it's own part of the realtime functionality of GRBL and currently, by modifiying the pulse_func to override the Z_AXIS when a flag is turned on, will override the Z_AXIS to move, even though it was not told to by GRBL.

I haven't tested this on a real plasma table so far, I'm currently modifying one of our tables to be able to develop on it. The tests I run are with the Arduino NANO connected to a potentiometer to simulate the voltage going up and down which works alright, although I hope to be able to bring in real world results in a few weeks.

Thank you everyone for the helpful comments, and sorry for not directly responding to them right now. Currently I don't have too much knowledge on the subject, so I keep this thread around but I'm unable to respond in depth yet.

[imechura]

I suspect that you are over simplyfing the process of voltage based torch height control which is understandable because there is not much information available in the subject.

I also began the process with a very simplistic view of how the same could be achieved but what I ended up doing in the long run is as follows:

I have the PULSE and DIR signals for the z-axis drive run through a set of relays. When your THC received the OK-MOVE signal from the plasma cutter then you can activate the relays so that the signals to the x-axis drive now comes from the THC instead of from the CNC controller. This scheme works well with the G38.2 probe command steps to perform the initial height sensing process. here is what it looks like from a high level.

1.move to position

2. 38.2 probe command
3. G92 Z0 to set z-axis zero-floating torch offset
4. G0 to Pierce height
5. M03 / plasma start signal
6. wait until OK-MOVE command
7. now THC is commanding z-axis drive in a PID-like manner
8. M05
9. move command = 0
10. THC resets the zaxis position
11. return z-axis control to the CNC controller.

these steps are automated in a post processing script that came with Sheetcam and mostly worked out of the box. It uses variables from the sheet cam dialog boxes to fill in most of the needed info, like pierce height, cut height etc.

And do not underestimate the cost and complexity involved in isolating that high voltage/high current analog signal from your precision digital electronics. it's not an optional thing. if you skip that step it will work fine right up to the point where it doesn't and then you will be replacing all of the electronics in your setup, starting over from scratch, and possibly getting yourself a new laptop as well.

So you can do all that... or you can buy a THC off the shelf for $150-$350 and be done with it. If you like the idea of having to figure out, through trial and error deep details about a topic that no one else that you meet will ever know or understand then it makes sense to continue down the path of building your own torch height controller.

not sure I would want to unlearn what I learned but definitely am planning to buy one next time I need one.

On Fri, Mar 25, 2022, 10:01 AM Guus Geurkink @.***> wrote:

Hi guys,

Currently I have a prototype of the ESP32 communicating with an Arduino NANO as a sort of test, using the TwoWire protocol. I want to be able to replace the Arduino NANO later for a dedicated Analog To Digital converter and I figured ADC's would be able to support that using TwoWire. The loop runs in it's own part of the realtime functionality of GRBL and currently, by modifiying the pulse_func to override the Z_AXIS when a flag is turned on, will override the Z_AXIS to move, even though it was not told to by GRBL.

I haven't tested this on a real plasma table so far, I'm currently modifying one of our tables to be able to develop on it. The tests I run are with the Arduino NANO connected to a potentiometer to simulate the voltage going up and down which works alright, although I hope to be able to bring in real world results in a few weeks.

Thank you everyone for the helpful comments, and sorry for not directly responding to them right now. Currently I don't have too much knowledge on the subject, so I keep this thread around but I'm unable to respond in depth yet.

— Reply to this email directly, view it on GitHub https://github.com/bdring/FluidNC/issues/310#issuecomment-1079115780, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABA4JFZ4A2LL3JUP367SY3VBXIMHANCNFSM5O6UWXYA . You are receiving this because you commented.Message ID: @.***>

[bdring]

Closing. This is on our long term dec list.

[Guusggg]

Just wanna note that I have proof of concept here on my own table, it's not complete yet and not tested thoroughly. It's based on a Arduino functioning as the THC with some integration to the ESP32 using TwoWire. I'll upload the code as soon as it's quality is enough to release it, and we might be able to develop it further within this community.

[chron0]

@Guusggg I'd really love to see that going forward since THC seems like a really essential feature to work properly with plasma.

[Guusggg]

@chron0 Hi, we are able to use the second Arduino effectively as THControl, we are rigorously testing at the moment so I expect to be able to show off some work in the next few weeks. I'm currently not working on the project myself, as I have other matters to attend to but in a few months, I'll be back on this full time. Meanwhile someone else is developing this further, so I expect a lot of clean up to make this into something that the community can use.

One more thing I want to do before releasing, is actually implementing some features in FluidNC in regards to the current voltage read, the nominal voltage and reporting the status of the THC to FluidNC. I expect this to take a little longer, as I don't have a lot of experience communicating between two micro controllers

[chron0]

@guusggg very much looking forward to see your results, as this is my current barrier to invest into a plasma cutter and run it with fluidnc.

[MitchBradley]

Don't hold your breath. It will be some time before FluidNC supports plasma machines properly, and it is not particularly near the top of our todo list.

[wgroenewold]

@Guusggg Do I understand correctly that you use the Arduino implementation of @HaleDesign to control the Z-axis and FluidNC to control the X and Y axis with no communication between the both? How did that work out and would you be interested to team-up to make communication between the both possible?

[Guusggg]

@wgroenewold Hi,

For our machine we proceeded by making our own THC design, integrated into the circuit where the ESP resides. It just an Arduino with DIR and STEP connected from FluidNC, which passes these ports through when not in use. The THC can run completely without FluidNC, but at the moment I'm developing a very simple (optional) protocol over 2Wire so that the THC can communicate how much voltage it reads (as I want to display that in a FluidNC dashboard). I want to expand this protocol to be able to configure the THC program, and maybe communicate the Z height. The hardware is all there right now, I just need to implement the FluidNC part reading the data and outputting it somewhere the dashboard can access it.

It's all still pretty experimental because I don't have a ton of experience with microcontrollers. I have a ton of experience developing games and software, so I'm not fearful of large codebases. I can probably tell you more in about two weeks as I'm drenched in work at the moment.

I plan to open source all my code related to this and I will create a pull request to get the protocol into FluidNC, although it might take a little while since I can only work a day or two per week on this and most of my time is consumed by figuring out peculiarities of microcontrollers

[wgroenewold]

@Guusggg Cool. I've got already some experience in programming MCU's and would love to review your work, but if you create a feature branch in FluidNC we can team up early in the process. I'm currently working on my hardware setup and will do the software afterwards so two weeks seems like a perfect timing for me. Do whatever floats your boat, but know that I am happy to help out.

[Tigeruno]

I have fluidNC on my RongFU 30 mill and built another controller for plasma table (JDsGarage DIY build). I am attempting to use High Frequency Plasma (Amigo CTS-180). Can cut continuous from first cut, but locks up when stepping to another cut after turning plasma off. USB must start over.

Anyways, very interested in THC. I am nearly finished with the Z axis which will allow setting torch height after touch off (probeing). But I suspect THC will be the answer. I am familiar with I2C and the MCUs but weak on programming. Thanks for the great work on this open source program.