Firmware 1.20 Release Candidate 1 available
-
I have released this in the usual Edge folders. The 1.20 series firmware is now feature-complete, so there will be only bug fixes between now and the 1.20 release. I hope to do the full release before Christmas, but that depends on getting sufficient feedback from users who try out the release candidate(s).
The full release notes are at https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md, but this is what's new since 1.20beta11:
-
M109 and M104 commands now set both the active and the standby temperatures of the tool.
-
M109 now only selects a tool if no tool was selected
-
Filament errors are now logged
-
M587 now checks that the password is either empty or is at least 8 characters long
-
M122 now includes the minimum and maximum StallGuard registers for each driver seen since the last M122 command
-
M307 now accepts an F parameter to allow the PWM frequency to be set. Caution: do not use excessively high PWM frequencies, especially with the bed heater, because you may overheat the mosfets.
-
The calculation of PID parameters from the heater model has been changed to provide faster heating and less risk of undershoot
-
The M81 command now accepts an optional S1 parameter, which defers the power down until al thermostatic fans have stopped
-
SD card detection is now working properly (Duet WiFi/Ethernet only)
-
A file that is open on the SD card can no longer be deleted
-
Various bug fixes
Those of you who are coming from 1.19 or 1.19.2 will find a lot more new features, listed in the whatsnew files under the various 1.20beta and alpha releases.
Please report your experiences with this release in this thread.
-
-
Nice work, will try it this weekend.
One question, did you remove the "stable" folder? I can't find those releases. -
One question, did you remove the "stable" folder? I can't find those releases.
Yes, because stable releases have been at https://github.com/dc42/RepRapFirmware/releases for some time.
-
I assume this is also in previous versions but I just tried to print a a file named "deflector (repaired).gcode". Without the quotes of course. When I select this file to print from the DWC file list I get an error M32 cannot locate file. If I remove the (repaired) part of the filename it prints fine.
I checked M32 and don't see any limitations on file names. -
I've finally finished my move and have been getting my printer operational again. With 1.20b11, I was getting under temperature events in my new 14 degree C basement.
So, I just tried re-tuning on the new 1.20RC1 and I keep getting "Heater is not ready to perform PID auto-tuning" for all three of my heaters (bed, HE1, HE2). Am I doing something wrong?
M303 H1 S240 is the command I'm using.
-
Update: I downgraded to 1.20b11 and tuning will start. Re-upgrading to 1.20RC1 and tuning gives the error message.
Update update: I'm on Duet Ethernet.
-
I assume this is also in previous versions but I just tried to print a a file named "deflector (repaired).gcode". Without the quotes of course. When I select this file to print from the DWC file list I get an error M32 cannot locate file. If I remove the (repaired) part of the filename it prints fine.
I checked M32 and don't see any limitations on file names.Round brackets are used to surround comments in GCode. To print that file you would need to send this command:
M32 "deflector (repaired).gcode"
with the quotes. DWC doesn't currently quote filenames when it sends commands. Neither does PanelDue.
-
Update: I downgraded to 1.20b11 and tuning will start. Re-upgrading to 1.20RC1 and tuning gives the error message.
Update update: I'm on Duet Ethernet.
Thanks for your report. I'll test the heater tuning in 1.20RC1. I last tested it in 1.20beta10.
You can use the same M307 heater model parameters for 1.20RC1 as you did in 1.19.2, so re-tuning the heater is not essential.
-
David,
I've just tried this release candidate with the two issues that I had been having.
The first was that using M109 in a macro with only X and Y movement caused the Z axis to move to absolute 5mm. This is now fixed.
The second was the behaviour of U and V on a CoreXY using the P3 hidden axes parameter in M584. This is different but unfortunately not fixed. What happens now is that if I use the P3 parameter, the U and V axes do not move at all.
As a reminder, in config.g I have M584 X0:3 Y1:4 Z2 U10 V11 E5:6:7:8:9 P3. Then the first line of my homeall.g is M584 X0 U3 Y1 V4. When I run homeall.g, the U and V axes remain hidden which is new behaviour (they used to appear in DWC). Then when I run the next line which is G1 X-380 U-380 Y-380 V-380 F4800 S1 the U and V axes remain stationary. I get the same thing from the console too. i..e if I send M584 X0 U3 Y1 V4 then G1 X10, or G1 Y10 those axes move as expected but if I send G1 U10 or G1 V10, those axes remain stationary. If I remove the P3 parameter from M584 in config.g so that the U and V axes are visible at all times, then everything works as it should - i.e. all 4 axes move as commanded.
To recap. With 1.20beta10, the issue was that the M350, M92, M203 etc parameters were not being applied to hidden axes even when the M584 command preceded those other commands. The work around was to use M584 without the P3 parameter at the start of config.g, then add a second M584 command with the P3 parameter near the end of config.g. This worked really well. If I put M584 X0 U3 Y1 V4 at the start of my home all file then M584 X0:3 Y1:4 Z2 U10 V11 E5:6:7:8:9 P3 at the end, then when I ran homeall.g the U and V axes would appear at the start of the homing sequence, then disappear at the end. I really liked that behaviour.
With 1.20beta11 you made a change which should have negated the need to use two M584 commands - one with and one without the P3 parameter. Unfortunately, whatever change you made had the effect of causing the U and V axes to lose their CoreXY kinematics. At lease that was the observed behaviour as they seemed to be just using a single motor and moving at 45 degrees. The work around was to keep the axes visible at all times. i.e. not use a P3 parameter anywhere.
Whatever change you have made with this RC1 candidate has had the effect that the U and V axes do not move at all when commanded to and when the P3 parameter is used in M584. The work around is again, not to use the P3 parameter.
I really liked the behaviour of beta10 - it's just that I had to use two M584 commands, the first without the P3 parameter and the second with the P3 parameter.
Cheers
Ian
-
Ian, thanks for the feedback. What happens if you use M584 P5 in your homing file(s) before you need to move U and V, and M584 P3 when you have finished doing that?
The behaviour is intended to be:
- If you use M584 to create new axes (that haven't been mentioned before in a M584 command), by default they are visible, unless you have a P parameter on the same command
- Axes have to be visible in order to move them
- You can change the number of visible axes at any time using M584 with a P parameter (at the same time as changing the motor mapping, or by itself).
-
Hi David,
That works. With those changes (P5 at the start and P3 at the end of the homing files), the axes are hidden unless they are being homed and all movement is as expected (as long as the axes are visible). So it's all good.
I have M584 X0:3 Y1:4 Z2 U10 V11 E5:6:7:8:9 P3 near the start of config.g (before any other drive related commands and before the axes limits) but no other M584 commands in config.g. That proves that parameters are now being applied to the hidden U and V axes.
At the start of the homing files (all of them apart from homez.g because no axis mapping is involved) I have put M584 X0 U3 Y1 V4 P5. Then near the end of the homing files I have M584 X0:3 Y1:4 Z2 U10 V11 E5:6:7:8:9 P3. I guess I could abbreviate that final M584 to be simply M584 X0:3 Y1:4 P3 but it does no harm as it is and I'm less likely to make typos with copy and paste :).
Cheers
Ian
-
Hi David,
Here are some things I have noticed, and they could be features or bugs, you tell me
- if you issue a M913 X10 Y10 to reduce XY currents to 10 percent, the new current setting sets in only after a move on one of the axis
- if you speciffy in bed.g coordinates outside the table, it will execute ignoring the table dimensions set with M208
Cheers,
Sascha -
David,
I have just tried to upgrade to 1.20RC1 on Duet 0.85, from 1.19 Stable.
It seems I have a difficulty to connect to my Duet over the Ethernet. I have my Duet set up to get the IP address over the DHCP. It seems it cannot do it anymore for some reason. I must admit, that I have a complicated network, but it was and is working until 1.20 just fine.
I have used the DWC to upgrade the FW, and after the flashing, I could not connect to the board anymore.
I was thinking that flashing over DWC went wrong for some reason, so I have flashed the board with Bossa.
It seems that the Duet reacts just fine with RJ45 disconnected, I can use PanelDue to home, and to jog the axes.
However, as soon as I plug in the Network cable, printer starts to act strange. The PanelDue commands are ignored, or executed with a great delay. It seems like the CPU is struggling to get the IP or something.
I also notice the SmartEffector LEDs are blinking very shortly once in a while. Like after a reset during boot up.I have downgraded to 1.19, and network and the Duet is working fine.
But I get random Duet resets out of nowhere with 1.19… so I wish to get upgraded as soon as possible. -
David,
I have just tried to upgrade to 1.20RC1 on Duet 0.85, from 1.19 Stable.
It seems I have a difficulty to connect to my Duet over the Ethernet. I have my Duet set up to get the IP address over the DHCP. It seems it cannot do it anymore for some reason. I must admit, that I have a complicated network, but it was and is working until 1.20 just fine.Thanks for your report. One of my printers uses a Duet 085 and gets its IP address via DHCP, so I know this works at least in some configurations.
Please can you load RRF 1.20RC1 again, confirm, the problem is still there, then send M122 for USB and post the report here. Also post a M122 report from RRF 1.19.
One possibility is that the configuration you are using is leaving your Duet short of memory, which would explain the problems you are having with both RRF versions. The M122 report may shed some light on that theory.
-
I confirm that it is not possible to tune heaters in firmware 1,20RC1. This will be fixed in 1.20RC2. Meanwhile, use the same heater parameters that you were using with firmware 1.19 or a 1.20beta.
-
Please can you load RRF 1.20RC1 again, confirm, the problem is still there, then send M122 for USB and post the report here. Also post a M122 report from RRF 1.19.
One possibility is that the configuration you are using is leaving your Duet short of memory, which would explain the problems you are having with both RRF versions. The M122 report may shed some light on that theory.
David, I have tried to flash it again using the DWC. The same behavior. It seems I also cannot sonnect over the USB, the Duet is recognized in Windows, but the drivers can not be installed for some reason, so I cannot connect via Comport. I am not sure why it is not working. The erased board is recognized just fine. I can flash it with Bossa.
Any thoughts?
Update:
I have been playing around to gather more information, please let me know if I should open a separate topic.
It seems that I cannot flash a newest FW over the DWC (1.19.3) anymore. The procedure works fine with FW_1.18.1, but with 1.19 and 1.20RC1 the printer doesn't seem to be able to reboot automatically, and gets stuck with the 'Update successfull! rebooting…' message on the PanelDue.
With the 1.19 FW I can power-cycle the printer and it will operate 'fine'. But reboots once in a while, even with sitting still and doing nothing.
With 1.20RC1 even if I power-cycle it, it doesn't seem to be able to find the network (see my original post).I will use 1.19 to get the M122 listing for you...
Update
I have the M122 listings, but I cannot find a way to attach it to this message from my mobile device... -
M307 now accepts an F parameter to allow the PWM frequency to be set. Caution: do not use excessively high PWM frequencies, especially with the bed heater, because you may overheat the mosfets.
This feature I am especially excited to try out, I've had to use bang-bang for my heated bed because with PID a couple nearby lights in my house would visibly flicker.
-
M307 now accepts an F parameter to allow the PWM frequency to be set. Caution: do not use excessively high PWM frequencies, especially with the bed heater, because you may overheat the mosfets.
This feature I am especially excited to try out, I've had to use bang-bang for my heated bed because with PID a couple nearby lights in my house would visibly flicker.
I implemented it just for you, in response to your post in another thread.
-
I just installed RC1. I can confirm M307 Fx works fine at 1, 1.5 and 2Hz and the light flicker is a lot less annoying. Thank you!
-
Only integer frequencies are supported, so 1.5Hz will get rounded, to 1Hz AFAIR.
