- Posts: 19899
- Thank you received: 4655
FPGA (field programmable gate array) programmed for linuxcnc motion
- andypugh
- Offline
- Moderator
-
Less
More
8 years 3 months ago #113549
by andypugh
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?
Replied by andypugh on topic 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?
- rodw
- Offline
- Platinum Member
-
Less
More
- Posts: 12170
- Thank you received: 4153
8 years 3 months ago - 8 years 3 months ago #113560
by rodw
Replied by rodw on topic FPGA (field programmable gate array) programmed for linuxcnc motion
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 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.
Last edit: 8 years 3 months ago by rodw.
- andypugh
- Offline
- Moderator
-
Less
More
- Posts: 19899
- Thank you received: 4655
8 years 3 months ago #113606
by andypugh
Replied by andypugh on topic 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.
- rodw
- Offline
- Platinum Member
-
Less
More
- Posts: 12170
- Thank you received: 4153
8 years 3 months ago - 8 years 3 months ago #113611
by rodw
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.
Replied by rodw on topic FPGA (field programmable gate array) programmed for linuxcnc motion
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.
Last edit: 8 years 3 months ago by rodw.
- islander261
- Offline
- Platinum Member
-
Less
More
- Posts: 757
- Thank you received: 216
8 years 3 months ago #113616
by islander261
Replied by islander261 on topic FPGA (field programmable gate array) programmed for linuxcnc motion
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
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
- rodw
- Offline
- Platinum Member
-
Less
More
- Posts: 12170
- Thank you received: 4153
8 years 3 months ago #113649
by rodw
Replied by rodw on topic FPGA (field programmable gate array) programmed for linuxcnc motion
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
.
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
The following user(s) said Thank You: tommylight
Time to create page: 1.360 seconds