THC Servo Start

If you know where in the gcode the fault is located, maybe one possibility is to use M62 to "arm" the
trigger on enable (by using an and comp in hal to create a specific halscope trigger signal)

John, I just wondered if the problem is that your commanded torch voltage is off when you enable THC servoing? eg. you are commanding say 90 volts and the torch is running at say 110 volts so there is a sudden attempt to adjust for the difference that causes the divot?

The solution to this would be to sample the torch voltage as you turn the THC on so that there is perfect alignment with the actual volts and target volts when you start so nothing should move.

I have shared a component that does this (that works well) in another post in this forum section.

PCW, Rod

Thanks for the replies. I understand what you are proposing. I think the best approach will be for me to generate test files that mimic the cut segments that have the "divots". This should be easy because I have all of the original artwork and SheetCam post the cut files were created from. The "divots" occur at the same place in each part cut out of the sheet.

I want to let the results of testing drive the resolution of this problem. However I am in agreement about the arc voltage set point not being equal to the actual arc voltage when the height hold is released. The height hold setpoint was 85% of requested velocity when these parts where cut. The voltage arc set point is for 100% requested velocity so the arc voltage had already start to raise by the time the height hold had been asserted (torch had lowered a little bit) and the arc voltage was dropping but not at the set point when the height hold was released ( arc voltage was above set point) causing the torch to dive very briefly. This transient is fast in real world terms, estimating distances from the photos I get .075"/ (( 220ipm *.85)/60)=.0240s. I really hate to slow the THC down without actually doing testing to prove it is required. I am beginning to think that the simple height hold ( or as implemented in eoffeset_pid, velocity hold) algorithm we are trying to use isn't up to the task of precision cutting in it's present form.

John

Perhaps you can extract the curved snippet from your code and set up a test file with iterations of just that segment.

Personally, I can't really understand why people get so fixed around running an exact torch voltage written down in a book or a series of cut tables. The objective is to keep a constant height and it just so happens we can't measure it other than indirectly via the torch voltage. But that can vary at the desired cut height due to consumable wear or other factors.

From my research, torch voltage PID control differs significantly from most PID controls in that it wants to maintain a setting not move to a set point like a thermostat temperature or the level of a liquid in a hopper. With a thermostat, it does not matter if we start 10 degrees off the setpoint. For plasma, I found it did.

In our case, ideally we want to maintain the voltage exactly where it is when its turned on.

I think sampling the torch voltage when the THC is enabled is by far the best method to ensure this. I wrote my sampling component to avoid any violent adjustments when testing the eoffset-pid that caused immediate oscillations/overshoot.

I've attached an annotated version of your schematic where I think the torch sampling should be inserted. It would not be a big exercise to try it, particularly if you build the test file I suggested.

Its possible that this component needs to accept a few more parameters like: commanded velocity and actual velocity and include an algorithm to calculate a velocity/voltage adjustment. That would then allow the component to raise the sampled set point if it senses an increase in velocity. Its probably not hard to measure a ramp up from 85% of the commanded voltage to 100% using halsampler to form an empirical basis for the adjustment algorithm. But overriding this, you won't ever know what the correct voltage is at 100% velocity for a given cut so you can't begin with a clear end goal to achieve.

Rod

I agree that the best way to set the arc voltage is by sampling it at a fixed cut height (after all this is what the high $ Hypertherm controls do). I have the code in my system for an arc sample voltage mode of setting the arc voltage set point. I haven't used it because of the very limited testing I have done. I am trying to transition to production cutting ASAP. I am sure that the "divots" from the start of the arc voltage servo are because of poor sheet surface detection which is not that likely because every time I test it it is good, ok maybe while running on a full sheet it tries to touch off on a dross pile...

The " divot" at the end of the hold time is another matter. We know from analysis that the torch should be some small amount below the ideal cut height because of who we trigger this. We also know that when the hold is released that the arc voltage is high for the current torch height because of the reduced travel speed. I need to figure out a way to limit the response when the hold is released but have full speed while in the rest of the cut. I bet there is an existing hal component that will work for this or maybe even an existing PID parameter.

John

Here is an idea. Set a PID deadband of say 2 volts. Assuming voltage is higher at lower velocities (did I get that right?). If the velocity is less than commanded at the time the torch was sampled, set the commanded volts to sampled_volts -1 volt (half the deadband). Continue to make the same adjustment until the commanded velocity is reached and then centre the deadband on the sampled reading eg. commanded volts = sampled volts when velocity is 100%. Don't make any adjustment if the voltage moves in the wrong direction, let the THC adjust for it.

Guys

Please find a simplified block diagram of the table Z axis control attached. This is a new revision that shows changed connection to get rid of Z axis (actually joint.3 following errors when height hold was asserted). Velocity height hold is asserted while in the cut by M:offset-enable going low. It also shows the connections to the motion component velocity pins to clear up any confusion about the source of these signals.

John

Hello

I believe that I have found a rather strange source of some of the "divots". All of the THC comps that I have seen that do any sort of velocity hold are comparing motion.current-vel to some fraction of motion.requested-vel and causing a height hold when it is less. If you look at how motion.requested-vel is defined in the docs this makes perfect sense:

motion.requested-vel - (float, out) The current requested velocity in user units per second from the F=n setting in the G Code file. No feed overrides or any other adjustments are applied to this pin.

The trouble is that it only behaves this way when the motion planner thinks the mechanics of the system as set in the .ini file can keep up. The motion planner reduces the value of motion.requested-vel if it will cause a violation of the .ini parameters for that joint (slows down for the corner). This causes a problem for the height hold because you are comparing to a moving reference which ultimately causes the THC to be active when it should be holding. Look at the attached halscope screen shot.

You may need to view this with an external viewer so you can zoom in to see the details. The blue trace is motion.requested-vel. The sage trace is motion.current-vel. The white trace is hc.enable-out (thc servo enable) and the red trace is arc voltage. You can see two instances on the right side of the screen where motion.requested-vel dropped to some value below the value commanded by the F word in the gcode. The result is the predictable enabling of the THC servo when it should be holding the height which leads to the torch diving and a "divot". This happens in a number of place during this cut. I have attached a second screen shot from a different part of the the cut to show this is not an isolated case. I have also attached the gcode for the cut that these screen shots were taken from.

OK so I am way over my head here. Do I not understand the docs correctly? Are the docs in error or incomplete? Is the motion component not behaving correctly? I do know one thing for sure and for any sort of velocity hold to work when plasma cutting we need a stable source of commanded velocity from the gcode we can access in the hal. Right now the behavior of the motion.requested-vel pin causes the velocity hold functions to fail just when you need them the most when plasma cutting.

John

Wow, I am surprised that this hasn't generate some interest as it potentially affects most plasma configurations I have seen. This was also independently confirmed by rodw on both the external-offsets and master branch last night (well day in Oz).

John

Requested velocity definitely doesn't behave as I would expect
(I would expect it to follow the feed rate in the gcode file during all but G0 moves)