Controlled arc problem
-
@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
-
Yes, please try firmware 3.2RC2.
-
@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 -
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.
-
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
arc.g
squaretest.g -
Your 'squaretest' file has only G1 moves, right? Are you sure you aren't missing steps due to a mechanical or electrical problem?
-
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:
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?
-
@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 -
@cjm just seen your post - many thanks I will try it out tomorrow.
-
@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 -
@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
-
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.
-
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.
-
@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
-
Thanks folks for the opinions really appreciate independent advice! I will focus on the mechanicals and re-test the square / diamond combo.
Neil -
@droftarts said in Controlled arc problem:
Don't you mean 45 degrees?!
Ha ha.
Yes. Thanks for catching my lack-of-coffee posting.
-
@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 -
This seems like a big enough error that you should be able to measure it with a ruler.
Try:
g0 x0 y0
(Mark the position)
g0 x100
(Check to see if it moved 100mm)
g0 x0
(Check to see if it moved 100mm back)If there's a lot of backlash in the X mechanics, you'll see one or the other of those moves be less than 100mm
-
Dear all, thanks so much for the advice, the loose grub screw was the root cause which was definitely in my blind spot! Learnt a lot and really appreciate the support, looking much better now with some tweaks.
Neil
-
Hooray!! Glad you solved it!
