FPGA (field programmable gate array) programmed for linuxcnc motion

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.