THC Servo Start

Sebastian just looked at the code and it appears that motion.requested-velocity reflects the TPs requested
velocity for the segment and this may be less than the feed rate to meet constraints. I will add a feature request for
a new pin from motion that just reflects the gcodes current (for some value of current...) feed rate

PCW

Thank you, we really need this for plasma cutting.

John

A quick and dirty workaround would be to use a m67 command in the gcode file to set the expected velocity hal pin

PCW

Thanks, we have discussed this as a possible work around depending on the outcome of getting a new pin.

John

Yes, the world of continuous code development/testing is alive and well as I'm 10-15 hours ahead of most of you at 6:00am Saturday morning!

Thanks PCW for escalating this. I had sent a report to Dewey last night

This behaviour has been confirmed using standard sims in

2.7 release branch,


2.8 development branch


and dgarr/external_offsets branch


This sim is using correct velocity and acceleration settings of real plasma hardware (mine) that runs up to 21 metres/min, the others were just using the default settings of the sim in question so the behaviour is much more apparent here.

This then begs 2 questions:
1. Are the docs just plain wrong and have been for years?

2. With the level of variation in current velocity observed, how valid is torch height control using torch voltage in the present simplistic approach? Seems like a more complex algorithm is required.

So are you saying that its correct in 2.7? If so this is a bug since the pin definition should not change
(I'll try and duplicate this here)

PCW wrote:

So are you saying that its correct in 2.7? If so this is a bug since the pin definition should not change
(I'll try and duplicate this here)

No, you can see that requested velocity changes in 2.7 as well. I think the changes also need to be pushed back to 2.7 branch as well as there are commercial systems likely to be affected by this issue. eg Command CNC by www.candcnc.com/

What I may not have made clear is that I've just grabbed random sims in 2.7 and master branches so the velocity and acceleration settings in each screen dump are different (the sim I used in 2.8 did not exist in 2.7). Also I've probably scaled the plots in halscope differently. The intent was just to demonstrate that requested velocity changes value so I did not bother creating configs so I could compare like with like.

The external offset plot is based on a sim replicating my plasma table so its more representative of the real world.

Peter, I will forward via email a zip file of my complete config for external offsets branch I sent to Dewey last night with the bug report.

I waded into the LinuxCNC source and managed to create a new pin but I have not got it publishing data so its always 0 at the moment. There is a structure called settings where gcode parameters are parsed into and it already includes a feed_rate variable that is being populated from an F code. This is done in /src/emc/rs274ngc/interp_convert.cc

Pins are created in /src/emc/motion/motion.c
Data to these pins is published in send_to_hal() in /src/emc/motion/control.c

Variables that are published to hal appear to need to be published in another structure emcmot_hal_data. I added a field in this structure for feed_rate but I have not yet been able to move the data from the settings structure as its out of scope in control.c

Most of the pins that are published seem to be taken from another status structure.

Its a bit late to play with this anymore tonight. This is the first time I've tried digging into the LinuxCNC source so if anybody with a bit more knowledge could provide any pointers on how to do this, it would be greatly appreciated.

Rod

Sorry, my Linux computer doesn't have email. Please find attached my modification to you cornerlock component. The main change is to stop the sampling of the commanded velocity while in the hold or locked state so changes in motion.requested-vel will not have any effect until either the hold is released or there is a new cut (THC enable toggled)

John

hi, I have been playing for two days with this corner lock concept, just to discover by myself the requested vel signal behavior, now I'm stuck, I have set up a rule in SheetCAM to disable THC in corners, it works but is not the most elegant solution, I think have an output pin with the real requested velocity is the way to go, please let me know if it is possible.