Rods "Spaceship" Scratch built Plasma Cutter build

PCW wrote:

The THCADs rise time is less then 0.5 ms. A 5 ms risetime would be detrimental to loop tuning. Of course any post direct data
filtering will affect the loop bandwidth.

Peter that is awesome thanks. You have no idea how long I spent trying to test this and capture a plot like that for Dewey in a very crude way. Looks like we should have just asked you!

In Dewey's simulated torch (hal file) in his HPID sim, he uses a lowpass filter with a cutoff frequency. Based on 5ms he said it should be around 70 Hz (you've already helped me with that. Now I just need to know what to change it to now to simulate the torch.
github.com/LinuxCNC/linuxcnc/blob/dgarr/...et_pid/sim_torch.hal
Any input would be appreciated.

With relation to the voltage range, the THCAD range can be scaled using an external resistor. Initially I scaled it to cover a 20 volt range, What I found is that the THCAD sees the Everlast's resistor divider network as part of this external resistance. From memory, this changes the scaling by a factor of 1.5x so it becomes a 24:1 divider (240 volts) so there is heaps of headroom so I removed the external resistor.The only time I've seen the volts go past about 130 is when I deliberately engineered a kerf crossing test off the edge of a sheet.... One more headache I had to find and deal with during this build.

I did some more test cutting yesterday but would you believe a prox sensor on the Z axis home switch failed? Should they be protected with a current limiting diode? If so what value for a 24v system?

I think I have a spare here and I've ordered some more. This is the second I've had fail.

I think the new coupling made a bit of a difference but the changed velocity means retuning. Here's a couple of plots with similar PID settings
The other day (old coupling)

Yesterday (new coupling)


I wanted to play with the eoffset scaling factor but my home switch said that was not to be!

tecno wrote:

Possible to use a simple voltage divider with suitable resistors as a pre divider?

Yes, I believe so as thats what the everlast board is but I'm not sure if they do anything with the raw voltage as it comes onto the board. But if you don't have a divider already, use the THCAD-300 mounted on or in your plasma machine.

Grotius wrote:

Tecno is right. Use a hypertherm powermax 45 xp with internal voltage divider .
Optional order one with modbuss interface. I called hypertherm too late this day. But maybe rod is
better of with a powermax to make some progress. I have sayed before i sponsor, it depends on free shipping
to australia...

Hmm, the closest Hypertherm office is Singapore. Maybe they could ship from there and I could pay you for the freight? We only have dealers here in Australia but it would be OK to have it shipped to one of them where I live in Brisbane.

I'm still working through all of the comments made last night. You guys were very active in another time zone!

robertspark wrote:

Hypertherm modbus is not for THC / reading the torch voltage (it is WAY TOO slow)....

The modbus protocol used on the Hypertherm 45XP RS485 interface does not publish torch volts and only allows us to set amps and pressure and read some status messages. This in itself is not particularly useful on the 45XP. However, the 45XP would be an affordable testbed to build and test the beginnings of a communications channel for the larger Hypertherm high definition plasma machines. One day, I would like to experiment with communicating to a Hypertherm machine using Mesa hardware to see if that is actually possible. If you can talk to the 45XP, I am sure the interface can be expanded to talk to some of the high end machines.

rodw wrote:

... high end machines.

such as?

The same communication protocol works on all plasma air systems (Powermax, except older / smaller than the 45XP). If you had a high definition setup, why would you change from hypertherm software setup (such as the phoenix )
www.hypertherm.com/en-US/phoenix-software/?region=NART

I don't think linuxcnc would be able to create a better cut which is after all what its all about, (including for the mix of: as quick as possible and with maximum consumable life)

I'm not actively using linuxcnc (too many other hobby projects needing attention), but it seems like because of the potential to be able to adjust everything with linux, you (users in general, no one specific) seem to then end up spending most of the time under the bonnet (I have various small board computers too {Raspberry Pi 3, Tinkerboard, Tinkerboard S, Odroid XU4, Beaglebone Green}), seems at some point you need to get the point of saying "..it'll do!" and move on to the next pressing thing.

As most of the discussion is over THC and out of bounds axis motion, what do you see as your current issues that your THC setup cannot overcome. Is it not able to follow at high or low speed, or the inability to be able to tune for many states (i.e. you tune it for high speed and the low speed goes to pot etc). Why not add in a current feedrate parameter to act as a filter to slow the speed of THC response to avoid oscillation. After all if your cutting feedate is 300ipm, the voltage signal should only be changing at a lower rate than 600ipm, and the THC correction should be acting at a corresponding rate (afterall most cuts are on flat plate, with minor rise / fall).

Cut logs in my view should include, sample time, current feedrate, z-axis dro/machine co-ords, and the sensed voltage, with a header / title showing the amperage, material, thickness, etc. And maybe an indicator of if the THC+anti-dive lockout was a active during the log.

That way if you log at various feedrates then it may be possible to interpolate the data for a large range of applications.

tommylight wrote:

I wrote on another thread (or this one, maybe) just roughly what it takes to control cutting current on plasma cutters from Linuxcnc, i have plenty of them (3 mine) so i can make some detailed tutorials, although i do not like to make tutorials about stuff that can kill people with a single mistake. Plasma cutters are inherently dangerous as should be treated with a lot of respect, working inside them is extremely dangerous as the use high voltages on all sides.
If anyone is interested, let me know.

I'd be interested. Many things can kill or others, it is just another risk that users need to consider or make for themselves. {I do everything on my own cars, I'd say the risk is higher there of causing injury, or death to ones self or more importantly others, as well as many many other things I do, mig, tig, arc welding, lpg systems, gas welding, electrical works, inverters / VFD's etc} The most dangerous thing is no information or poor / wrong information. If someone has decided to do something {lets face it ... you'd need a plasma cutter first!} then an ambition to take the covers off, you take responsibility when you take the covers off at that point anyway for your own actions.

Tommy, thanks for your input as always.

Robert, I was thinking of one of these when I referred to high end machines
www.hypertherm.com/hypertherm/hyperforma...erformance-hpr130xd/
I know for a fact that many of these machines are deployed by plasma table manufacturers without using the Hypertherm controller but none of them will be using Mach3 or LinuxCNC. Here is a local manufacturer I've visited that has installations in shipyards all around the world:
www.advancedrobotic.com/
But you can see, these machines are not entry level CNC machines. Windows based controller of their own design.

I can't see why Linuxcnc can't do as good a job as these machines. After all, Islander261 is already on record as saying his Linuxcnc table is performing better than his previous commercial software.

I agree with you that at some stage, I need to make this table work. But the fact of the matter is that one of the LinuxCNC developers put a lot of time and effort into a software module which should do plasma THC very well while I was working on my table. So I decided to adopt this experiment. The developer Dewey then spent a lot of time and effort educating me about how to use it. My feedback then went back into improving his algorithm. So far I have not got it working but I feel I have an obligation to persevere until I have no more options to explore. I have not had a lot of time to devote to this and have been thwarted by my lack of understanding of the environment and a few hardware issues which have disillusioned me from time to time.

As Tommy (and others) have pointed out, there are other methods to do plasma with Linuxcnc but they have missing features. There are a few of us who are working on developing a fully complete THC internal to Linuxcnc. Each of us have our own views but we do collaborate. We think that that internal approach will exceed the performance of any external CNC. A couple now have good success.

I've also allowed myself to get distracted by writing a number of components to support basic THC functionality. Torch voltage sampling and corner lock are the two most important ones to help me manage the testing I've done.

So when I exhaust the external offsets branch (and there is only one more thing I can think of to test), I would have a working system in a couple of days either by borrowing another working experimental config or by going a more conventional known good route.

However, in the meantime, I have gathered a lot of data to help understand the torch voltage behaviour which I hope will eventually pay off..

So the limitation for my THC is really the limitations of the experimental external offsets branch and its included PID component and my own lack of knowledge. Those that have reported success have used the Linuxcnc PID component which is more sophisticated than the one I am using, The other constraints could be the external offsets method of applying adjustment using a count as is done with a MPG jog wheel.

As far as logging data goes, screen dumps from Linuxcnc's included halscope tell most of the picture to those who understand the Linuxncnc environment and the signals that are shown. Its still not as good as being able to evaluate a live capture in halscope itself. All of the items with the exception of amperage and material can be logged in halscope. It is possible to pixel count to establish a scale for the screen dumps.

Finally, with what I know now, I don't think a whole series of cuts are required to calibrate for a new material. From what I've learnt, I think I could do that with a single 6" long cut while Linuxcnc logged key data at 1000 times a second for subsequent analysis.

I hope I have answered most of your questions.

Don't think I've ever said linuxcnc does not work with THC or plasma, just always seems a long setup process plus a lot of fiddling. (I'm considering it for turning as I've got an old CNC lathe to upgrade)

Linux is always considered to be a highly configurable OS, just the time it can take for you to get it the way you want it plus understand what you need to do can be a long road. (...under the bonnet / hood time...)