Anyone Actually Using External Offsets Branch for THC?

So now you have linuxcnc installed but no menu system.

Before you can run linuxcnc you need to configure the rip environment (eg set up all the paths so stuff can be found).
Open a terminal window navigate to the linuxcnc-dev folder and type this exactly as shown:
Note that there is a space between the dots. You will need to run the first line every time you open a terminal window (up arrow is your friend). I just leave the terminal window open all of the time.

The normal Chooser should open up and you are away. Just navigate to the external offset hpid sim and have a play

Rod

Thank for the reply.

I have been there and done that. Now I will have to revisit the instructions and read in detail. I will get the hpid sim running and link in as much of my hardware as needed. As usual life has thrown me a curve and I have to go to the mainland tomorrow and get propane for the cooker. How is it that every cylinder you own goes out of cert over a short time window. So not much will happen on this front tomorrow except picking up the 10-32UNF X .5 SHCS that are unobtainium on the island.

John

John, glad you remembered your bolts. Even on an island the size of Australia, I find examples of unobtainium when I try to buy bolts (I usually spend about $500 a month on bolts.)
I just posted a torch voltage sampling component which will be helpful for anyone trying this at home
forum.linuxcnc.org/plasma-laser/33795-to...e-sampling-component

Also, in the plasma and laser section (where this thread is), I have previously posted a corner lock component that works well as a velocity hold.

When I implemented the HPID example, I used both of these with hard coded values but in reality, you would control them using a GUI control (or from gcode) which if you are using sheetcam, would be the preferred method in my view.

Both of these are tested and working...

All

Just a quick update here.

Well I have the new X axis drive installed and the new Z axis mechanics. After all the fooling around moving limit switches and trippers, changed drive ratios and travel distances I have the mechanics working with my old control system. I even managed to cut some emergency pieces for an up coming trade show.

The real news is I have LinuxCNC connected and driving the table for testing now. I am still not sure what to do about the simulation for tuning the THC gains. I have cut some straight line tests and as expected the constant height cuts are good quality. Also as expected when the THC is enabled with the default gains the Z axis oscillates wildly while cutting. I think that I may add a THC gain control tab for testing to my GUI, I can do this much quicker as I understand it vs fooling with the Axis SIM.

I may get some pictures and Halscope screen shots together later today if progress is good. The X axis car and Z axis mechanics are not very nice looking right now with two sets of control cables and sensors attached.

John

Great you have got the eoffset branch working. The intent is to build a simulation that uses the same axis velocity and acceleration settings as your table actually has (eg uses the same ini settings). ie. in theory, you should be able to get a near perfect tune in the simulator you can transfer to the live table.

There is a trick to this. External offset uses a OFFSET RATIO that says how much of the acceleration and velocity is allocated to external offset control which effectively slows down the maximum speeds available with eoffsets enabled. In our application, because moving the Z axis under our (or Gcode) control and moving the Z axis under THC control are mutually exclusive. (Ie. can never happen at the same time), we set the OFFSET RATIO to 0.5 and double the true velocity and acceleration settings. That then gives our machine 100% of the speeds under both THC and gcode/jogging control. Hope you follow that as it was my idea that Dewey has fed back into the branch code.

Then with the tuning settings (mainly P,I,D), get the simulation tracking the setpoint in the sim. The implement the peturbed signal square wave and see how well (and fast it responds) to the steps without overshooting.


I would start low with P and increase it by doubling it, you will probably have to add small amounts of D as you go. Dewey says I is not useful but I found a very small amount (eg in 0.0001 increments) moved the voltage line up or down in relation to the setpoint so you could try that if you are tracking the setpoint but are offset from it (eg. parallel to it but not on it).

So when you are happy with the result, transfer your settings to your live configuration and watch the torch still oscillate wildly! That is becasue the simulated torch is still currently the unknown. eg Using your own velocities and accelerations means that the movement is not actually simulated, its what your table truly does.

I think the best tuning method of the live torch will be to set up for a long cut (full width of the table) on thick material (so the torch is moving fairly slowly to give you more time to tune). Then while cutting, try the same tuning approach you used in the sim to see if you can reduce the oscillations. That is my next step.

Finally, when tuning live cuts, your eyes should be on halscope, not the oscillations themselves....

Rod

Thanks for clarification on the simulation, I though I was to try and actually drive my machine with it.

Find attached a bunch Halscope logs of trial cuts. This seem very strange the low gain needed to get the oscillations down. They also required dgain to work at all.

The records are quite short because of the thin material I have. I have included a screen shot of THC setup.

My cutting current is 45A at a speed of 220ipm.

I'm still not sure where to go from here as I don't believe the low gains I am using are correct.

John

Lost .hal file in mix.

John

islander261 wrote:

Thanks for clarification on the simulation, I thought I was to try and actually drive my machine with it.

You were. Dewey would like us to do that as it makes it easier for others to see what is going on and to provide support.
You and I had already built a working config before adopting eoffset_pid though.

I think if I followed Dewey's paradigm from the beginning, I would have a much more streamlined system with more automatic settings as the sheetcam post we both used as a base is probably far more complex than what we need.

islander261 wrote:

Rod
My cutting current is 45A at a speed of 220ipm.

I'm still not sure where to go from here as I don't believe the low gains I am using are correct.

Were the cuts stable or was it oscillating?
It would be good to post some screen dumps of your Hal scope of a live cut. Thats what Dewey and I worked with.

Its very interesting how low your P & D settings are. This may be the reason. In your ini file, you haveThis is a key critical parameter.
This means that only 20% of the velocity and acceleration settings of your Z axis can be used by the THC to adjust the height
When we first started, Dewey was apologetic that he set it so low and suggested that it might need to be much higher, more like 0.8. But then touchoffs take forever as they are throttled back to 20% of maximum speed. So then I had an idea of setting it to 0.5 and doubling the actual velocities in the ini file so that maximum speeds were available for both the touch off and THC control could both use maximum speeds as 0.5 of 200% = 100% of available performance. This can only work becasue the THC and touch off are mutually exclusive events. Make sure you understand what I've written here and review your Z axis velocity and acceleration settings.

Now on to tuning.....
I'm going to assume you had a stable system at those low P & D terms for now.
I'm no expert with PID tuning but I think the idea is to continue to push P up (try doubling it each time) and adjusting the D to get it stable again. Once it becomes unstable and overshoots and oscillates around the set point before settling, then back off to the last stable setting. This should give a more robust system than the initial low values.

From what I did, I think velocity and (more importantly) acceleration will be key tuning parameters as well as the P,I,D terms and the provided sim allows these to be changed on the fly. In theory, we want these to be as fast as possible so we build a really responsive system so I would not change the maximum machine settings unless I was out of options.

So in answer to your question. What to do next? I think I would change OFFSET_AV_RATIO to 0.5 and see if you can get it stable again.
Then I would try slowly increasing the velocity and acceleration settings so they are 2 times what the machine is capable of and see if you can keep the system stable by changing the PID settings. At that point, I would try gradually increasing the P & D terms as discussed earlier.

Rod

Damn, I really didn't want to have to get another GUI and configuration running.

The cuts look good, but don't be fooled, the Z axis was oscillating all over the place. I guess this is a good testament about the tolerance of the HT torches to cutting height.

Ok, I am just starting to get my head wrapped around the OFFSET_AV_RATIO parameter. This may explain why it appeared that the touch offs were so slow.

I have tuned many PID servo controllers over the years. This is why am am very suspect that the basic setup I have is wrong.

I have plenty of head room to increase the axis velocity and acceleration if need be. Dewey has recommended about .2g+ for cutting corrugated steel, my present setting is .15g and I am cutting sheet that is flat to better than .25"/foot. Torch ends are expensive and I have learned the hard way about driving them into the table even with a break away mount. If the break away mount is stiff enough that the torch doesn't wiggle (technical term) when cutting then you can damage the torch in a collision, it just saves the day when the operator has a brain fart.

I posted an archive of some of the Halscope log files I took. This is a much more efficient way to transmit this information.

Yes it is always easier when you know where you are going end up when you start a journey. This will be proprietary hardware killer when someone takes the time to put it in an easy use to wrapper.

John