Consistent inconsistencies

I am trying to cut a pattern out of 0.8mm sheet steel from a design i’ve made in fusion360. The idea is two identical patterns, tig welded and inflated with a pressure washer to hydroform a 2stroke pipe.

The problem appears to be between the first cut, and subsequent cuts. The first cut is accurate, the second cut is off by about 10mm on one end of the pattern only.

After a reset and full recalibration, the results are the same. First cut is accurate, second and subsequent cuts are all off by exactly the same amount.

I’ve tried to upload both images of the issue and the gcode file but “new users cannot attach files”

There are no radius moves in the gcode, it is all purely X,Y coordinates.

Everything is leveled, calibrated, and the problem is repeatable. Even after a firmware update of both the screen and the machine, results are identical.

Also, square cuts come out more of a trapezoid than square. Not by much, maybe 1mm skewed over 60mm. Every time.

I’m just about through an entire sheet of metal so I’ll grab some sheets of paper and a pen and try reproduce it that way.

Any thoughts?

The above pics are 4 cuts stacked. The top two are identical, the lower two are identical. No changes to any settings inbetween.


4 back to back tests with pen and cardboard with zero issues. Tested with the lightning symbol enabled and disabled. The trace matches up exactly with the first metal cut.

This would suggest the issue presents only when the Unimig Razorcut 45 is in use? or more precisely, after it has been used as the start and stop points are correct on the first cut.


This is the second metal cut overlaid on the cardboard pen trace.

It is clear that the first cut starts and stops where it should. After replacing the metal with a fresh sheet and hitting play, it is clear the start point is offset down and left before the arc is even struck, eliminating the possibility of interference causing this.

This occurs with and without zeroing between sheets.

I don’t think it can be an encoder/stepper issue as the offset would be consistent throughout the whole cut, not just the first and last 100mm or so.

This pattern is 660mm wide. Can the arcdroid cut beyond 660mm? or does it scale and compress the pattern to fit?

Hey mate, I use the unimig razor cut 45 with mine and no issues . I would suggest going through your calibration again and make sure to clamp the triangle down and put a 1" piece of wood in between the arcdroid and calibration triangle, just spaces the calibration jig a bit further out and makes it easier so you don’t have to bring the arm right up to the arcdroid when doing the calibration .

Thanks for the suggestion. I’ve calibrated this thing a half dozen times already but I’ll try it with a 1" spacer and see how that goes. It’s not that it’s inaccurate, It’s very accurate when it works the first cut after a reset.

OK so I’ve found out what is happening during the bad cuts, but not exactly why.

There are two calibrations, one for the torch and one for the pen. They differ the most on the far right of the table and are almost identical on the far left due to the arm geometry.

When you plug the pen into the arcdroid, it changes the calibration to the pen cal which offsets a variable amount depending where on the table the droid is pointing to.

This pen calibration follows the bad cuts I’m seeing. Plugging the pen in will make the green locator on the screen jump to the bad cut profile, removing it jumps back to the good cut.

Something is causing the machine to use the pen cal when cutting with the torch even though no pen is attached to the system.

I suspect if I perform both calibrations with the torch, even if the pen cal is triggered it’ll still accurately cut, though I’d loose the pen functionality. I recall seeing a youtube video recommend calibrating using only the torch to fix linearity issues.

Arcdroid support has written back to me suggesting I check table/droid/unimig earths are all tied together. The table and unimig earths are connected but there is no earth connected from the mains socket to the droid and it relies on metal to metal contact though the base, which isn’t happening here due to the powedercoated base. I’m waiting back for them to tell me to grind the paint off the base of the droid to earth it to the table.

Also, looking at the marlin source code which the arcdroid is based on, there was an update which fixes offset errors which I think is exactly what is occuring here. I’m not sure how up to date the marlin code in the arcdroid is.

So! next step will be to re-calibrate without the pen and just the torch and ground the droid to the table and hopefully my repeatability and accuracy issues should be solved. Loosing the pen input isn’t ideal but until there’s a firmware update there’s not a lot else I can do. It could also be the 3.5mm socket internal switch is faulty triggering pen mode, or the difference in grounds triggering it.


and to prove my theory, here’s the same pen test with the pen plugged in. So we know what its doing but not exactly why

Hey mate I did this post on how I did my grounding , thought it help. Just type Gqhoon in search and click on “self deleting trace file” and scroll down to the post

Thanks @Gqhoon I’ll run a cable from the droid back to my earth stake. I’ve had someone email me saying under no circumstances should you ground the arcdroid. That doesn’t sound quite right and I’m sure i’ll hear back from Andrew and the team today about it.

Every time iv had an issue the first thing Andrew or Ken ask is if the machine is grounded properly .

I havent had that issue, but I was thinking for accuracy it would make sense to mount the pen at the same distance out as the torch.
It would also prevent issues of one reaching near the end, but the the other not reaching.

I also have a oxy fuel torch that i mounted the same so no need to recalibrate when switching