Hello, Here is the test results of the day... I have setup to 4 microstep and a speed of 1000 (default one was 10 000) because when I use only 1 microsteps the motor's noise is very very strange with a lot of vibrations. 4 microsteps and a speed of 1000 real cut two passes of 1mm each Therorical distance: 100mm Practical: 100,2mm Therorical distance: 500mm Practical: ~501,8mm Therorical distance: 1000mm Practical: ~1005mm
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).
I have unmounted my belt and examine it very carefully qithout seeing anything suspicious. I have also switched the motors as proposed by Alex. I have rerun the test after a bit of calibration (because I have moved a little bit the belt I guess) it was M92 X13.363 and now M92 X13.383. Now the same test give me Distance | Actual Cut 1 | Actual cut 2 100______|_100,12 ________|____________ 500______|_501,5 _________|____________ 1000_____|_1004__________|____________ Be aware also that I have the best precision of the measure of the 100mm is the best one because I am able to measure it with my caliper after that I use a standard meter and estimate the tenth of mm so of course not as precise at all. The test result for every 100mm is comming (execution right now)...
Since the motor switch are the belt check it looks a bit better finally. But first forget the measures of my two previous post because I have used another meter than usual and as you see below sometimes 10cm is not equals to 10cm.... This meter is really bullshit... so i used another one and i have measure it with my caliper this one is correct. remark, this only invalidate my two posts the other one have been measured with a correct tool not made in wood. Anyways now I think that I am close to the solution. Here are my measurements. (I have adjusted a little bit the parameter between the two measurements. Distance | Actual Cut 1 | Actual cut 2 100______|_100,25 _______|_100 ______ 200______|_200,5 ________|_200,2 _____ 300______|_301 _________|_300,3 _____ 400______|_401.5 ________|_400,5 _____ 500______|_501,8 ________|_500,8 _____ 600______|_602 _________|_601_______ 700______|_702,3 ________|_701_______ 800______|_803 _________|_801,8_____ 900______|_903 _________|_901,9_____ 1000_____|_1003.5 _____|__1002,5___ So it looks almost linear now. But I cannot say what have really change...
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.
Although it doesn't appear to be the case here, what is the diameter of your endmill? If it is supposed to be 6 mm, but in reality is 5.9, your 100 mm square will be larger than 100mm. I measure the diameter of every endmill I use and input that into my CAM software. I have yet to find an endmill that is the claimed diameter. Most are slightly smaller.
Good to know I will measure it tomorrow... the one I currently use is a CMT so it is suppose to be a good brand.
@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.
Hello, I think I have it. Distance | Actual Cut 1 | Actual cut 2 | Actual cut 3 | Actual cut 4 100______|_100,25 _______|_100 ______ | 99.7 | 99.8 200______|_200,5 ________|_200,2 _____ | ? | 200 300______|_301 _________|_300,3 _____ | ? | 300 400______|_401.5 ________|_400,5 _____ | ? | 400 500______|_501,8 ________|_500,8 _____ | ? | 500 600______|_602 _________|_601_______ | ? | 600 700______|_702,3 ________|_701_______ | ? | 700 800______|_803 _________|_801,8_____ | ? | 800 900______|_903 _________|_901,9_____ | ? | 900 1000_____|_1003.5 _____|__1002,5___ | 999 | 999.8 About the M92 configuration parameter, Cut | Parameter Value Actual Cut 2 | 13.383 Actual Cut 3 | 13.25 Actual Cut 4 | 13.337 But I didn't found a formula who match my result exactly the formal is supposed to be simple. About the changes I did: Switching the two motors Unmount and remount the belt so the strech is not exactly the same Changing the M92 parameter Something is sure is the fact that my Z-axe is not correct either but I didn't have tried to calibrate it for the moment... As a test I have tried to execute the attached file who looks correct when I in NC Viewer // GCode Viewer and Machine Simulator But the result is really really strange I had to stop this test! What did I have done the wrong way? I will try to reexecute some square tests tomorrow... Regards, Benjamin
@Benjamin Vg definitely interesting as my machine (same as yours) gives random anomalies like this aswell
I have found this on the duet site: Microstepping set too high. If you set microstepping too high, the processor may not be able to generate step pulses fast enough. If this happens then high speed moves may be jerky. To check whether you have microstepping set in a reasonable range, execute some long high speed moves, then run M122 and look at the MaxReps figure in the report. This value should be kept below 100 and preferably below 50. Source: Jerky movement when printing But they speak about 50 microsteps I have 16 in Y and 4 in X so I am not sure if this is the cause of my problem...
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.
Not for a belted machine, on a BlackBox and my 1500mm Ox with GT3 belt I can get 7000mm/min with a 3000mm/s^2 acceleration Would you ever consider building a second CNC? If yes, may I maybe suggest grabbing a BlackBox as a test. If it doesnt solve this issue, you already have a controller on the shelf for your "second CNC" - this hobby tends to that to most of us, not long and you'll want two, three, more more machines for your robot army. A plasma, a mill, a laser, who knows (i'm sure even at minimum wage you've spent more time on this than a BlackBox costs) I am not saying it will solve this issue, at all, but at least it gives you an easy thing to swop in and see if it improves: We use decent 4A Max drivers, set to 1/8th by default, extensively tested to be able to run NEMA23s all day long. Silent Drivers it does not have, but is noise, or reliability the issue you want to deal with (; Now of course, huge chance you get one and still have issues - but then we 100% know its mechanical...
I was going by the carbide speeds and feeds chart which recommends 2540mm/min feed at 19700 spindle speed for plywood. Alex.
@Alex Chambers This code have been generated by Aspire. I didn't really have investigate the best cnc software for woodworking yet. I am use to use Sketchup but the cnc plugins are not very good in my opinion...
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 have checked and yes the Post-processor is Grbl (mm) (*.gcode) and that is what they use in the ooznest videos (program and post-processor). I guess that the not knowed code are just ignored right? And the M3 command looks handled by duet if I read the documentation here: Gcode but if I could really use this command it could be really great btw... I guess that the G2 command is alsodocumented here: Gcode T1 command is also present in the same doc: Gcode
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.
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.
I assume that you used the Duet Web Control to upload your g code file and run it? -> Yes I do! -> Are they some other/better tools I can try for it Is your router cable well away from any other wiring? -> Yes and I was present at the moment of the issue that wasn't because of a wire in the path or something 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. -> Ok I can try to change it but I am pretty sure that it wasn't the issue here because I only do 2mm passes and it was the case everywhere but on the bottom left it was really as if he "forgot" to move up the router before moving About the ooznest firmware -> 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? What software do you use with your machine in place of vetric?
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