FPGA (field programmable gate array) programmed for linuxcnc motion

islander261 wrote: While I am still running my plasma table on an external offsets build I am not using any of the features for torch height control. I am actually planning on moving back to the straight master branch next week when I get some time. I never could get good THC using the external offsets branch and the eoffset_pid component. Right now I am using hal components to build a THC solution that works far better than the commercial system I have ever did.

I am a bit confused by this. The external offsets branch ought to be a better way to apply the offsets, even if your HAL components setup is a better way to calculate the offsets. Using External-Offfsets also should guarantee that the machine stays within the travel and velocity/accel limits.

If you are finding that an alternative way to apply the offsets is working better then perhaps you have not set up the external-offsets limits optimally?

Andy,

I think a few of us have given the external offsets a good workout for plasma (3 I know of) and we could never get it to get good control of the torch height. The best I could get was when Dewey had missed something with metric v's imperial and we had some settings out by a factor of 25.4. (I seem to remember you thought it was running like a drunken sailor) Dewey has since added a deadband to his hpid component at my suggestion but I've been lazy (or busy) and have not tested it. I feel a bit guilty becasue Dewey has put so much work into helping me understand such a complex subject and taking my feedback and putting it back into the eoffsets branch.

Anyway, maybe this weekend as I've got a bit of a lull for a change.

I still think you might be erroneously conflating how the offsets are calculated and how they are applied.

andypugh wrote: I still think you might be erroneously conflating how the offsets are calculated and how they are applied.

I don't think the work I did contained config errors
The eoffset-pid component Dewey wrote is a HAL Lib component that the user does not touch it or its connections
github.com/LinuxCNC/linuxcnc/blob/dgarr/...nts/eoffset_pid.comp

The config I was using was based on Deweys. hpid_mm.ini sim
github.com/LinuxCNC/linuxcnc/tree/dgarr/..._offsets/eoffset_pid

All my setup was in accordance with the documentation Dewey wrote.

I think its more of a case that we don't fully understand torch voltage behaviour and also from what Islander261 has done indicated that any additional filtering of torch voltage whether it is done in hardware or software, introduces delays into the signal which caused tracking problems for him. He spent a lot of effort optimising his physical plasma environment to achieve maximum signal response..

Its always been assumed that there is a linear relationship between torch height and voltage. One test I did with a very limited data set indicated that the torch voltage was a 3rd order polynomial as this graph shows with a 95% confidence level



The next step is to use halsampler to collect a much bigger dataset with a gcode program that initially probes the test area to account for surface irregularities and then does a single cut at varying height over about 150mm. Then load the cut data and the probe data into a spreadsheet, adjust Z height with probe data and repeat the regression analysis with a few thousand data points and see if the trend is confirmed.

So with this graph, applying a deadband around the plateau makes sense.

If the plateau is confirmed, it will be a good way to determine ideal cut height on a given material with a single cut as it will be in the centre of the plateau.

So that is todays' task if nothing goes wrong.

Hi

I really want to have a fresh go at the EO branch. The last commit I have is several months old now. How do I get a version that current to the 2.8.1-pre version?

I have to generally agree that for THC work the EO branch and eoffest_pid component should in theory work well. I just have never been able to get it to work well. I am willing to give it another try because it takes care of the following error problems you have with other approaches.

John

Well, it seems I shot my earlier theory down in flames. I used Halsampler to capture about 9200 readings and plotted the results. (Torch height in mm vs torch voltage.)
.

You can see the torch voltage is linear across a large height range. But at least I know that my plasma cutter changes at the rate of 7.53 volts per mm. There are about 450 readings per reading in 0.05mm increments from 1.5mm to 2.45mm

rodw wrote:

andypugh wrote: I still think you might be erroneously conflating how the offsets are calculated and how they are applied.

I don't think the work I did contained config errors
The eoffset-pid component Dewey wrote is a HAL Lib component that the user does not touch it or its connections
github.com/LinuxCNC/linuxcnc/blob/dgarr/...nts/eoffset_pid.comp

Yes, but, eoffset_pid isn't the External_Offsets branch. External_Offsets adds extra HAL pins that allow you to apply an external offset to any axis.

I have used it on my lathe to do things

this

Regardless of whether eoffset_pid (which is a HAL component that could be used with any branch) gives the correct THC behaviour I think that the External_Offsets branch is the correct way to _apply_ external offsets even if eoffset_pid isn't the optimum way to calculate those offsets.

If you have a bunch of HAL that works well to calculate the required offset then I think that you should probably use that as the input to the external_offset pins.

Andy, correct but eoffset_pid is only distributed as part of the external offsets branch as it depends on it and it was envisaged as a standard mechanism to use the external offsets for torch height control.

Islander261 used the external offsets exactly as you suggested and it was working quite nicely for him. So I think what you are saying that the eoffset_pid algorithm is probably the road block, not external offsets itself. eoffset_pid contains its own PID routine so I'm now wondering if it can't be revised to use an external LinuxCNC PID which is more sophisticated.

Regardless I am going to give it one more go. I realised I need to redo my live config as the latest eoffset_pid example has changed since I built it. I don't think its anything significant, but the configuration methodology in the ini has changed to make it cleaner and easier to configure.

It would be nice if the external offsets branch was rebased to master again. It seems the last time was back in February and there are a few enhancements in master branch we'd like to be able to use.

Rod

Thanks for putting in the time to put the arc voltage linearity question to bed.

All

I think that the most of the THCs that operate successfully actually generate a velocity command from the arc voltage error. With eoffset_pid we are creating a position error correction command that is then put into the hal pid which operates in a bang bang fashion (look at the gains and clipping used)to get a velocity command for the step generator (this is for Mesa hardware). I will try and get my current configurations drawn up and posted in the plasma section later this week.

I must admit that even when I used the features of the External Offsets branch to keep the following error to a minimum while using regular hal components to correct the arc voltage error I didn't
about not using the eoffset_pid componenet.

John

Hi,

This is what i get on a 10mm mild steel plate with linuxcnc. The tiny hole is 10mm. The plate is cut at 100x100mm.


Plasma source : Thermal Dynamics ultracut 100xt
Material : mild steel 10mm
Speed 2000 mm/min
Power 100 amp
Cutting gas : Oxygen
Shield : Compressed air
Cutting angle : less 1 degrees

This is the test machine with the linuxcnc hard disk. Accuracy machine 0.1mm in movement, stepper + 2x ltp1 machine.
Okey now turn your monitor 90 degrees :dry:


Okey now turn your monitor back in orginal direction.
Plasma inverter :


So be conviedent. Linuxcnc is almost master kenobi with plasma....

There are a few little things to solve for linuxcnc. No problem. It is free, open source !!

I will read your last post's carefully. islander, rodw, andy, in coming time.
It will be great to have an add on FPGA chip for a simple ltp1 superport card.
For islander, if you use a non chinese or non italian plasma source, normally you can use a pci slot without burning your pc.
Cebora is italian and very bad. There is a italian ellettro source, that can be used. But for both countries, for me the same rule. They are all cheap copy masters.