Another plasma component...

islander261 wrote: Phill

Thank you, I actually don't read all the new man pages as you create them...

I've been reading through this thread and it has just about convinced me to build a plasma table. I'm amazed at what is being accomplished here. I built a CNC router from scratch several years ago but used Mach3. While Mach3 is functional, I see a lot of benefits of using LCNC. I'm still trying to get up to speed on LCNC; I've found the "standard" man pages, but where can I find the new man pages that talk about plasmac (referenced above)? I looked in phillc54's Github repo but couldn't find anything. Thanks in advance for the help, and thanks to all for the hard work that's been done to create plasmac.

Steven

docwelch wrote: but where can I find the new man pages that talk about plasmac (referenced above)? I looked in phillc54's Github repo but couldn't find anything. Thanks in advance for the help, and thanks to all for the hard work that's been done to create plasmac.

Steven, man pages for components are created at compile time from comments within the plasmac source code github.com/phillc54/linuxcnc-plasmac/blo...ponents/plasmac.comp You'll be able to read that file but its not easilly readable.

they are displayed from the command line by typing
The LinuxCNC architecture allows anybody to write a custom component In c and embed it in your hal configuration using the hal component generator linuxcnc.org/docs/devel/html/hal/comp.html

so if you wanted to edit plasmac.comp, you could recompile it and install it at one time using To install the documents you need to type
These commands need to be prefaced by sudo if you have not installed linuxcnc as run in place from source (which is required for plasmac)

Because plasmac sets up simulations in various GUI's you could install it and play in the sims now without any hardware attached. I have written another thread with install instructions based on my recent installation. See forum.linuxcnc.org/plasma-laser/36410-in...her-plasma-component

islander261 wrote: Guys

I run my system like a mill. I jog the torch to X0,Y0 on the work piece and set the G54 X & Y offsets from the touchoff screen. I have a permanent G54 Z offset that puts the top of the work sheet within the probing range. I think that Gmoccapy likes to work this way. I tried using G92 before and it just shifted some machine zero if I recall. the G92.1 clears all previous G92 offsets, usually called at end of Gcode file to leave machine in known starting state. What you are doing is just shifting the machine zero to the work piece origin rather than setting a work piece origin in G54. This is an old legacy Mach trick for simple tables without homing that didn't use soft limits.

John, Phill thanks. I knew I was doing it wrong but just did not know how to do it right! I'll work on this. Sounds like John's trick with the G54 Z offset will solve my problem. Gmoccappy macro buttons sounds like they are the go here. One for touch off x,y and another to probe for Z0 to set the G54 Z offset. I'll share what I come up with.

This still does not solve the problem of the continuous loop if you get this value wrong.

Rod

I really don't know what to say, at some point we all need to get the correct .ini values for our tables. When I got mine set correctly most everything seems to be working correctly. The G54 Z offest had no effect on getting rid of the Pogo stick on my system, only the correct MIN_LIMIT fixed it ( my Zmax is at the top of travel, if your directions are reversed then it will be opposite). I only set the G54 Z offset once and Gmoccapy seems to remember it. The G54 X & Y offsets are set to the work piece origin or zero once for each work piece. On my system the G54 X & Y offsets are always 0 at startup.

Phill

Well another day of cutting. The reverse run really saved the day today because I was busy grinding while the machine was cutting. Several tip up collisions while cutting that would of previously ruined the part, easy recovery and no lost parts! All in all things are working pretty well, the weirdness is most likely operator error at this point. Plasmac is quite usable at the moment.

Still having some strange happenings, I really hate to say random but it sure looks that way. The machine followed the feedrate from Gcode correctly with the Cutting Speed set to 0. The feedrate displayed on the Gmoccapy active Gcode and feedrate frame only intermittently updated to current feedrate. I couldn't detect any pattern to what was going on but I was seeing the correct speed with a halmeter but the wrong one on the UI and then sometimes it was correct.

I think I need some instruction on how you intend the IHS Skip to work. It actually appeared to work intermittently for me today. Is the shorted torch test supposed to happen even when skipping a probe? It actually looked like the IHS Skip is affected by the Gcode order or move direction as well as the actual distance from the last probe. Some times the it would work as I think it should and sometimes on cuts with start points well within the IHS Skip distance it would probe every cut.

John

islander261 wrote: Rod

I really don't know what to say, at some point we all need to get the correct .ini values for our tables. When I got mine set correctly most everything seems to be working correctly. The G54 Z offest had no effect on getting rid of the Pogo stick on my system, only the correct MIN_LIMIT fixed it ( my Zmax is at the top of travel, if your directions are reversed then it will be opposite). I only set the G54 Z offset once and Gmoccapy seems to remember it. The G54 X & Y offsets are set to the work piece origin or zero once for each work piece. On my system the G54 X & Y offsets are always 0 at startup.
John

John thanks. pretty sure my Zmax is at the top of travel. I'm just going up to the shed now. I kinda think my zmin is too low below the cutting surface so the probe height is lower than the material surface. So the probe is triggered when plasmac is not expecting it

IHS skip should work like:

If start of cut within n distance of end of last cut then skip IHS providing:
THC was active on the last cut and no errors were detected on the last cut.

Well that is the theory anyway...

Cheers, Phill.