Jerky movements, again
-
I can't see any difference in the movement between the first two videos but maybe that's because I'm an old guy who wears glasses. You seem to be trying to make videos that record the sound, so are you saying that it sounds different?
Yes, that's what I want to say. English is not my native language so sometimes I cannot say what I want in few words so other people can understand me.
Can you hear clicking (5-10 times per second) sound on last video with black picture? This clicks are felt, if I touch a finger to the carriage. This feels like tower caret stops moving for few milliseconds and then starts moving again.
But there is no any clicks or other sounds then I change microstepping to 1/256. Everything else is the same - maximum jerk settings, accelerations, speed, motor currents and so on.
-
I ran roboduet's file on my Rostock Mx V2 and can confirm that there is a different sound as he describes.
However, I also ran print tests and cannot see any difference in the results! So, to me at least, this appears to be of academic interest only.Thank you very much! At least this is confirmed now by other people too.
As about differences in print quality - I can see slight differences in external surface, but I'm sure this is absolutely not a problem for me. I can try to find macro photo friendly plastic and right lighting to take photo with differences. Also I'm not sure what is affecting print quality - true 1/256 microstepping instead of interpolated 1/16 or this clicking issue.
-
The interpolation is only completely accurate when the carriages are moving at constant speed, which is rarely the case on a delta printer. So my guess is that the clicking noises are produced when the drive gets the interpolation wrong, perhaps when a carriage reverses direction in the middle of a move. Dynamically varying microstepping will solve that, when I get round to implementing it.
-
I hear this clicking sounds with interpolation disabled at 1/16 microstepping.
Also seems like I found bug, printer completely freezes (including ESP8266 web server code) then I executing this commands: [c]G28[/c] to home printer, [c]M350 X16 Y16 Z16 I0[/c] to disable interpolation (interpolation enabled in config) and then start printing file without (!) homing after executing M350 command. This is reproducible every time I enter this commands.
-
I hear this clicking sounds with interpolation disabled at 1/16 microstepping.
Also seems like I found bug, printer completely freezes (including ESP8266 web server code) then I executing this commands: [c]G28[/c] to home printer, [c]M350 X16 Y16 Z16 I0[/c] to disable interpolation (interpolation enabled in config) and then start printing file without (!) homing after executing M350 command. This is reproducible every time I enter this commands.
I can guess what is happening. Executing M350 flags the axes as not homed, so for every move that your file asks for there will be a error message generated. The Duet will run out of message buffers, so it will no longer process status requests. Sending a pause command via USB or possibly PanelDue may still work. Or you can wait until the file finishes"printing".
-
So my guess is that the clicking noises are produced when the drive gets the interpolation wrong, perhaps when a carriage reverses direction in the middle of a move.
Just small note about interpolation and this clicks - linear (straight) movement of effector does not produce this clicks with interpolation enabled. At the start of first two videos effector goes down to Z = 10.3 mm at X0 and Y0 and then goes to start of circle at X-49.744 Y1.647. This straight move is without clicks.
To summarize my messages:
Moves with clicks: segmented (many g-codes with short straight lines) movement around circle regardless of interpolation mode at 1/16 microstepping.
Moves without clicks: straight movement with any microstepping setting or segmented movement around circle with 1/256 microstepping.
I will try tomorrow to create small script that produces straight segmented moves and slightly bent (extremely large radius) segmented moves to test how angle between two straight movement g-codes affects this.
-
I'm just created simple script that produces segmented (0.5 mm) straight movement from X-50 Y-50 to X50 Y50 and then goes back to X-50 Y-50 with single g-code:
[[language]] T0 G21 ; set units to millimeters G90 ; use absolute coordinates M83 ; use relative distances for extrusion G1 X-50 Y-50 Z10.300 F4800 G1 X-49.5 Y-49.5 F960 G1 X-49 Y-49 G1 X-48.5 Y-48.5 G1 X-48 Y-48 G1 X-47.5 Y-47.5 G1 X-47 Y-47 G1 X-46.5 Y-46.5 G1 X-46 Y-46 G1 X-45.5 Y-45.5 G1 X-45 Y-45 G1 X-44.5 Y-44.5 G1 X-44 Y-44 G1 X-43.5 Y-43.5 G1 X-43 Y-43 G1 X-42.5 Y-42.5 G1 X-42 Y-42 G1 X-41.5 Y-41.5 G1 X-41 Y-41 G1 X-40.5 Y-40.5 G1 X-40 Y-40 G1 X-39.5 Y-39.5 G1 X-39 Y-39 G1 X-38.5 Y-38.5 G1 X-38 Y-38 G1 X-37.5 Y-37.5 G1 X-37 Y-37 G1 X-36.5 Y-36.5 G1 X-36 Y-36 G1 X-35.5 Y-35.5 G1 X-35 Y-35 G1 X-34.5 Y-34.5 G1 X-34 Y-34 G1 X-33.5 Y-33.5 G1 X-33 Y-33 G1 X-32.5 Y-32.5 G1 X-32 Y-32 G1 X-31.5 Y-31.5 G1 X-31 Y-31 G1 X-30.5 Y-30.5 G1 X-30 Y-30 G1 X-29.5 Y-29.5 G1 X-29 Y-29 G1 X-28.5 Y-28.5 G1 X-28 Y-28 G1 X-27.5 Y-27.5 G1 X-27 Y-27 G1 X-26.5 Y-26.5 G1 X-26 Y-26 G1 X-25.5 Y-25.5 G1 X-25 Y-25 G1 X-24.5 Y-24.5 G1 X-24 Y-24 G1 X-23.5 Y-23.5 G1 X-23 Y-23 G1 X-22.5 Y-22.5 G1 X-22 Y-22 G1 X-21.5 Y-21.5 G1 X-21 Y-21 G1 X-20.5 Y-20.5 G1 X-20 Y-20 G1 X-19.5 Y-19.5 G1 X-19 Y-19 G1 X-18.5 Y-18.5 G1 X-18 Y-18 G1 X-17.5 Y-17.5 G1 X-17 Y-17 G1 X-16.5 Y-16.5 G1 X-16 Y-16 G1 X-15.5 Y-15.5 G1 X-15 Y-15 G1 X-14.5 Y-14.5 G1 X-14 Y-14 G1 X-13.5 Y-13.5 G1 X-13 Y-13 G1 X-12.5 Y-12.5 G1 X-12 Y-12 G1 X-11.5 Y-11.5 G1 X-11 Y-11 G1 X-10.5 Y-10.5 G1 X-10 Y-10 G1 X-9.5 Y-9.5 G1 X-9 Y-9 G1 X-8.5 Y-8.5 G1 X-8 Y-8 G1 X-7.5 Y-7.5 G1 X-7 Y-7 G1 X-6.5 Y-6.5 G1 X-6 Y-6 G1 X-5.5 Y-5.5 G1 X-5 Y-5 G1 X-4.5 Y-4.5 G1 X-4 Y-4 G1 X-3.5 Y-3.5 G1 X-3 Y-3 G1 X-2.5 Y-2.5 G1 X-2 Y-2 G1 X-1.5 Y-1.5 G1 X-1 Y-1 G1 X-0.5 Y-0.5 G1 X0 Y0 G1 X0.5 Y0.5 G1 X1 Y1 G1 X1.5 Y1.5 G1 X2 Y2 G1 X2.5 Y2.5 G1 X3 Y3 G1 X3.5 Y3.5 G1 X4 Y4 G1 X4.5 Y4.5 G1 X5 Y5 G1 X5.5 Y5.5 G1 X6 Y6 G1 X6.5 Y6.5 G1 X7 Y7 G1 X7.5 Y7.5 G1 X8 Y8 G1 X8.5 Y8.5 G1 X9 Y9 G1 X9.5 Y9.5 G1 X10 Y10 G1 X10.5 Y10.5 G1 X11 Y11 G1 X11.5 Y11.5 G1 X12 Y12 G1 X12.5 Y12.5 G1 X13 Y13 G1 X13.5 Y13.5 G1 X14 Y14 G1 X14.5 Y14.5 G1 X15 Y15 G1 X15.5 Y15.5 G1 X16 Y16 G1 X16.5 Y16.5 G1 X17 Y17 G1 X17.5 Y17.5 G1 X18 Y18 G1 X18.5 Y18.5 G1 X19 Y19 G1 X19.5 Y19.5 G1 X20 Y20 G1 X20.5 Y20.5 G1 X21 Y21 G1 X21.5 Y21.5 G1 X22 Y22 G1 X22.5 Y22.5 G1 X23 Y23 G1 X23.5 Y23.5 G1 X24 Y24 G1 X24.5 Y24.5 G1 X25 Y25 G1 X25.5 Y25.5 G1 X26 Y26 G1 X26.5 Y26.5 G1 X27 Y27 G1 X27.5 Y27.5 G1 X28 Y28 G1 X28.5 Y28.5 G1 X29 Y29 G1 X29.5 Y29.5 G1 X30 Y30 G1 X30.5 Y30.5 G1 X31 Y31 G1 X31.5 Y31.5 G1 X32 Y32 G1 X32.5 Y32.5 G1 X33 Y33 G1 X33.5 Y33.5 G1 X34 Y34 G1 X34.5 Y34.5 G1 X35 Y35 G1 X35.5 Y35.5 G1 X36 Y36 G1 X36.5 Y36.5 G1 X37 Y37 G1 X37.5 Y37.5 G1 X38 Y38 G1 X38.5 Y38.5 G1 X39 Y39 G1 X39.5 Y39.5 G1 X40 Y40 G1 X40.5 Y40.5 G1 X41 Y41 G1 X41.5 Y41.5 G1 X42 Y42 G1 X42.5 Y42.5 G1 X43 Y43 G1 X43.5 Y43.5 G1 X44 Y44 G1 X44.5 Y44.5 G1 X45 Y45 G1 X45.5 Y45.5 G1 X46 Y46 G1 X46.5 Y46.5 G1 X47 Y47 G1 X47.5 Y47.5 G1 X48 Y48 G1 X48.5 Y48.5 G1 X49 Y49 G1 X49.5 Y49.5 G1 X-50 Y-50
Update: also click frequency directly depends on frequency of g-codes, seems like this clicks going between g-code commands. Maybe something like fill of next command queue or read-ahead of g-codes freezing movements?
Example of low-frequency clicks with longer segments:
[[language]] T0 G21 ; set units to millimeters G90 ; use absolute coordinates M83 ; use relative distances for extrusion G1 X-50 Y-50 Z10.300 F4800.000 G1 X-50 Y-50 F960 G1 X-45 Y-45 G1 X-40 Y-40 G1 X-35 Y-35 G1 X-30 Y-30 G1 X-25 Y-25 G1 X-20 Y-20 G1 X-15 Y-15 G1 X-10 Y-10 G1 X-5 Y-5 G1 X0 Y0 G1 X5 Y5 G1 X10 Y10 G1 X15 Y15 G1 X20 Y20 G1 X25 Y25 G1 X30 Y30 G1 X35 Y35 G1 X40 Y40 G1 X45 Y45
Now I'm sure that this clicks are result of a lot of g-code fragments. David, I think that something wrong.
-
Thanks for your example. My printers are out of action until my office refurbishment is complete, but I'll try it out when I can. Feel free to remind me on Wednesday if you don't get a response before then.
David, did you have time to check this? It seems to me that RRF produces very small pauses after each g-code, this pauses causes jerky moves. Even linear (straight?) movement of effector on my delta produces this pauses. You can view example g-codes in my previous post. But 1-line (w/o segments) g-code does not produce this pauses.
Now I can hear this pauses almost in every print with smooth curved movements
-
I think if I listen very carefully to my delta running a 0.8.5 I can hear similar sounds. Can you post photos of the surface defects it creates on the sides of the print? I'm sorry if you posted this already and I missed it.
-
@bot:
I think if I listen very carefully to my delta running a 0.8.5 I can hear similar sounds. Can you post photos of the surface defects it creates on the sides of the print? I'm sorry if you posted this already and I missed it.
I said earlier that I'm unable to take macro photos of differences with acceptable quality of photo. I will try later with another plastic colors and right light. UPD: this defects looks like vertical columns of very small plastic blobs on surface of printed part.
Also I said before that print quality isn't a problem for me, I'm happy Duet WiFi owner, but I still think that something is wrong here with g-code processing or something another.
That's why I'm trying to draw David's attention to this problem. But seems like he is very busy in the last month and haven't time to check this.
-
Okay, no worries. I just figured since I checked the other day and noticed a faint sound that is similar to yours, and with the same consistency, that I'd let you know. I don't notice any print defects at all that I can attribute to this noise, however.
-
I am sorry, it is still on my list to investigate.
-
I finally got round to testing this. I can hear and feel clicks on my deltas but they are very faint, perhaps because my printer has 0.9deg motors.
At this stage I can think of two possible explanations:
1. At the boundaries between segments, the motor positions each have to be rounded to the nearest microstep. Interpolation doesn't help here. The clicks may just be the result of this rounding.
2. Or there could be a problem with the precise time interval between the start of the old move and the start of the new move. Currently, the new move starts as soon as the old move has taken its last step; but the first step of the new move won't happen until it is due.
I will investigate further.
-
Thank you, David!
Also I noticed that in 1/256 microstepping mode this clicks not audible nor feeling. Maybe this can help to investigate.
-
Hello, David. Do you have any news? Maybe I can help you testing/debugging this issue?
-
My best guess is that the clicks are due to the boundaries between segments having to be rounded to the nearest microstep for each motors. That would explain why reduces or goes away at higher microstepping. But I have it on my list to check the pulse time with an oscilloscope, to make sure that each move is starting at the correct time and is not early or late.
-
Seems like beta boards does not have pins for step signals for onboard drivers or I just overlooked something.
I remapped drivers to expansion header pins (M584 X6 Y5 Z8) and connected logic analyzer to this pins.
Then I manually pressed homing switches during homing to cheat homing procedure and printer "homed" correctly. Then I captured X/Y/Z step signals during g-code printing with segmented straight movement with this clicks.
I see pauses in step signal generation but I can not interpret this information correctly.
If you wish I can upload logic analyzer dump file. I'm using Seleae Logic software, it's free to download. Also I can export data in other formats.
-
Would it be possible to take screenshots of the output of the software and post the results here? Thanks, roboduet, for being persistent and proactive about what you feel is an underlying issue. This may turn out to be a very useful avenue of exploration, even if to simply determine that this behaviour is unavoidable.
-
Yes, I can post images. I also want to say again that I do not fully understand what happens and who is responsible for this (logic analyzer hardware, usb bus, software or Duet itself).
Pauses are selected with marker (blue icons). X channel is first from top, Y is second, Z is third (bottom).
@bot - thanks for your support
-
Thanks for posting those traces.
I see that each pause is less than twice the normal pulse interval for that motor, and the pauses do not occur on all motors at the same point. Also there is sometimes a reduction in the interval between pulses instead of a pause.
I think this confirms my suspicion that the pauses are caused by the need to round each motor position to the nearest microstep at the junction between each pair of segments. Such rounding is unavoidable. Increasing the microstepping is the only real cure I can think of.
Whereas all other delta printer firmwares chop moves into short segments, RRF doesn't except when grid bed compensation is enabled, and even then the segments are quite long (about as long as the grid spacing). So this should be much less of an issue with RRF than with other firmwares.
btw you can use M584 to map each motor to more than one driver, allowing you to use the internal drivers as well as putting the pulses on the expansion connector.