Cut not matching Sheetcam file or simulation

Can anyone look at these Sheetcam settings and explain why the 2 inner shapes are being cut right next to each other (almost overlapping)? They are being cut before the outline which is good but not in the correct position. As you can see - the shapes are no where near each other and when run in Sheetcam simulation it does just fine. I’m cutting 14 ga mild (slightly rusty) with a Razorweld 45 at 32 amps. THC is on. Also, the pierce delay seems wrong but after compensating minus 1% in Fire Control the interior cuts are incorrect. Thank you AGAIN for help!!

Do you have a picture of the failed cut?
Does the same thing happen in a dry run?
Can you attach the gcode and/or the .job file (will need to zip first)? You should just be able to drag and drop it into the reply window, or select the up arrow icon in the reply window to attach.

blade1.tap (2.8 KB)

Yes, I believe it overlapped in the dry run. Thanks

Sorry, not the job report. Here is the job file.
blade1.zip (4.7 KB)

There is nothing in your generated gcode to cause what you describe.
You can load it into a viewer here https://ncviewer.com/
There are only 3 moves (rapid G0 in xy) between cuts and all of them correspond to the pierce points shown in Sheetcam.

Your pierce delay seems a bit short, for my hypertherm I’d be at 0.5 to 0.7. I wouldn’t think that would be cause, instead you would get an error.

Are you using the Firecontrol rotate or scale feature?

One possibility is that your X Axis is slipping on the move from the first to the second cut. However I would expect the first cut to be messed up and I wouldn’t expect the outer one to complete successfully if that were the case. Does it behave the same every time? I would try a number of dry runs. Do they all do the same thing? I’d also check the motor connections. I would expect the behaviour to be a bit more random if it were a lose connection but might as well double check.

1 Like

I’m not rotating or scaling. When cutting a single outline it works fine. Any addition “inside” of that outline is what’s not registering properly.
I checked motor connections and X axis screws.
It seems to be an issue in Fire Control misinterpreting the g-code?? I have run various TAP files and whenever there is more than a simple outside line is when the problem appears. Would it tell us anything if I reproduce the same file but change the 2 inner shapes to a separate layer?

There is nothing in the gcode that looks suspect. The proper moves are there. It’s a pretty basic gcode file.
Does it do it when doing a dry run?
Are you using 20.6.2 of Firecontrol?
Does jogging work without issue?

Here’s a simple program that moves to each of the pierce points from your tap file above and pauses for 5 seconds, then returns to 0,0. It doesn’t turn on the torch. Just moves at rapid speed to each pierce point. Save it in a text editor as test.tap. Does this work? Make sure your z is raised, zero, then run.

G90 G94
G17
G20 (Units: Inches)
H0
G0 X3.1557 Y1.0316
G4 P5.0
G0 X9.4533 Y1.5119
G4 P5.0
G0 X10.1809 Y2.3004
G4 P5.0
G0 X0 Y0
M5 M30
(PS110)

1 Like

Thank you for the help Greg! I will try more dry runs in the morning. Firecontrol is 20.6.2 and jogging works fine. I’ll also give the test.tap a run tomorrow and report back. THANKS!

Hi Greg - I loaded your dry run file and Fire Control warned it was post processed on an old version (v1.6) but will convert file to current v20.6. Ran file dry and while the torch head moved 4 times and paused 5 sec at 3 points it did NOT move more than 3" x or y overall. The shape was W-10.18" by H-2.30" on the screen but strangely it didn’t jog anywhere near the full x or y distances.
I then ran a new version of the exact file (originally posted) that had the 2 inner shapes but this time placed these shapes on another layer. Sheetcam ran it fine in simulation. Ran it dry on machine and the SAME overlap of inner shapes happened. FRUSTRATING!
FireControl is v20.6, Crossfire v1.21s, THC v1.10.
FireControl seems to be cooperating with the outer shapes but not understanding any inner shapes. ANY IDEAS? Thank you!

I wouldn’t expect moving the cuts to different layers to have any effect. Like I noted above, the gcode file is pretty basic, and I don’t think it’s anything you have done. Your problem seems to be when there are multiple rapid moves in X/Y. I’m not sure what could cause a problem with rapid moves. I’d contact support with your problem and what you have tried.
@langmuir-daniel @langmuir-mike

I put in a support request with this topic linked. Thanks for the help Greg!
As an aside, the ncviewer site is a good resource. Have you found a way to slow down the speed at which the code runs or is it WYSIWYG?

If you click on the gcode text, then use the arrow keys, you can step through it line by line. You can also jump around by just clicking on a line. Just be aware that not all gcode lines result in movement.

Update - No solution has been determined yet. The motor couplings/lead screws are aligned and tight. All cables are seated properly and tight. I have run test files in Sheetcam simulator as well as ncviewer they all ran fine. The issue continues and I would like anyone reading this to throw out an idea as to why this may be happening. It’s very frustrating to not be able to generate a finished product on a new machine.
Again, while I continue to work with a Langmuir tech any ideas are greatly appreciated from forum members! Outside cuts = fine. As soon as I introduce shape(s) anywhere inside of the outer shape the torch will not jog the corresponding x or y distance inside, not even close. I can cut straight lines on the x or y axis without issue in test mode. Mind boggling! Any help?? Thank you!!
@jamesdhatch @langmuir-daniel @langmuir-mike @anybody

can you post a pic of the issue?

If you look at the original post picture on top you can see the outside shape and 2 inside smaller arrow or chevron shapes. The file calls for the 2 inner shapes to be cut first and then jog to cut the larger outside shape. It will not cut the inside shapes in the correct locations and when it jogs to the outer main shape/line it goes “off course” and most importantly, it only jogs 2 - 3" at most . That’s even on a shape that may be 10" wide. I have tried separate layers to no avail. I have run over a dozen basic files with various configs to no avail. The G code is cycling properly but it’s communication out of FireControl (fullu updated) is not matching input. A simple example…12" x 6" rectangle with a 2" circle placed inside this rectangle on dead center. The torch will jog to cut 2" circle and then proceed to jog to rectangle but will travel only a couple inches. It will often cut a straight line thru the circle since the distance of travel is so minimal. Also, it forget the location of the zero I set previously so if I tell it to go back to zero it goes anywhere but zero. Thanks!

I sure hope you are running all these test in dry run. There’s no point in wasting metal until you can get past a dry run with plasma off. That also helps narrow the potential sources of error (plasma interference). Given that the simple test I gave you failed, there’s no point in wasting your time with all these other tests you are doing. There is nothing magical in Sheetcam that will fix the fact the machine will not make 3 basic rapid moves successfully.
Keep the tests as simple as possible.

Here is another simple test which might give a clue. It does rapids (G0) only in X, then only in Y, then some in both X&Y at the same time.

Place a piece of metal under it, each time it pauses use a marker to mark the torch location, you don’t need to be exact. When done double check the marked positions with a tape measure to see if they are close.

raise Z, Zero, turn off plasma, then run.

(v1.6-sc)
G90 G94
G17
G20 (Units: Inches)
H0
G0 X3.0
G4 P5.0
G0 X6.0
G4 P5.0
G0 X3.0
G4 P5.0
G0 X0.0
G4 P5.0
G0 Y3.0
G4 P5.0
G0 Y6.0
G4 P5.0
G0 Y3.0
G4 P5.0
G0 Y0.0
G4 P5.0
G0 X6 Y6
G4 P5.0
G0 X2 Y10
G4 P5.0
G0 X0 Y0
M5 M30
(PS110)

You should see it move to X=3, then X=6, then X=3, then X=0, now only in Y Y=3, Y=6, Y=3, Y=0, now both axis at same time: X=6, Y=6, then X=2, Y=10, return to origin X=0,Y=0

From what you have said of the previous failures I would expect it to fail in one of the combined X,Y moves (6,6 or 2,10). But I’m curious if it is the combined rapid that causes the failure or if it is just the second rapid that causes the problem. That’s why I’m having it move in just X and Y then both.

2 Likes

I just saw this post Greg and will run the code today and let you know the results. Thank you!

btw: I noticed last night that when manually jogging the carriage head on the X axis at 300 ipm the lead screw would turn but the carriage head remained in one spot. Any other speed is fine and jogs left/right with no problem. I’m not a fan of using 300 ipm and most of my cuts have been <150 ipm so this is the first I noticed this. I believe the default continuous jog speed is 300 ipm so I should have noticed.
When Z-axis tramming during the build everything was to specs so I’m wondering if this issue could be causing a problem during rapids? Are X axis rapids approaching 250 - 300 ipm? The lead screw/motor coupling is still tight and has not slipped. Have you seen this at 300 ipm? Thank you!

I think you are on to your problem.

FYI - There are two types of moves in CNC. Rapids (G0) and those done at Feed rates (G1). Rapids will move as fast as the machine has been configured to move. Feed moves at the last designated feed rate (FXXX where XXX is the feedrate). So even though you program a cut at 150 IPM, the moves between cuts are done at rapid (G0) speeds. For the CrossfirePro the max speed is 300 IPM which will equal the rapid speed. So the fact you can ‘reproduce’ the problem jogging at 300 IPM is reassuring, it means you are on the track to finding the problem.

Now if the motor AND screw are turning but the axis isn’t moving that would point to a stripped nut, but then I don’t understand how it moves at slower rates. Are you sure the lead screw was turning? In any case I would take a closer look at your nut on the X axis. Maybe the nut is rotating in the housing at the higher speed???

1 Like

I am heading to the shop NOW and will have a good look at this. More in a little while! Thanks!!

Just looking at the code to rapid X3.0 the display does it but the carriage/torch didn’t move an inch! None of the X’s went more than an inch. The Y’s went to the correct distance but because the X’s were off they were not near the intended locations. Definitely an X problem.
Looking at the nut…it’s plastic I think. It looks fine, no cracks and snug. Jogging the X now still works fine at all speeds EXCEPT 300 ipm. It starts but binds. On what I can’t tell. the lead screw is fine, motor coupling still tight on my marks. Makes no sense to me…
Is there a way to change the default rapid speed to 200 ipm and override FireControl? Would that change anything other than overall longer job time…which at this point I would accept. Could the motor not be strong enough to spin the larger lead screw at 300 ipm? Thank you!!