Firmware 1.19RC5 released - last chance to report issues
-
I reported a stuttering bug on github when pressure advance is enabled. It seemed to only happen on a skirt generated by s3d 4.0, but was quite strange. I assume it can happen in other scenarios.
-
I copy-pasted your M111 commands.
Yes, I am using grid autoleveling.
Michael
-
@nyt:
I reported a stuttering bug on github when pressure advance is enabled. It seemed to only happen on a skirt generated by s3d 4.0, but was quite strange. I assume it can happen in other scenarios.
The stuttering is caused by S3D generating strange gcode. Here is an example:
G1 X203.690 Y182.089 E0.0139
G1 X203.694 Y182.089 E0.0001
G1 X204.940 Y182.306 E0.0525
G1 X204.943 Y182.307 E0.0001
G1 X205.241 Y182.368 E0.0126
G1 X205.244 Y182.368 E0.0001
G1 X206.364 Y182.633 E0.0477
G1 X206.367 Y182.634 E0.0001
G1 X206.683 Y182.720 E0.0135
G1 X206.686 Y182.721 E0.0001Notice how every alternate move has an extrusion distance of just 0.0001. Transposed to a spreadsheet:
X Y E XY distance extrusion/distance
203.690 182.089 0.0139
203.694 182.089 0.0001 0.004 5.49E-07
204.940 182.306 0.0525 1.265 2.88E-04
204.943 182.307 0.0001 0.003 5.49E-07
205.241 182.368 0.0126 0.304 6.91E-05
205.244 182.368 0.0001 0.003 5.48E-07
206.364 182.633 0.0477 1.151 2.61E-04
206.367 182.634 0.0001 0.003 5.48E-07
206.683 182.720 0.0135 0.327 7.39E-05
206.686 182.721 0.0001 0.003 5.47E-07The extrusion rate varies greatly between adjacent moves. This forces the extruder to slow down between them to adjust the extrusion rate, hence the stuttering. I guess we could detect ridiculously short moves and throw them away, but I don't see it as our job to compensate for stupid gcode generated by buggy slicers. Please file a bug report with S3D.
Increasing allowed extruder jerk and/or acceleration may reduce the stuttering.
-
I copy-pasted your M111 commands.
Yes, I am using grid autoleveling.
Michael
I guess you used Repetier host, because it enables full debug output by default when you connect, and I can see that you entered the correct debugging commands later in the session.
I see now that you have G29 S1 in config.g. That explains why we get different behaviour. I am using a bench setup to simulate your system, so I have no heightmap.csv file. Now that I can see what is happening, it should be easy to fix. I just need to make sure that I don't upset the behaviour for users who use the U axis as an additional axis instead of a substitute X axis.
I'll look at your report regarding G1 R2 as well.
Thanks for all the feedback you are providing and the tests you are running, and for your patience.
-
One of my other printers use the U axis as an additional axis (head rotation) so if you release a new RC, I can test that too.
And thank you!
-
After some discussion with other users (I can't remember if you were one of them), the specification of what the feed rate does was changed to:
1. If there is any XYZ movement, then the F parameter relates to the combined XYZ speed, and any other axes have their speeds chosen to match that.
2. Otherwise, the F parameter relates to the combined movement in hypercube space of all the motors that are moving. [An alternative choice wild have been to make it apply to the one that is moving the most.]
When the U axis is used as a substitute X axis, then U movement counts as X movement in the above.
What's happening in this case is that the bed compensation is causing #1 to be applied, when you want #2.
Here are some possible solutions:
A. Change definition #1 above to be "If there is any XY movement, then the F parameter relates to the combined XY speed, and any other axes have their speeds chosen to match that." The problem with this is that a pure Z movement may have a small XY component added if axis compensation is enabled, which would cause the Z speed to be wrong.
B. Change specification #1 above to be "If there is any XY movement, then the F parameter relates to the combined XYZ speed, and any other axes have their speeds chosen to match that." I think this might work.
C. Keep track of whether the movement of each axis was commanded by the user or was added by bed or axis compensation, and stick with the original specification except that XYZ movement not commanded by the user doesn't count in deciding whether to use #1 or #2.
D. Add a configuration option to specify that a particular axis (in this case U) should be treated as an X axis when deciding on what the F parameter means.
One thing that is puzzling me: as the U axis is not being treated as an X axis in this particular case, why is bed compensation being applied? Looks like I need to investigate some more.
-
Odd homing behavior with Height Map active.
Firmware Name: RepRapFirmware for Duet WiFi
Firmware Electronics: Duet WiFi 1.0
Firmware Version: 1.19RC5 (2017-08-07)
WiFi Server Version: 1.19beta10
Web Interface Version: 1.17+2Machine homes correctly multiple times, as soon as I load the Height Map the machine lifts up on Z and either stops or it's moving VERY slowly. I placed my hand on the screw and it seems to be just slightly rotating.. almost impossible to tell.
; homeall.g
; called to home all axes
;
; Author: S. Halbrader
; Date: 5/16/2017; Relative positioning
G91; Lift Z
G1 Z10 F6000; Course home X and Y
G1 X-1005 Y-1005 F4500 S1; Move away from the endstops
G1 X5 Y5 F6000; Fine home X and Y
G1 X-1005 Y-1005 F360 S1; Course home Z
G1 Z-505 F2500 S1; Lift Z
G1 Z2 F2800; Fine home Z
G1 Z-505 F360 S1; Absolute positioning
G90 -
Should I remind you that this worked in previous releases and RCs?
Checking with RC4
-
RC4 exhibits same problem.
RC3 exhibits same problem.
RC2 exhibits same problem.
19beta11 works as expected.I don't have RC1 on hand.
-
I have just released 1.19 RC6. Kulitorum and Joe in particular, please test this version to see whether it fixes the issues you reported. Also please upgrade DWC.
Please note the following significant change in behaviour since RC5 and all previous releases:
The behaviour of the R parameter in G1 commands has changed. Previously, G1 R1 with no additional parameters restored the head position for all axes to the values just prior to the last pause command, and G1 R2 with no additional parameters restored the head position for all axes to the values just prior to the last tool change. The behaviour now is that only axes that are mentioned in the G1 command have their values restored. So instead of using G1 R1 in resume.g to restore the head position, you must now use G1 R1 X0 Y0 Z0. As before, any non-zero axis parameters will be added to the saved position of that axis. This change has been made so that additional axes used as substitute X and Y axis are not automatically restored.
-
Will check in an hour.
-
Yep, works so far, on my IDEX machine. I will test on my rotating nozzle machine tomorrow morning.
-
The extrusion rate varies greatly between adjacent moves. This forces the extruder to slow down between them to adjust the extrusion rate, hence the stuttering. I guess we could detect ridiculously short moves and throw them away, but I don't see it as our job to compensate for stupid gcode generated by buggy slicers. Please file a bug report with S3D.
Increasing allowed extruder jerk and/or acceleration may reduce the stuttering.
Reported to S3d.
-
I seem to be having issues with WiFi Configuration:
SENT: M552 S1
READ: ok
READ: WiFi module started
READ: WiFi reported error: no known networks found
READ: Wifi module is idleI updated the WiFi Server, as well as the firmware. I can't seem to get back to a point where I can configure the SSID.
-
Got it working .. had to write the SSID & password twice, then it started working again.
mDNS isn't working properly… no more going to [ndisname.local] anymore. OTOH, not a big deal.
-
Use M550 in config.g to set the machine name, because that forms the basis of the mdns name in firmware 1.19.
-
FYI, my rotating head printer is also running fine with RC6, so it seems all my problems have been solved.
Thank you for all your hard work
Kulitorum
-
Thanks for the feedback! Looks like we can release 1.19 at last.
-
Homing issue is fixed.
Thanks DC!
-
I just noticed a problem with the Pause / Cancel / Resume buttons on the PanelDue.
I can pause a print, but I cannot cancel or resume it from the screen.
