Anyone Actually Using External Offsets Branch for THC?

Hello

Well I have made some progress towards having working THC using the eoffsets branch. I have looked at the source code (I'm not a programmer) till my eyes bugged out get my head wrapped around this thing. I have cut nearly 100 test lines in the shop trying to find a configuration the works well. Thanks to Dewey for all the hard work he put in getting it this far.

What I have now is THC in a straight line with no corner hold or kerf crossing tested. The torch holds 2v (.010") pk-pk or better position while following gently bending sheet. The height control is still a little "nervous" for my tastes but much better than previously. The cut is good with no noticeable variation in taper or kerf width. I have even gotten to test many of the extra features I added to my GUI. I think I will have a total rebuild of my GUI before putting this into production use. I also need to reinstall the eoffsets branch because it has been rebased since my last install.



My configuration is not the standard one for testing the eoffsets branch. I am using eoffsets_pid Pgain =1 and Dgain =.1. My machine is an inch units machine. My z axis is set to maximum velocity of 220 ipm with an acceleration of .15g. Here are the deviations from the standard test configuration files that I have.
During my testing I found that it would have been really nice to have separate scaling factors for both axis velocity and acceleration.

Tonight I have to reinstall my old commercial controller so I can get back into production. It will be a month or more before I get a chance to dive back into this, maybe someone else can clear more of the path in that time.

John

John, great you have made some progress. You prompted me to read the whole thread again.

When you say this:

islander261 wrote:

Hello
During my testing I found that it would have been really nice to have separate scaling factors for both axis velocity and acceleration.

You are referring to being able to alter the velocity and acceleration values in the ini file right?
The hpid GUI provides a window for this and you can implement it in your config by adding this to your ini file (update the path)

I found I had to add the complete path to sim_pin but for some reasons the sims don't need to. I've never worked out if sim_pin is something added by Dewey on this branch or if its included in LinuxCNC. It is very handy though.

Rod

Well I was actually thinking about this snippet:

OFFSET_AV_RATIO = .5
MAX_VELOCITY = 7.7776
MAX_ACCELERATION = 110

Having one ratio for A and on for V. I will look at what you posted, it may do the same thing. Though I doubt it is needed for a production machine.

John

John, it only lets you change these 2 on the fly
I don't think we need to change OFFSET_AV_RATIO

Rod

What I want to do is have independent ratios for each velocity and acceleration. By using the ratio and the max value I can tune the different response between operating under gcode control (planning) and eoffset control. I always want near maximum under gcode but for testing and trouble shooting it is nice to slow down the eoffset control.

John

You can't do that as OFFSET_AV_RATIO is part of the internal external offset code, not part of your config or the component without rewriting the core code. (eg. uses axis.eoffset-scale pin)

Remember, the original intent was to give up a fraction of your velocity and acceleration so it could be used independently for the external offsets without the knowledge of the trajectory planner. The result is your machine slows down. I bastardised it by setting up a config that used 100% of the velocity and acceleration for THC and jogging/touchoff applications (which was only possible because these operations are both mutually exclusive). I did this by doubling the values for velocity and acceleration in my ini file

What you could do is revert to the original intent, (eg. don't double your velocity and acceleration values) to achieve your goal. But THC needs a lot of horsepower (OFFSET_AV_RATIO = 0.8 is suggested). Try it by all means but touch offs will take forever (limited to 20% of the maximum)

Rod

You hit my intent right on the head. Change the underlying code to support one ratio for velocity and one for acceleration. I have no intent on trying it myself. I actually don't know if you need it for a production machine. It sure is nice while homing in on the correct tuning to slow things down. My use actual would be in the other direction, values >0 and <.5. The difference between (1-r) and r can really help to skew response.

Power on the Z axis isn't a problem for me, I have a spare 490oz/in stepper driving it with .1" per rev two start (.2" effective) lead screw.

John

Its nothing about power. Its about making the thc as responsive as possible (eg. fast). But I do get your point about changing the velocity as part of the tuning process.

I did some maths but never did implement it. It is possible to vary my 0.5 ratio and change the maximums in such a way to keep maximum velocities for touch off but run a slower velocity on the THC but it can get confusing with the virtual velocity and accelerations