Firmware 1.19RC5 released - last chance to report issues
-
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.
-
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.
Strange, I just tested it, and it works for me. What version of PanelDue firmware are you running? Can you reproduce the problem?
-
firmware is 1.16
Yes, it is repeatable. I didn't even think about the firmware.. I bet that's it.
-
1.16 is current.
-
I cancel print jobs from the panel due all the time.
It works. -
I have noticed an issue that has existed for some time but just confirmed it really does exist….
Power on, run Auto Delta Calibration from the panel due - the button.
Now run it again.The second time seems to honor the dive height whereas on the first run it sort-of does. I mean, I have recently had to set my dive depth to 10m, which takes forever to complete a pass, but without 10m set the IR probe goes wonky between probe points.
This is a change from 7mm I had set in earlier firmware releases.The first pass does not go 10mm dive height, the second does. I know this because the first pass completes is about 3/4 the time the second pass does.
M558 P1 X0 Z0 H10
Granted, I may need to dial my Z height in (again). First run result is something like 6.778 second and future calibrations ar 0.091 or so. Still, I seem to recall this pattern for quite awhile, maybe since an early beta.
My current settings (heh):M92 X100 Y100 Z100 E150:150:150:95:95:95:95 ; Set axis steps/mm
M665 R88 L215 B100 H355.00 ; tweaking height
G31 X0 Y0 Z2.704 P500 ; Set the zprobe height and threshold (put your own values here) - for Z, bigger number means closer to bedCan someone with a delta and a ir probe double check what I am saying??
