Feature update required.
emcmot_status structure in motion.h
This part of motion.c explains in a bit more detail
github.com/LinuxCNC/linuxcnc/blob/master.../motion/motion.c#L85
Please Log in or Create an account to join the conversation.
Well it does a bit, you would need to set all your material cut speeds to zero and you wouldn't be able to use the wizards as they are. To me it kinda defeats the purpose of the materials file, may as well do everything in gcode.
For me there would need to be a different set of calculations for 2.8 and master, maybe different wizards. It seems like a lot of work for no gain.
F#<_hal[plasmac.cut-feed-rate]> may look a bit odd but it does work and it works well.
Would you need to set the values to zero? I would think that the feedrate pin stays but the THC part of plasmac uses the new pin. That way the THC won't care if the plasmac pin is used or the user uses his own F code. It would make plasmac more robust.
Yeh granted that the 2.8/2.9 issue makes it harder to sort out. Maybe Andy will get 2.8 release done next week!
Please Log in or Create an account to join the conversation.
But how does it determine which pin to use, at the moment setting the material pin to zero is the trigger to use the motion pin.Would you need to set the values to zero? I would think that the feedrate pin stays but the THC part of plasmac uses the new pin. That way the THC won't care if the plasmac pin is used or the user uses his own F code.
I am sorry but I don't see how.It would make plasmac more robust.
Release date doesn't change things though. Also we would need different PP's for 2.8 and master.Yeh granted that the 2.8/2.9 issue makes it harder to sort out. Maybe Andy will get 2.8 release done next week!
Please Log in or Create an account to join the conversation.
I assumed it was just used for the normal F code and then used to set the Anti Dive threshold.
if the feed-upm pin was used for the antidive threshold then it will mirror the Fcode regardless if its set by the user or the plasmac feed rate pin.
You could put a variable in the PP to select if it uses the PP feedrate or plasmac's
Please Log in or Create an account to join the conversation.
the material feed rate and motion.requested-velocity
material is used as the reference unless material is Zero, then motion is used as the reference
the reference is then adjusted by the feed override and used as follows:
THC waits until current feed is 99.9% of the adjusted reference before enabling THC (in association with the THC enable timer)
Anti Dive uses the adjusted reference for its calcs
Please Log in or Create an account to join the conversation.
motion.requested−vel OUT FLOAT
The current requested velocity in user units per second. This value is the F-word setting from the G-code file, possibly reduced to accommodate machine velocity and acceleration limits. The value on this pin does not reflect the feed override or any other adjustments.
It has no bearing on the gcode feedrate. Its totally different! Its what the motion controller requests, not what the user requests!
So here is the new pin
motion.feed−upm OUT FLOAT
Current feed rate in machine units per minute for motion.motion-types feed(2) and arc(3). Value is the program F value multiplied by the current feed override value and the motion.adaptive-feed setting (if M52 active). Value is zero if motion.feed-hold or motion.feed-inhibit are asserted.
But if you used the new pin, you would get rid of the conditional pin selection and any feed override adjustments becasue it would be set to the material feed rate if its used. Such an enhancement eliminates any dependence on user space variables
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
It can be used, so long as the user knows that it is not reliable. It is what everyone using THC and THCUD currently use.Well its good that motion.requested_velocity was never connected. It cannot be used period!
It also means we have two different modes of operation, one for 2.8 and one for master, this will create more issues for folk moving from 2.8 to master or vice-versa.But if you used the new pin, you would get rid of the conditional pin selection and any feed override adjustments becasue it would be set to the material feed rate if its used. Such an enhancement eliminates any dependence on user space variables
And I also will have to change all the wizards for master.
Personally I think having two different modes will cause more grief than the little if any gain the change will achieve.
Please Log in or Create an account to join the conversation.
It can be used, so long as the user knows that it is not reliable. It is what everyone using THC and THCUD currently use.Well its good that motion.requested_velocity was never connected. It cannot be used period!
.
I think the reliability issue stems back to the reason why you never connected it in the first place.
THC and THCUD can do what they like really. They did what they could with the tools available at the time and the document was deficient.
You are throwing out one of the major learnings we had pre-plasmac. Thats a shame.
This issue refers. github.com/LinuxCNC/linuxcnc/issues/440
Please Log in or Create an account to join the conversation.
If a user wants to use it they can but they have to specifically set the cut paramaters to do it so it is not as if it would normally be done accidently.
It was originally allowed to satisfy folk who didn't like the idea of F#<_hal[plasmac.cut-feed-rate]> and wanted to type Fnnn, which is a bit of a PITA when you are hand coding.
It is and always was in the docs so I don't see a major problem, well no worse than the current one of a user specifying Fnnn in the gcode and having a different value in the cut parameters. Although having said that I also realise that quite a lot of folk don't RTFM.
Actually, thinking about it I probably should have the gcode parser spit out a warning if it sees an F word that is not #<_hal[plasmac.cut-feed-rate]>
Please Log in or Create an account to join the conversation.