Help with external offsets on a Real Plasma machine

Hi guys, I've finally got my plasma running and am ready to get Dewey's external offset pid controlled Torch Height controller working. But I've hit a bit of a wall as this short video shows. You see the eoffset_pid and the external offsets never becomes active.

If you watch the 15 second video, you will see the Z axis move up and down during touch off then move to pierce height of 4.0mm before dropping to 1.8mm cut height.



You will see the a,b,c enables come on and then the enable-out becomes active but you never see the component become active.

Any help would be really appreciated. I think this might be the first plasma machine using this experimental code so all help would be appreciated.

Thanks Andy. Dewey and John have given me a bit of a way forward so I'll see where it goes from here and report back. Thats the trouble with plasma. Everything happens very quickly!

As it turned out I had missed a critical ini file setting. Thanks to Dewey for helping. Once I added that, it worked perfectly.

Andy I'm sorry, if you thought the last video was too quick, there is only 3 seconds of cutting in this one before the torch crashed into the material.

Anyway for me, the most important thing was that the Z axis moved under THC control but clearly it is far too responsive.



I'm hoping it won't take long from here. Dewey's shared the relevant docs so I've got some homework to do.

Hi Rodw,

Can i have a look in your hal file's? Or files that connect your machine?
Any help how you connected the machine in real life to external offsets would be great !
First i want to test on the parport.

Later this morning, I'll dig something out. I've just got some courier deadlines to meet first. ( I just gotta find a cup of tea first as I just gout out of bed!

Hi Rodw,

Thanks, please don't hurry. It would be great if external offsets is working on real machine. I did the simulation and it looks very impressive. If it works over here, i will try to make a document how to set things up. When i look into the file's its for me at this moment a big puzzle to make things clear and understand how it is exactly working. What i don't understand is how the gremlin screen is updated. With the normal offset.component it would be pretty nice if this was also possible to visualise the current offset.

What i see is that the thcud.component has changed in time. Big john has made a simulator in the past. This comp file that can be downloaded is completer then the current thcud.comp file. Within the current thcud file the current-offset is deleted within the code, but parameter is still available, so this is very confusing. You think you do something wrong. But function is not available.

Maybe i can compare the offset branche in a later stadium with the adaptive feed version. The both functions are working. That would be a goal i want to make with linuxcnc.

Yesterday i had an idea about simple torch height control.
If we use a fake joint. For example joint 8. We can use this joint for primary z axis command input.
It will always follow the z g-code program lines in theory. So that is a good start.

Then we add a offset.component on top of joint 8 and make the real z axis joint (in my cast joint 2) going to float with real offset graphics. Or am i thinking not the right way?

Here a mind example how i think it could work :

Hmm, it might take a bit longer than I first thought. I remembered that Dewey added a deadband at my suggestion after I read that it was pretty much required for PID based motor control. I have yet to add that in to my config. I think it would be best if I incorporate that into my config before posting anything publically here. So I will recompile the Linuxcnc external offsets branch to make sure its 100% up to date and tidy my config up first.

The first few days of the month is pretty busy for me so give me a few days.

I think I'm going to get right back into this plasma config. My laser cutter supplier has stuffed up the machining on a small component for the second time in a row (500 parts and counting). I am thinking of buying a Hypertherm 45 XP becasue I think it will improve cut quality on the 8mm parts and do them in house.

Hi Rodw,

I will ask hypertherm tomorrow if they can sent you a xp45. I am at the moment only working with thermal dynamics ultra cut.
Hypertherm has issues going on. For example look at copy parts : www.borte.com.cn/weldingcutting.php?id=303
If you want cut quality, just add a ultracut 100 amps. Then you are master kenobi in your garage.

Grotius wrote:

Hi Rodw,

I will ask hypertherm tomorrow if they can sent you a xp45. I am at the moment only working with thermal dynamics ultra cut.
Hypertherm has issues going on. For example look at copy parts : www.borte.com.cn/weldingcutting.php?id=303
If you want cut quality, just add a ultracut 100 amps. Then you are master kenobi in your garage.

Wow, a very generous offer! Thank you. Send me an email by the forum if you need more info.

Attached is a minimalist config for a working external offset system based on a Mesa 7i76e and a Mesa THCAD-10 voltage to frequency daughter card. This config adheres to the developer's notes on how to move the sim to a working system

The working .ini file to run is called hpid_mm_rod.ini
The rest of the config is a copy of the hpid sim that ships with the external offsets branch so everything in the sim is there at your fingertips so its easy to drop back into the sim to review stuff.

As many of the tuning aids used by the sim as I could open on my live system are opened at run time so you can test and tune in a live environment.

the external offset hpid sim uses a fake touchoff.ngc to simulate a real touchoff routine. The real one that uses probing and a floating head I wrote is in hpid_probe_touchoff.ngc

hpid_touchoff.ngc does a simulated touch off so you can test without cutting.

I've added the source to 3 components in a folder under a config. Install these with
halcompile --install thiccomponent.comp

[bcornerlock.comp][/b] is not used in this config but I've included it as it allows the corner lock velocity (0-1.0) to be set using a screen control. In this config, we send the corner lock velocity and corner lock speed in gcode for simplicity as mentioned in the main .hal file (hpid_spaceship.hal):

scalethcad.comp is a helper component that makes it easier to set up the various parameters so you get accurate voltage readings back from the THCAD10. You will not use this if you are using other methods to rad the torch voltage.

torchsample.comp is used to sample the torch voltage and set the commanded voltage to be exactly what is read a certain delay after ArcOK is returned from the plasma cutter. This is hard coded to be 1.5 seconds as I found that was a good setting for both 8mm and 2mm plate steel. I would strongly recommend you implement this.

Finally, hpid_plasma.hal is used to unlik some of the standard signals and set the zo.deadband. 2.1 volts will probably need changing I have done NO cutting with a deadband enabled. Any configuration to the hpid component (named zo in the default hpid. config). Any changes to the zo component must be made in this file not your main hal file.

When setting this up, please take the time to first use the default config as I have done and do not change the main hpid.hal file that is hidden away in the LInuxCNC internals. This will allow Dewey to support you when it goes pear shaped.

From my own testing, I would say that we have tried to get the PID as responsive as possible by maximising velocities and accellerations. Whilst the PID theory says this is the way to go, I'm yet to be convinced. However, I am hoping the implementation of the deadband will substantially dampen the Z axis offset behaviour.

I have quite a complex estop setup and also have some cool warning lights. I also have a remote pendant. It was easier to cut and paste the supporting hal code into this config than to trim it down to a minimalist config. Sorry about that.

Basically, start with a copy of the hpid sim nad cut and paste your ini file settings in place of the sim config thenb work through your hal file to just insert the barest minimum to get this working.

Once you have a tuned system, migrate your learnings to your new GUI. Take it from me, it will be worth doing it this way and will be quicker in the long run.

Good luck. A few people have tried this code now and most have had problems so I'll be very interested to see how you go as you have so much more knowledge than others.