Another plasma component...

Yes I checked an old config and that is set in the ini file. So what does plasmac do to reset the G92 X0 Y0 Z0 data? I'e not come across that before.

rodw wrote:

Yes I checked an old config and that is set in the ini file. So what does plasmac do to reset the G92 X0 Y0 Z0 data? I'e not come across that before.

OK, I see now your mertric_startup.ngc issues a G92.1. Why is that? Will it break something if removed?

phillc54 wrote:

Not sure, only one way to find out.

Cheers, Phill.

Just navel gazing at home.

I might have another go in the morning.

Let me know your thoughts on this idea. I think I need to probe each corner of my table and pick the highest point and see how far above the minimum soft limit the table is. Then add the thickest material I can cut (say 25mm) Then add a probing distance above that. How high above the material should the probe height be? Say 10mm , 20 mm or something else?

The default probing speed is 1000 mm/min. Does that work for you?

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.

I had probing problems with Plasmac until I got my Z limits correct for my actual table condition instead of no errors when making Gcode Z moves when probing from Gcode. You will get better probing by moving slowly so set the probe distance for the anticipated thickness of the material so it can be as short as possible, I probe at 5ipm right now. If you set it for the thickest you can cut you will will waste time probing.

Phill

Cut time = arcok AND movement in X & Y
Cut Distance = arcok AND leading edge distance to go ( transition from 0 to some number) , I tried to use time and feedrate and it was way off. The TP should do a good job at calculating the actual cut distance so I think the key is getting it out. I think it is easy in plasmac because on cutting moves all Z movement is handled outside of the TP so DTG is only a 2D move.
Probing time = ohmic probe enable, of course this doesn't work for float switch probing so I guess time while at probe speed?
Pierce count = number of times torch on goes true.

At the end of the day the actual times are good for job costing and the pierce count and distance cut for estimating consumable life left. SheetCam is ok at estimating but doesn't account for machine acceleration which can have a huge effect when cutting art work ( non rectilinear pieces).

John

John

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 usingTo 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