motion.requested-vel unexpected behaviour

[pcw-mesa]

motion.requested-vel is used by at least a couple of plasma Torch Height Control (THC) systems to allow setting of the corner lock threshold as a percent of feed rate. Unfortunately, motion.requested-vel is the TPs requested velocity and not the gcodes specified feed rate so the THC velocity compare can fail in some circumstances. One solution would be to add a new pin to motion that just reported the feed rate from gcode

[SebKuzminsky]

I think this feature will require the state tags branch to do correctly.

[SebKuzminsky]

... Or maybe not. Maybe tpActivateSegment() could just put tc->reqvel on a pin. And when the tcq drains, set that pin to 0.

[rodw-au]

I tried Seb's suggestion and it worked! See https://forum.linuxcnc.org/plasma-laser/34650-thc-servo-start?start=30#112187 I did not understand what this meant "And when the tcq drains, set that pin to 0" (guessing its about queues) but it appears that the pin resets to 0 on its own accord.

[SebKuzminsky]

@rodw-au, neat! Do you have a branch somewhere that I can look at?

[rodw-au]

Seb, let me see if I can learn how to do that after I do some more testing to make sure it works. I need to redo it on master branch instead of dgarr/external_offsets as well.

[SebKuzminsky]

Of course, and let me know if I can help with any of the git stuff.

[rodw-au]

Testing failed so back to square 1. tc->reqvel is a copy of motion.requested-vel. I also tried tc->target_vel I'd like to be able to access settings->feedrate from hal. I've tracked that to CanonConfig_t.linearFeedRate but its already modified in SET_FEED_RATE() before storing. I think a new field in CanonConfig_t should be added and SET_FEED_RATE() could store the raw F parameter. But I don't know how to get it from there to where it can be seen by hal in control.c Any ideas?

[SebKuzminsky]

Motion gets a sequence of segments (lines and arcs) from Task. Each segment carries with it its own requested feed rate, which as you noted shows up in Motion on tc->reqvel and in HAL as motion.requested-vel. The requested velocity that Task uses for lines is normally the F-word, except when that would violate axis velocity constraints from the ini config. The requested velocity that Task uses for arcs normally the requested F-word, except when that would violate axis velocity or acceleration constraints from the ini config. The following picture demonstrates this behavior. It's a low-acceleration machine, running a program consisting of alternating lines and arcs, where the arcs start out small and increase in radius along the sequence. Notice how motion.requested-vel is always high for the lines, and for the arcs it starts out small for the small arcs, then grows gradually to match the straight-line requested velocity once the radius gets big enough that the low machine acceleration can keep up with the arc path.

[SebKuzminsky]

This is all to say: Motion doesn't know the programmed feed rate, it only knows the requested velocity of each segment. This requested velocity is generated by Canon (the interface between the Interpreter and Motion, inside Task) based on machine constraints.

So I'm back to my knee-jerk reaction of believing this has to wait for State Tags.

I'm not familiar with Torch Height Control, can someone educate me on this use case where the programmed feed rate is more useful than either of the two velocities (motion.current-vel and motion.requested-vel) that are currently available?

[pcw-mesa]

I am no expert but what I believe is wanted is a way to compare the gcodes programmed feed rate (FXXXX) which is the desired plasma cutting speed with the actual speed (current velocity) so the THC can be disabled (frozen at current height) when the current speed dips to a specified percentage of the programmed feed rate (to avoid diving at corners).

[rodw-au]

Torch Height Control (THC) is fundamental to plasma operations. With plasma there is a linear relationship between torch voltage and cut height. Manufacturer's publish cut charts stating ideal heights, cut speed and arc voltage for a given material and thickness. Feedrate is usually set based on these parameters. The arc voltage is used as feedback to a PID controlling Z axis height. When the TP slows current-vel, voltage increases so the PID lowers the torch height sometimes resulting in a crash. The solution is to inhibit PID control when current-vel falls below say 85% of feed rate set from the manufacturer's data. (Velocity Hold)

This issue stems from incorrect documentation stating that requested-vel is the F parameter. At the high speeds used in plasma, changes to requested-vel are often violent.

Where a user depends on the incorrect documentation, THC operation is enabled unexpectedly due to the fall in requested-vel for a segment and a violent and unexpected correction can occur resulting in a divot in the cut.

Because of the current requested-vel behaviour, the solution is to send the feed rate from Gcode twice, once as a F code and again as a M67/M68. Such data duplication is highly undesirable as it can result in errors.

I have spent several hours studying the code and came to understand the relationships between the modules as Seb has described. I noted that EMCMOTSTATUS was described global in the source and I did try setting a new variable in the structure from within canon (from SET_FEED_RATE procedure) but got a runtime error so I assume it is only global to motion.

Can global EMCMOTSTATUS data be altered from canon? Is there a branch for State Tags? Can you explain what State Tags does?

[pcw-mesa]

I'm not so sure that the documentation is incorrect, just that it is incomplete That is motion.requested-vel is whats requested of the TP, which means it has additional constraints compared to the bare gcode feedrate number

To quibble, it really should be named a speed, not a velocity...

[rodw-au]

2.8 docs at http://linuxcnc.org/docs/devel/html/config/core-components.html#sec:motion-pins state: 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.

Speed and velocity aside, there is nothing said about it being adjusted by Machine and TP constraints on a per segment basis.

[pcw-mesa]

Ahh, I was just going by the manual page which says less:

motion.requested-vel OUT FLOAT The requested velocity with no adjustments for feed override

The docs are more misleading than the manual page, though its true that it is derived from the F=N setting, it just has additional constraints

[SebKuzminsky]

I updated the docs (manpage and html docs, in 2.7 and master) to try to be more clear.

@pcw-mesa, I agree it's a speed, not a velocity, but I think calling it requested-speed would be more confusing, since "speed" is a term-of-art for the rotational speed of the spindle. We also can't call it requested-feed, since that would exclude rapids...

[rodw-au]

Can you give a synopsis of what "State Tags" does? I found the discussion about merging it but still none the wiser what it will achieve.

For plasma use, I think its possible to synthesise a feed-rate in a component that monitors requested-vel and has an output pin which is ratcheted up whenever requested-vel increases and is reset to zero when motion stops.

Thanks for updating the docs. I can see the change now.

[rodw-au]

I'm just a novice with all of this but I think I just found there is a simple workaround. Perhaps plasma users should just remap Fnn and issue an M68 E1 Pnn to send the raw feedrate to HAL. Are there any possible negative side affects of this approach?

[andypugh]

I hadn't realised that F could be remapped, but it appears that it can: http://linuxcnc.org/docs/2.7/html/remap/remap.html#remap:remappable-codes

This should work well, as it does not need the postprocessor to be THC-aware.

[samcoinc]

Huh - I didn't know F could be remapped either.. cool - I think I have an application for that too.

sam

[rodw-au]

Just to confirm that remapping the F code is a solution thats been tested by a couple of us and it will work. But before we close the issue and while we've been updating the docs earlier in this issue, may I point out that the remapping documentation is poorly lacking and the F code section has several TBD's in it which I assume means TO BE DONE.

Here is an example gcode setfeed.ngc sub based on the axis/remap sim that works, maybe it could be used in the docs

o<setfeed> sub 
(debug, in setfeed feed=#<feed>) 
; using the code being remapped here means 'use builtin behaviour' 
M67 E1 Q[#<feed>/60] 
F#<feed> 
; signal success be returning a value > 0:
o<setfeed> endsub [1] 
m2