THC Servo Start

The current workaround is to also send the feedrate/60 by an M67 E1 Qnnnn command in your Sheetcam POST where it sets the cutting speed with the gcode F command. Then update your HAL files and replace references to motion.requested-vel with motion.analog-out-01. Please check your config to make sure this digital pin is not in use and use another pin if it is (the E1 parameter).

Then install the component John (islander261) posted for corner lock. .

PCW has added a feature request in the linuxcnc issues register and there has been a couple of comments about modifying the code.

Also, I've rewritten my torch voltage sampler to wait until the current_vel is near the feed rate (default 95%) and sent it over to John but neither of us has tested it yet. So we've finally nearly got a full feature set for plasma

I added a new field called feed_rate to the
emcmotStatus and emcmot_hal_data structures

I then tried what Sebastion suggested on the issues tracker github.com/LinuxCNC/linuxcnc/issues/440
and this is what I got.



in /src/emc/tp/tp.c, I added in src/emc/motion/control.c (to load the Hal structure) And in /src/emc/motion/motion.c
I didn't understand what Sebastian mean when he said "And when the tcq drains, set that pin to 0." but the value drops to zero between cutting segments.

Any ideas would be much appreciated.

Idiot. Helps to get the data type right


So we have a winner (220 inches per minute on a metric machine).

grijalvap wrote: 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.

Pedro, I've sent you an email. If you can reply to it, I'll send you a solution. (Providing it tests OK for John)

Sorry guys, a false start, the feed-rate pin is a copy of requested-vel

Oh well, it at least got me to organize all my custom components so it is easy to update my rtlib after the recompile.

John

islander261 wrote: Oh well, it at least got me to organize all my custom components so it is easy to update my rtlib after the recompile.

John

Sorry about that. Not the first dry gully you've been up on this project I'm sure! I have to get the code into a git repository so it accessible by all (and can get pushed to master branch).

I did do a bit more digging and am sure it can be resolved.

Just a bit of an update. And a Solution!

After a bit of research I found something and asked the devs if we could remap the F code..

Some of the developers had forgotten that the F code can be remapped. There is a complete sim example already included.

It uses a subroutine called setfeed.ngc and you just have to change it to
And use motion.analog.out.01 instead of motion.current-vel in your HAL file.
After I confirmed this worked in a sim and grijalvap has tested this on a live config.

So the only thing missing is some decent documentation on remapping as its a bit convoluted to migrate it from a sim to a live config.

Can't await until Sunday.
I have implemented the Remap solution on a Live Cutting system attached you can see the signals

Channel 1 speed out for Z axis
Channel 2 Voltage
Channel 3 torch position
Channel 4 current speed

grijalvap wrote: Can't await until Sunday.
I have implemented the Remap solution on a Live Cutting system attached you can see the signals

What do you mean? Its already 8:00am Sunday morning here! Time to get out of bed!

So good to see this finally coming together for a few people. Those results look great.