Wandering Z zero

Hello

This may also belong in the G code threads.

I have a nearly working plasma system that works flawlessly when doing test line cuts. Now that I have started working with real cut files and the PP to generate them I am having what seems to be random shifts in Z zero. I am sure that this isn't really random and that it is an artifact of the way I am handling touchoffs. I only cut 14ga (1.75mm) hot rolled steel so everything happens real fast. I have only run my old mill which only has machine and one set of work coordinates and no G92 so I am really in the dark about proper use of work offsets. My present plasma uses an external THC and has no knowledge of actual Z position, only is the torch ready to move. This is what I do.

I home the machine at turn on to the limit switches. The Z axis is homed like a mill with Z machine zero just off the upper limit switch. I then place the material on the table and square it up using manual jogging against the torch mounted laser lines. I then jog the torch to the part X &Y zero location and set the G54 X zero and Y zero using the offsets tab. So now my DROs read X G54 0 and Y G54 0 and Z G54 reads about +2.6 which is close to real world. I will then load the part program and run it. When the system probes for Z part zero I use a G38.2 down to find the sheet surface and the a G38.5 up until the probe disconnects. At this point I do a G92 Z0 to set the part surface zero for that location. It may run the whole program with no problem but may not. If it runs ok if I then reset the the G54 X & Y zero for the next part. Then at some point it will fail with either a probing error warning that the move will exceed Z -limit alarm or the probe distance will not be long enough to find the sheet and the probe will fail by not tripping at the maximum probing distance. I have not found a repeatable recovery method yet. Sometimes just rehoming Z will work and sometimes not. Am I generating some kind of accumulating error with every G92 Z0 when probing the material surface? Do I need to do a G92.1 at the end of each part, this seems to really mess up the starting Z zero? Do I need to do a G10 L20 P1 Z0 instead of a G92 Z0 to set the part surface? Anyone find an error in my method? I am very close to a workable system. Fixing this coupled with a little more robust error handling during probing, a fact of life probing errors happen, and I should have a working system. THC is working great.

John

Tommy

Thank you, I have seen your work referenced before. My hardware will not be compatible with your exact code as I am using a 7I76E with a THCad card for THC. The THC part of my install is working better than my old Torchmate AVHC ever did, holding to +/- 2V on curvy lines. I am going to study the files for clues though.

I did a trial of cutting a full sheet tonight and things didn't go as planned. I did intentionally choose a part that is tricky to cut in order to stress the system and find the failure points. The sheet had 8 pieces of medium complexity, 59 pierces each using two different tools, one with thc disabled/slow cut speed and one with thc enabled normal cut speed. The first two cut with no problems. The second one had 2 bad touchoffs that required intevention, the third one had 6 failed touchoffs, the forth was a real disaster and I didn't finish it tonight. At least I am learning LCNC disaster recovery methods during testing.

I am seeing that most of the failures are probing related. Some are to be expected such as a shorted nozzle to shield from debris and water from the table. Others are harder to explain. I have a dual sense system, ohmic sensing and a floating head switch. I have some protection built into the code but obviously not enough. Some of the error detection worked as expected but I haven't discovered all the ways that G38.x probing can fail yet.

I still haven't figured out what is going on when the probing fails in a sub routine. I stop the gcode program running with the stop button and because the subroutine isn't displayed in the code window correctly I have go back by hand and find where it was call from in the mainline code. After fixing the problem and resetting the Z height to the correct value I try to start the program with using the run from here button on the gui. I enter the line number I want to start from and the code display shows the selected line highlighted. Then I select the run button and the program starts in the middle of the subroutine that it was in when it was stopped! So obviously the stop button doesn't actual stop and rewind the program, it is more of a pause with undefined restart. I have tried estopping and just shutting down with the gui power button neither changes this behavior. On my old system when you paused it that is what happened and when you stopped it the program reset to the beginning. There are couple of other puzzling behaviors with the G38.X and subroutine recovery but I need to fix the basic stuff first. Well I have plenty to think about tonight.

John

PS the cuts look good.

Tommy

Thanks for offering your work. I always send folks looking for a simple parallel port with Proma plasma to your thread.

What happened today. Sorry I don't have the photos together but I have moved into the house for the evening to keep the peace. I put more error checking into the touchoff sub and finished cutting the 4th piece. The touch off is now working (or should I say catching most errors) before they lead to cutting problems. Still one niggly problem, the occasional error that probing will exceed the Z min-limit. Of course when I look at the DRO and do the math the end point for the probing move will not be close to the z min-limit, I come back to this one later. The one thing that is very troubling is that when making long cuts the torch is dropping out for segments of the cut. I have never had this happen cutting with my equipment in 5 years. There is a lot going on really fast when cutting thin sheet so I don't know what is going on. So a little refining on the probing error handling and off to cut the 5th piece. Things went really well with the probing errors being caught before they caused a problem other than requiring operator intervention. Still had the problem with torch drop out on the long cuts, still no clue about the source. One clue is that the system is seeming to react to operator input and subroutine calls very slowly. So I bit the bullet and shut down the system, power of to the PC, box with the 7I76E and THCad, and the stepper drivers. Re powered everything back up and started lcnc fresh. Rehomed and set the G54 work offsets to the work sheet. I then proceeded to cut the last three pieces with only interruptions for probing failures, no skipped segments in long cut. Actually the probing and cutting performance improved with each of the last 3 pieces. So I don't know what is going on but do know that I am now going to rewrite and test the probing using the same flow chart I used to fix the old TM controller. Still have the same problem with the preview screen. I will post some photos and maybe a video tomorrow.

John

The one thing that is very troubling is that when making long cuts the torch is dropping out for segments of the cut. I have never had this happen cutting with my equipment in 5 years. There is a lot going on really fast when cutting thin sheet so I don't know what is going on.

That sound like to me it could be the plasma cutter itself. Is by chance the ArcOK going out before the flame out? If my plasma looses ArcOK, it tries to establish the arc so I get an intermittent cut. Maybe you can make your machine monitor ArcOK and do some error handling if it goes off while cutting.

Tommy

Correct, the torch actual goes out and then restarts. It is kind of strange because it appears to be exactly one or two line segments (blocks) long out of a long line. This is even stranger in that it appears that my system needs to have been turned on for long period or I need to have made a number of parts before it starts to happen. It is not related to my power supply or torch because I switch between controllers when I change back to my production work and this never in 5 years has happened with the TM controller.

I the probing problems are 100% related to the use of ohmic sensing of the plate surface with a floating head switch to back up. If I just had a floating head switch this would have worked the first try. I am getting very close now. I rewrote the touchoff sub this morning so that it checks for more errors and then automatically retries on the ones don't require operator intervention.

John

Well as promised here are some photos of the problems. In the end I only had to resort to the die grinder cutoff disks for one part of of the whole sheet.

John