Controlled arc problem

alankilian

@neilo I ran your GCODE in this simulator (The only one I know that simulates arcs correctly) and it looks right.

https://nraynaud.github.io/webgcode/

G0 x25 y0
G2 X0 Y-25 I-25 J0

Try smaller arcs, a complete circle, some G1 moves etc, or first move the head to a different position to get some more information.

dc42

Which firmware version are you using?

whopping pochard

I have nothing to contribute to this discussion, except that the title makes me think of my many feeble attempts at welding...

neilo

@dc42 Hi there I'm using RRF 3.1.1. Is it worth giving the latest version a go? (3.2)

@alankilian I'll try some other moves in the meantime today

Cheers

dc42

Yes, please try firmware 3.2RC2.

neilo

@dc42 sorry it's not clear to me whether I can go direct from 3.1.1 to 3.2 RC2? The RC2 release notes say the iap files have not changed since RC1 but cannot see them in the RC1 area to copy across.

Also RC1 notes state: "Users of Duet + Single Board Computer should upgrade from the packager server as usual." Not clear to me where/what the package server is!

Thanks,
Neil

Phaedrux

https://github.com/Duet3D/RepRapFirmware/releases/tag/3.2RC1

There are 4 files with SDiap32 in their names.

https://duet3d.dozuki.com/Wiki/Getting_Started_With_Duet_3#Section_Software_Installation

You can find the instructions for adding the unstable branch package server here.

neilo

Thanks very much for your assistance, the good news is that the firmware upload (RRF3.2RC2)went fine, the bad news is that the mis-behaviour is still present.
For example a simple square is not completing (fig 1)
or a sequence of simple moves (fig 2) .
This time I've uploaded the config and gcode files for the above if someone could please spot the deliberate mistake config.g
arc.g
squaretest.g

whopping pochard

Your 'squaretest' file has only G1 moves, right? Are you sure you aren't missing steps due to a mechanical or electrical problem?

cjm

@neilo

I've used a Duet 2 board running RepRapFirmware for Duet 2 WiFi/Ethernet 3.2-beta1 (2020-09-15b1) with a homebrew CNC to machine a test piece containing diamond, circle and square sections:

The g-code for this with a 5mm diameter end mill is as follows and contains both G2 and G3 commands that the Duet appears to have executed correctly:

SquareDiamondCircle 42mm.g

The finishing passes for the circular section are complete circles so one assumes should have shown up the same sort of error you're seeing if this was intrinsic to the Duet hardware/firmware?

Perhaps trying this g-code file might help diagnose the problem?

neilo

@whopping-pochard that's right just trying to keep it simple with G1 commands in one file. I've added another test (fig 3)
and it appears to act erratically. Mechanically it looks fine, it's belt drive on X and Y NEMA 23 FYI .
steps.g

neilo

@cjm just seen your post - many thanks I will try it out tomorrow.

neilo

@cjm here is the result: Still looks weird and clearly incorrect. I used a 1/4 inch bit so slight dimensional difference but does not explain for me the strange behaviour.
Would you mind sharing your config.g file with me please?

Thanks,
Neil

droftarts

@neilo I think this is a mechanically issue. My best guess is that the X pulley is slipping on the motor shaft, because the first move of any change in direction in X causes the movement error, but subsequent ones do not. Probably the grub screw on the pulley is loose, allowing a limited range of movement.

Ian

sonderzug

I second @droftarts opinion; circles with horizontal and vertical flat spots (i.e. corresponding to the direction change of the x respectively the y axis) indicate mechanical backlash, quite noticable in your case.

alankilian

One way to test this theory is to make a square, but rotated 90-degrees.

That way, you get two reversals of each axis while the other axis is moving continuously in the same direction.

You'll see the vertices get messed up if you've got a lot of backlash.

AND you can do it with just G1 moves.

droftarts

@alankilian said in Controlled arc problem:

One way to test this theory is to make a square, but rotated 90-degrees.

Don't you mean 45 degrees?!

Ian

neilo

Thanks folks for the opinions really appreciate independent advice! I will focus on the mechanicals and re-test the square / diamond combo.
Neil

alankilian

@droftarts said in Controlled arc problem:

Don't you mean 45 degrees?!

Ha ha.

Yes. Thanks for catching my lack-of-coffee posting.

cjm

@neilo The behaviour does look odd.
It is interesting that some of the part (e.g. the upper left quadrant) is machined OK over multiple layers.
As mentioned by others, this implies something is loose, perhaps a drive block, so that when the axis is driven in one direction the slack is taken up and the movement is controlled, but when there is a change of direction, the slack needs to be taken up in the other direction before movement control is restored. i.e. backlash, but with much more movement (around 4-5mm by the looks of the part) than normal.
With the spindle/router powered down and unplugged for safety, if you send the machine to XY coordinates in the middle of its range and then manually try move the spindle/axes carriages in X and Y directions what do you feel?
Everything should be tight, with no knock or play.

I'm not sure it will help but as requested here's my config.sys file:
config.g