I’m close to getting my DIY plasma cutter working using Mach3, SheetCam, a Proma THC and a floating Z.
1- What’s the appropriate SheetCam post processor?
2 - Some of the post-processors show with THC. I thought the THC control was independent of the Mach3 G code. I believe that’s the case with the Proma 150 so why is it included in some of the post-processors?
3- Once I have the proper post-processor is there somewhere with an explanation regarding what needs to be changed within the post-processor to make it function properly with my configuration>
#1. I would try the basic mach3 post. You want to make sure you use one with the z axis if you have it. There are some tables that don’t have a z axis. #2. Some thcs are controlled by gcode commands, some aren’t. My table uses S codes to adjust the volts and delays and turn it on and off. Yours may not. #3. You shouldn’t have to make many changes to the post. If you aren’t getting the expected results, post back and Les or someone else will help you.
I got your email but I thought I’d reply here to help anyone else with similar questions.
Start off with the ‘Mach3 plasma’ post. This a a very basic post and does not do the touch-off. Manually touch the torch to the top of the work and zero the Z axis before you start. Once you have it cutting with this post move over to the ‘Mach3 THC with scriber’ post. After selecting the post hit the ‘edit post’ button. At the start of the post are a number of options. You can ignore the scriber related options.
To find your switch offset put a piece of plate on the table and place a sheet of paper on top. Slowly jog down until the switch operates. Zero the Z axis then slowly jog up while gently pulling on the paper. Stop when the paper slides out. The Z axis reading is your Z switch offset. Note the post uses metric so if you are using inches you need to multiply by 25.4.
I got the basic Mach3 Plasma post working just fine but I’m having trouble with the ‘Mach3 THC with scriber’ post.
The problem I see is that the G92 function is not working properly. I took the following bit of code from that generated by the post-processor so I could see what was happening and the way I thought it should work is the G92 function in line 110 should happen after the G31 triggers the sensor. The problem is that as I watch the head move down the Z is zeroed before it hits the switch and the resulting Z is not 0 but a value determined by the length of travel after the Z 0s and the sensor is tripped. As a result all the Z move functions after that are incorrect because they assumed the Z was zeroed.
Just for info I posted the entire code below the code I shortened. I used the shortened version to better see what was happening but the problem occurs in the full code as well.
That looks correct.
N0100 G31 Z -100 F19.685 probe
N0110 G92 Z0.0 zero z with switch closed
N0120 G00 Z0.2930 raise switch offset amount
N0130 G92 Z0.0 rezero z
N0140 G00 Z0.1181 raise to pierce height
N0150 M03 fire torch
I know the code looks correct but it doesn’t work that way.
Think of it this way. The G92 is executed before the G31. That’s not the way the code is written but it’s the way the program acts. I can see the Z go to 0 before the switch in G31 is tripped. From that point all the other Z moves are incorrect.
That a point I forgot to mention; it makes a difference.
When I single step it works fine. G31 lowers the Z until the switch is actuated and the next step zeros the Z, just as you would expect.
When the code is run as normal ( I moved the Z pretty high so there’s plenty of time to watch as it goes down) I can see the Z zero before the switch is actuated thus making all the following Z functions incorrect.
What controller are you using? It could be something with the probe signal not making it to Mach correctly. I read about some instances of this happening.
You could try using G28.1 instead of G31. That would be a Z home input instead of the probe input.
If you see the Z zero before it hits the switch it could be noise on the switch input.
Do you have any Proma supplied macros installed in Mach? If I remember correctly they provide a probing macro that would conflict with this code.
The difference is the pause I put after the G31 (line 120)
The detector is not a switch, it’s an inductive proximity sensor. It seems 100% reliable. It always senses and stops the Z motor and I can see the input recognized on the Mach3 diagnostic screen. I would think if it were noise it would work some of the time and the fact that the one set of code posted above that worked would be subject to the same noise or detector problem. I ran each one 10 time and one worked 100% and the other failed 100%.
I do have a Proma THC but it’s not installed yet and there are no THC macros or plug-ins installed.
Huh. That’s different. About all I can think of is that it is applying the G92 before it has stopped moving from the G31. That of course should not happen.
Edit your post (Options->machine->post processor->edit post). On line 238, just before this line:
post.ModalText(" G92 Z0.0\n")
enter this line:
post.Text(" G04 P5.0\n")
I’d suggest playing with the pause time. At a guess you can probably get away with quite a bit less.
I know Mach does this with macros. I have my reference moves in a macro and when I was making it, Mach would skip ahead when I thought it shouldn’t. I had to add some pauses to get it to work properly.
After adding the pauses the program runs as expected.
The value of the pauses was interesting. It depended on how far above the work piece the Z started. Makes sense. The longer the Z had to travel the longer the delay needed. I ended up manually bringing the Z close to the work piece before starting the program and lowering the safe Z travel to minimize the pause time.
I won’t say problem solved but acceptable work-around developed.
Just a thought - do you use M8/M9? If not, try replacing your G04P5 with
M8
M9
Most controls will wait until motion has stopped before executing M8 and M9.
I tried the M8/M9 suggestion and got the same bad results.
It seems that whatever is controlling things just ignores the G31 travel and executes the next line of code. The only thing that works so far
is the pause after G31.
Is G31 controlled by Mach3 or the motion control card? I suspect it’s the card and the card software is the problem.