Workbee - precision

Looks like a ton of backlash to me. The straight lines are where the y axis is moving before the x axis has "re-caught" its lead nut.

Hmm, interesting. Probably good settings to stick with for now. And yeah, stepper motors make some crazy noises, sometimes it's hard to tell the difference between healthy noises and bad noises with those little StepStick chopper drivers, hahaha.

The 1000 and 100 points are great, the 501.8 is... Disappointing. You may need to do a really thorough map test for the axis, because I'm wondering where the issue is happening and then going away again. Calibrate your steps/mm to get exactly 1000.0mm on command, then do sets of shallow cuts every 100mm, making sure it returns exactly to your zero position every time. So you end up with a table:

Distance | Actual Cut 1 | Actual cut 2
100______|______________|____________
200______|______________|____________
300______|______________|____________
400______|______________|____________
500______|______________|____________
600______|______________|____________
700______|______________|____________
800______|______________|____________
900______|______________|____________
1000_____|_1000.0______|__1000.0___

Maybe then we can start to get a handle on where the non-linearity is happening.

What's your current acceleration setting? For a belt-driven system at 24V-48V, you should be able to get it up to pretty high numbers, 5000mm/s^2 maybe. I'd try and get it up to at least 1000, because the distance it's taking to get up to speed is messing with the numbers we're getting, I suspect.

Since you already said it was returning to your zero each time (when Alex was thinking backlash, I assume), I'm less inclined to think missed steps, too. Because it would miss steps on both the forward and return trips and end up back at say, 1.2mm instead of 0mm. I'm at a bit of a loss for now. All I can think is to try a different controller (flash an Arduino with Grbl real quick, say).

 

The thing that has puzzled me is that the error rate has increased with distance travelled (not the actual error - I would expect that to increase, but the error/mm of travel) In a theoretically perfect system the error/mm should be constant (5 times as many steps to travel 500 mm as 100mm). If it was just a calibration issue the error/mm for each distance should be the same. If it was missing steps I would expect the error/mm to be inconsistent. Although the second set of data is closer to the desired outcome (more accurate) the first set is more linear.
Look forward to seeing tomorrow's data, but please tell us what you are changing @Benjamin Vg - it helps us understand what is happening.
Alex.

 

@Rob Taylor So the problem is in the X axis not the Y axis?
Thanks for the help. I will check all of the anti-backlash blocks.

 

Check the eccentrics on the X axis as well.
Alex.

 

@Alex Chambers Thanks, that was the first thing I checked and they are all good.

 

@Benjamin Vg definitely interesting as my machine (same as yours) gives random anomalies like this aswell

 

Hi Benjamin, I have looked at your G code file and there are some aspects of it which look a little odd. Could you please let us know what software you used to create this? (G17 is not recognised by the Duet, M3 turns your spindle on, but your machine is not set up to use this. The feed rate at 3600 is very high.

Alex.

 

I was going by the carbide speeds and feeds chart which recommends 2540mm/min feed at 19700 spindle speed for plywood.
Alex.

 

What post processor did you use? - it should have been this one; GRBL (mm) (*.g-code)

There is also a T1 call in your g code - an instruction to use tool number one, which the workbee doesn't need.
There are also no arc codes (G2) which the Duet can support - your code is all straight lines.
Alex

I am not familiar with Aspire, so I don't know for sure what G code vectric software should produce..

 

I don't have any vectric software (can't afford it) so I was a bit puzzled by those bits of g-code I mentioned, and I am surprised that vectric doesn't do arcs. As the file ran those codes must have been ignored.
Having said that I don't think the g code was the cause of your problems with those P clamps. I assume that you used the Duet Web Control to upload your g code file and run it?
From the picture it looks as though two of the p clamps are bigger than the others, but they don't seem to be in your g code. EDIT - just looked at your g code in a simulator and those two are bigger.
Is your router cable well away from any other wiring?
Given the problems you have been having I suggest not asking your machine to work too hard - reduce the feed rate to 2000 or even 1000 and use a router speed of 19000/20000 - 3.5 on the Makita speed dial.
Alex.

 

After going through and tightening screws and correcting the backlash problems I have a circle. It measured 50mm diameter as it should. The couple of small abnormalities are due to me
smashing the Sharpie head into the spoil board and the fact that I have it mounted in my spindle and it rotates as it draws. Let me know what you all think and thank you again to @Rob Taylor and
@Alex Chambers for their suggestions.

 

Now you just need to cut one with a really pointy bit.
Alex

 

By the way @Benjamin Vg, that Duet G code site is very useful - I use it all the time, but you need to know that some of the things Ooznest have done with their firmware do not match what that site says. In particular Ooznest use G54 as machine co-ordinates (standard is G53) and unlike G53 it is modal - that is if you send G54 to your Duet it will stay in that co-ordinate system until you change it (G53 only applies to the line of g code it is on. Workplace co-ordinates for the ooznest Duet is G55 (would normally be G54). This means that if you select machine co-ordinates in Duet Web Control it will stay in that co-ordinate system until you select workplace co-ordinates.
Alex.

 

Hi @Benjamin Vg,

-> Are they some other/better tools I can try for it - for the Duet controller no.

Is your router cable well away from any other wiring? - it's important to keep any mains wiring well away from any low voltage wiring - interference can cause all sorts of weird problems (you probably knew that)

but on the bottom left it was really as if he "forgot" to move up the router before moving - that and the mis-positioning of the two clamps on the right was why I suspected interference

-> What is the purpose of those changes wht did they do that? Does it have an impact of the g-code product by my CAM software? - most hobby cnc machines use the grbl subset of g-code. The Duet uses the rep-rap subset (developed for 3D printers as was the Duet) It shouldn't have an impact on your g-code as long as you use a post processor that has been written for the Duet - you are correct to follow the recommendations on the Ooznest site. I think the reason why Ooznest use "non-standard" machine and workplace co-ordinates is because the way the Duet used G53 was a bit odd to start with (I believe that may have changed now)

What software do you use with your machine in place of vetric? - I use Fusion 360 - it is complex and takes a while to learn, but very powerful. Another alternative is Sketchup - search the forum and you will find references to where you can download it if you are interested. There is a plug-in for Sketchup for generating g-code, but I don't know how compatible that is with the Duet because I haven't used it. I have asked a friend who uses Vectric software for some example files to check that the g-code output you got is the best that it can do for the Duet - will let you know later if there is anything different you can do.

Alex