THC Servo Start
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
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
emcmotStatus->feed_rate = tc->reqvel;
*(emcmot_hal_data->feed_rate) = emcmotStatus->feed_rate;
if ((retval = hal_pin_s32_newf(HAL_OUT, &(emcmot_hal_data->feed_rate), mot_comp_id, "motion.feed-rate")) != 0) goto error;
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.
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)
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.
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.
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
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  m2
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.
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.