Jerky movements, again
-
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.
-
Yet another two examples. I just created g-code with 50 millisecond segments (F1200, 1mm movements), so pauses (or step signals with shorter interval) going exactly every 50 ms, easy to find in analyzer logs:
All three motors paused at 7.420+ s position
Pause for X step, premature step for Y and Z at 7.520+ s position
Pause for X and Y, premature step for Z at 7.670+ s position, also steps are skewed at 7.770+ s position
