no mine is tight, but the sticker on the back is coming off. my pierce delay in my tap files read .4 all the way down through all the P’s.
I don’t know what is going on with the pierce delay. I have tried several different things, including the suggestion above and it always sits for about 3 seconds before starting to move after the torch fires. i’d really like to cut it down to half of that. each pierce is the same, about 3 seconds before the torch starts to move. can’t be overly good for the consumables either.
so what are you putting for your pierce delay in sheetcam? 600? or .6?
I have attached screen shots below.
It sounds like the problems that I was having before I set Mach3 to use ms for the dwell. I would check again and make sure that sheetcam and Mach3 are both set to ms.
Good luck
they are both set to ms (Mach 3 and Sheetcam). I never changed them, however I did go back in and double check just to make sure.
I am putting .6 for my pierce delay - is this correct?
Not if you’re in ms if you want a .6 sec delay, go to sheetcam and enter 600000 for the pierce delay, resave your post then open your gcode and you should see P600
Enter 600000 in the pierce delay box and hit enter.
Yes that looks correct
just making sure 6e5ms looks correct?
Yes, make your post and look at your gcode and it should say P600 and that will give you a little over 1/2 second delay
yeah - just did all that and no change in the delay for it to start moving after the torch fires. I have no idea what is going on. can you screen shot your mach config and let me see if anything changed there?
Here you go, we should really go to the other post that I created earlier as we have totally hijacked this thread. lol
Crazy stuff going on here. If P0.6 still gives you 3 sec delay, how come P600 will help?
I think some config needs tweaking rather than the g-code. P0.6 should be standard.
Btw, you can just keep the plasma cutter off and dry run the crossfire to see how much it is waiting. That way you can tinker without burning consumables and steel.
1 Like
I’m not running it while I’m doing all this. And neither 600 or .6 works. No matter what I do it pierces for almost 4 seconds every time on every pierce.
Maybe just try fusion 360 as per crossfire setup tutorials? They have made custom profiles and I think that has settings to help with this unit mismatch.
If you use Sheetcam for your post then there is a known issue with the pierce time below 1 sec.
The difference between .6 and 600 is that for some reason sheetcam doesn’t write the delay correctly on the tap file, so people have found out how to manipulate the entry so that it is correct in the tap file.
P0.6 should be .6 sec if mach3 is set to seconds
P600 should be .6 sec if mach3 dwell time is set to ms which is what I asked him to do.
I really believe after looking at the code above that he posted, we will eventually find out that the line that he has highlighted is the problem, He has a z command and I believe his delay is waiting for the z axis to complete travel.
I looked at fusion and didn’t like it and sheetcam and mach3 play well together once you figure out how to either manually modify your gcode or manipulate the number in sheetcam if you need pierce delays less than one second. I can accurately change the time in sheetcam below 1 sec and it post correctly.
Gunny will also be able to use this same combination effectively very soon.
I posted a modified Sheetcam post-processor to fix the issue of Sheetcam not generating Ms instead of seconds regardless of the units (s or ms) you told it. Sheetcam works in seconds (even going so far as to translate ms entries to their equivalent fractional seconds). The post has to adjust that to create ms entries that Mach3 needs so it can do sub-second times.
I do agree that the Z axis adjustment is likely his problem. Suppressing or zeroing all related Z axis parameters should fix it as would my post processor as it does not create Z axis settings.