Do we need a Plasma Touch Off HAL component ?

More
28 Mar 2017 20:52 - 28 Mar 2017 21:04 #90464 by rodw
OK, I know we have the Gcode touchoff.ngc approach but when I read the MOTION documentation, it seems we are missing a critical component.
The docs say that after each spindle start, movement is inhibited until this is true
motion.spindle-at-speed

When I look in my HAL file, we are kludging this like this:
sets spindle-at-speed true
net spindle-at-speed           =>  motion.spindle-at-speed

I keep thinking that we would gain so much flexibility if we had a component that did all of the smart stuff until such time as XY movement was good to go and then enable the spindle-at-speed signal. Maybe something like:
net touchoff.is-good-to-go          =>  motion.spindle-at-speed

After a bit of research, there are quite a number of smart features some torch height controllers use get faster performance. Stufff like
1. Rapid from pierce height to almost cut height then slow down to sense speed
2. move up to molten pool jump height while piercing
3. only do touch off when next pierce is more than 50mmm from the previous pierce to save time
4. Voltage sampling for auto sensing

So what should a touchoff component do? I came up with:
1. travel down until float switch triggered
2. Move up to pierce height (rapid)
3. Turn Torch on
3a optionally move up to molten pool jump height while piercing
4. Wait for Pierce Delay
5. rapid to 1/2 to 2/3 of distance to cut height
6. slow down and continue to cut height
7. If Arc OK start XY Motion
8. When at commanded velocity, sample voltage
9. Enable Torch Height control

I might have missed something so please toss in your ideas as I was thinking I might have a go at writing a touchooff component if you guys think it is needed and after we get the feature wish list sorted.
Last edit: 28 Mar 2017 21:04 by rodw.

Please Log in or Create an account to join the conversation.

More
28 Mar 2017 21:50 #90467 by tommylight
Again all that except the 1/2 2/3 part is already implemented in hal on the config i use for my plasmas. All that is automated and adjustable on screen, even switch travel for floating head. All that is needed in gcode for it to work is an M3, no sub routines, no M codes, nothing.
On M3 it goes down to work piece, retracts the distance set by switch travel plus pierce height, fires the torch, waits for ARCOK, waits for pierce delay, moves to cuting height, starts XY moves and accepts input from THC, stops corrections on corners if corner lock is active also setable on screen.
It would need the THCAD part to be aded and adjustable setings for voltage, the voltage part already used by someone else on this forum on a config named VLCDTHC or something similar.
Adding the THCAD part should not be hard, but i do not own one ( forgot to order when i ordered a bunch of Mesa stuff , still beating myself for that ).
Again, i would rather have all that as a comp, but in the last several years of use it has proven extreemly reliable on several machines.
Maybe that is not the point of this thread, but somehow it has been mentioned several times that this needs to be added to Linuxcnc, but it already is and was added by someone else ( could not find exactly who, he deserves a lot of free beers for that. ) just needs to be modified for THCAD.
My 2 cents ( maybe more :) )

Please Log in or Create an account to join the conversation.

More
29 Mar 2017 01:04 #90474 by islander261
Hello

I am looking at my setup and wondering how many more component instances I can run without causing real time problems? Really no clue here, it may never be an issue. I am using two G code subroutines to do this task. One G code subroutine does the probing for the plate top surface and one manages the piercing and start of movement. So far with desk top testing all works fine. If I knew how to do conditional execution in HAL file I may have gone that route. Using G code subroutines was the lowest hill and well proven by others.

The probing spacing has been handled in the CAM part of the process by others implementations, look in the CandCNC Sheetcam posts for examples. My system probes for sheet surface every pierce at the present time, wastes lots of time, but I have no choice with my present external torch height controller. When I get my lcnc control up and running this will be one of the first things I look into. Actually if you are mostly doing engineering/fab shop type work this isn't a big gain because of the low number of pierces.

John

Please Log in or Create an account to join the conversation.

More
29 Mar 2017 03:07 - 29 Mar 2017 03:12 #90478 by rodw
Thanks for your thoughts guys.

Tommy, I had a look at your hal code and it looked quite hard to move it to another GUI (Like GMOCAPPY). I also wasn't sure if it would work where LCNC was controlling the X when using a THCAD card.

As I see it, the touch off and THC are 2 separate functions and therefore should be kept as separate components because they don't intersect. This is demonstrated by being able to touchoff using a subroutine in gcode.

Keeping them separate is consistent with a modular approach and you could use a touchoff comp with any THC component (As there are a couple).

John, I think you'd be surprised how much work a CPU can get done in one millisecond. Thats a long time in comparison to the 2 GHz clock cycle of a J1900 Celeron PC. each instruction (in assembler code) might take a few clock cycles so we have a lot of room for competing interrupts on the servo thread. You can't hog the CPU by running long loops. But you have the servo timer interrupt to control ongoing processes so it is easy to workaround.

My thinking was that the current level of plasma control in LCNC is pretty basic (even though its functional) and by having full use of the C language in a COMP. If the PID THC control comes to fruition, we'd have a good robust commercial quality system.
Last edit: 29 Mar 2017 03:12 by rodw.

Please Log in or Create an account to join the conversation.

More
29 Mar 2017 22:56 #90531 by BigJohnT
As soon as I get my nose above the high water mark I'll start testing the height control by pid that Dewey added to the external offsets branch just for THC applications. It should replace my cobbled up thc component :)

JT

Please Log in or Create an account to join the conversation.

More
30 Mar 2017 04:38 #90546 by rodw
John, thanks, I wondered how you were going with the PID THC. I had a look a Dewey's updated External Offset branch and it looks very exciting to see all of the Plasma THC specific stuff. I'll have to give his plasma SIM a try!

I see he's still including your touchoff.ngc subroutine so there is still room to migrate it to a HAL component. I think my world is like yours at the moment but I'd like to find time to try my hand at coding a touchoff component.

Please Log in or Create an account to join the conversation.

More
30 Mar 2017 06:54 #90549 by rodw
Hmm, I'm not quite sure what Dewey is doing here but it sure looks interesting. These are the windows his plasma THC-PID sim opened. (sim is called hpid)


Time to study it closely. JT or Dewey, if you had a spare moment some commentary on this would be really appreciated.

Please Log in or Create an account to join the conversation.

More
30 Mar 2017 07:27 #90550 by rodw
There may be an easier way to get this, but I've attached a text file containing the man page for Deweys' eoffset_pid component used in his PID based THC control sim. Enjoy!

File Attachment:

File Name: eoffset_pid.txt
File Size:4 KB
Attachments:

Please Log in or Create an account to join the conversation.

More
02 Apr 2017 20:36 #90781 by rodw

As soon as I get my nose above the high water mark I'll start testing the height control by pid that Dewey added to the external offsets branch just for THC applications. It should replace my cobbled up thc component :)

JT


It would be good if Dewey could rebase this with master again becasue I'm using Gmocappy and Norbert has asked me to test the latest changes he's pushed to master overnight. I've made good progress in implementing this and removing THC from my config on real hardware.

Please Log in or Create an account to join the conversation.

More
06 Apr 2017 10:12 #90962 by BigJohnT
It still needs to be tested and is not ready for master yet. I've been swamped with work and now I'm off to the mountains for 5 days. I hope to get back refreshed and ready to do more testing. Messing with the sims and understanding them will be a big help. I would stick to Axis to test this experimental branch. Just keep in your mind that experimental branches are just that experimental and may not work. I hope this branch proves itself out after some testing.

JT

Please Log in or Create an account to join the conversation.

Moderators: snowgoer540
Time to create page: 0.099 seconds
Powered by Kunena Forum