Odd arc behaviour

MJLew

@dukemachine There were some problems with arc commands that were fixed a good while ago. You probably should say which firmware version you are running.

I've looked at the gcode and it looks fine in ncviewer (put a G21 in at the start to convert ncviewer from inches to metric dimensions: https://ncviewer.com/). From that inspection I can see that the kink in your photo corresponds to a G2 command, and the subsequent G3 seems to have worked perfectly well. Is the corresponding G2 on the other side of the shoulder also kinky? If not then I would suspect that there is a mechanical problem.

DukeMachine

@mjlew Thanks for taking a look!

Well M115 reported the following:
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.3 ELECTRONICS: Duet 3 MB6HC v1.01 or later FIRMWARE_DATE: 2021-06-15 21:45:56

The other G2 commands seem to be behaving fine. I originally suspected it might be a mechanical issue, but this is the second cut its happened in, and it doesn't happen in the same spot on the X axis, and its suspiciously consistent (i.e. in the cut, it occurs at the same point, but not the same point between cuts). Belts are tight, pulley set screws are tight, its not binding so

DukeMachine

Well for anyone looking at this one I have a temporary fix anyhow:

I disabled arcs in my post processor (no G2/G3 commands) and my output is as expected.

o_lampe

Now I'm concerned.
I use RRF3.3 too and have ArcWelder as postprocessor in my slicer.

Can anyone confirm it's a RRF bug, or does it depend on the postprocessor?

Catalin_RO

@o_lampe As long as the GCode file can be opened with various viewers (I have myself tested it with a very old, mostly GRBL tool - Candle and with the PlanetCNC application in demo mode) and it looks OK it can be only a problem with RRF.

But, also, I wouldn't rule out a mechanical issue even if disabling G2/G3 commands in the postprocessor gives correct results, especially because it is a belt-based machine. While splitting in the postprocessor the G2/G3 commands in small straight lines might seem identical to what RRF is doing, the simple fact that those lines have different lengths may change the behaviour of the machine.

I have myself started years ago with a ShapeOko clone and then moved to the original WorkBee. Both pretty decent machines if all possible problems where considered when generating the GCode - both machines where technically backlash free (impossible to determine/measure backlash in the belts/screws), but with other crazy "degrees of freedom", all related to the wheels solution.

As a simple comparison, with both machines I broke quite a few 3mm cutters when going just 500mm/min at 0.2mm depth. With the QueenBee I did machining at 1200mm/min, 0.5mm depth with a 2mm cutter!

Phaedrux

Can you test with the 3.4 beta found here?

https://www.dropbox.com/sh/i5vox3xmkd55gaz/AAC19mI0WEC5GmEjLOBRbKs-a?dl=0

DukeMachine

@phaedrux I’ll give it a shot tomorrow and report back. Thanks!

dc42

@dukemachine any news?

DukeMachine

@dukemachine my apologies life got a little busy. Will try it today.

DukeMachine

@dc42 so just tried it, and it doesn’t seem to have alleviated the issue

DukeMachine

I think I ended up narrowing down the issue. My apologies as it seems to have been setting related (I was driving my new NEMA23 way too fast according to the reprap firmware EMF calculator), I backed off the maximum speed and my problem seems to have resolved itself. Thank you all for your suggestions and help.

dc42

@dukemachine thanks, I'll mark this as resolved.

alankilian

@dukemachine said in Odd arc behaviour:

(I was driving my new NEMA23 way too fast according to the reprap firmware EMF calculator), I backed off the maximum speed and my problem seems to have resolved itself.

Thank you for keeping up with this problem.

It will surely help someone else in the future.

Congratulations on getting your system tuned and running well.