Firmware 2.02 released!
-
@kazolar said in Firmware 2.02 released!:
@dc42 -- first, marry x-max. I've been banging my head on this glitch, too many moving parts, and now I see it's a bug in 2.02RC7 which works fine in RC5. In config.g I need to move my Y an U axis 0.1 mm -- it's due to have smart steppers init themselves -- they need to be jogged to function. This code below at the end of my config.g
M300 S300 P500
G4 S3
M564 S0 H0
G91
G1 Y0.1 U0.1 F30000
G4 S1
M564 S1 H1
G90
M300 S300 P500
M18works perfectly in RC5 but takes forever in RC7, something is not right with how it executes the move on startup -- specifically the G1 command.
Please provide your config.g file.
-
@phaedrux said in Firmware 2.02 released!:
Merry Christmas David. Thanks for all your hardwork.
One thing I've noticed on the the 2.02 release is that beeps don't play from the PanelDue speaker anymore, but they do play from the DWC. At first I thought it was just because I was interacting with the DWC that it played them there, but even with no DWC open and a fresh startup, there were no beeps from the PanelDue. Am I crazy, or is this new behavior?
I'm sorry, I can't reproduce this. On my Kossel with PanelDue and on my Crane with a 12864 display, beeps only come from the display.
-
@dc42 Here is the full thing, the key section at the bottom. Works fine in 2.02RC5 and super slow in 2.02RC7 as if I can't issue motion commands for 30 seconds. I have exact same minor code alterations to add the 2 additional steppers, that code hasn't changed. Something about init has changed.
-
@dc42 Hi dc! I tested the new CNC mode, and it works fine now. The only thing I forgot to tell you was that It would be usefull if you can can add some G o M function to set a G0 speed, so that speed is fixed and only a G1 speed is set through the cam (thats the way industrial CNCs works). A workaround could be to tell the postprocessor to output G0 F1000 (could be any speed) instead of G0 only.
-
@dc42 note, the small move in config.g worked find in the last 1.2x version, worked in 2.02rc5, and sorta works in 2.02 rc7, but has random timing. Sometimes completes as expected very quickly, sometimes (most of the the time) seems to take about 20-30 seconds, afterwards, after config.g completes everything works fine, but that small move is weird. I haven't tried 2.02 final, let me know if I should - I'd need to apply a few of my diffs to it. Are there any changes between rc7 and final which would fix this config.g timing issue.
-
@3doeste Normally G0 speed is the top speed defined as maximum feed rate in config.g. When jogging, DWC uses the value specified in settings. If you want to use the fastest possible, use something abnormally fast as DWC value, the firmware will never exceed the maximum feed rates defined in config.g.
-
@3doeste said in Firmware 2.02 released!:
@dc42 Hi dc! I tested the new CNC mode, and it works fine now. The only thing I forgot to tell you was that It would be usefull if you can can add some G o M function to set a G0 speed, so that speed is fixed and only a G1 speed is set through the cam (thats the way industrial CNCs works).
That's already how RRF works when you switch it into CNC mode. Use M203 to set the speed for G0 moves.
-
Just wanted to say how fantastic it is to finally have the network reconnect after my POS cable modem/router stops working, and I have to reboot the thing. I hated flying blind until the print ended.
Thanks devs
-
Thank you.
What would be great would be an online update function that the board could download the firmware data itself. If that's possible.
(Auto Update Firmware Button on the Webinterface)
With release channels Beta and Stable.
And with update message in the Webinterface when a new Version is available
Also that if you click on Update you will get the realse notes as well. -
@dc42 I tried 2.02 code branch, and init is definitely not right, the startup move takes 30 seconds instead of < 1 seconds. I went back to 2.02RC5 and it's fine. I'll use RC5 until 2.02RC gets sorted out. I have a patch with my mods so I can try new firmware very easy.
EDIT:
I tried 2.02RC6 -- problem persists. Went back to RC5 -- problem goes away -- something was changed between RC5 and RC6 which makes init bootup moves not workEDIT2:
I changed the move to beG1 S2 Y0.1 U0.1 F30000
(I added S2) and now it's fast as before, something between 05 and 06 changed, so without S2 this move on startup takes 30 seconds.
I am on 2.02 and with S2 it works fine -
Hi David,
Same problem for me with 2-02rc6 on my Scara
https://forum.duet3d.com/topic/8155/firmware-2-02rc6-released/5 -
I've been using 2.02 for a few days now and have not noticed any issues myself.
I just installed the new DWC while exploring it, I realized that the new FW also has a way to set material parameters on the machine. I'm really excited to migrate all of my machine/material combo specific firmware parameters out of the slicer and into the machine. This should make it much easier to use various slicers (currently I can only use KISSlicer with my configuration system) while maintaining a well-automated system of parameters for machine/material combos. Thanks for all of your work David!
-
After running a 4 hour or so print, the end stops on the Duex5 don't respond in homing. Worked fine in RC5. I thought it was wiring, or other issues, but seems firmware related -- the lights on the Duex5 change accordingly, but Duet doesn't recognize the end stops as triggered.
edit -- after rebooting the duet, end stops work again.
going back to 2.02RC5. I think end stop changes are in RC7 -- all I was missing in RC5 was the the ditto filament fix,and I migrated that. I can't run a long print and rely on it ending smoothly as it homes some of the Duex5 axes, so I'll be using the RC5 build until there is a solution for end stop issue.
-
@kazolar said in Firmware 2.02 released!:
After running a 4 hour or so print, the end stops on the Duex5 don't respond in homing. Worked fine in RC5. I thought it was wiring, or other issues, but seems firmware related -- the lights on the Duex5 change accordingly, but Duet doesn't recognize the end stops as triggered.
edit -- after rebooting the duet, end stops work again.
I had the same problem yesterday while testing something:
M119 did show that the X axis endstop is triggered while it wasn't. And it didn't change while manually triggering it.
However, the status LED showed the correct status and changed accordingly.
After rebooting it worked again... -
Updated from 2.02 RC4 today and sometimes the Duet just starts refusing uploads without any specific error message after another print is done or canceled. Only a reboot helps then. Sometimes it's even more sporadic - I need to delete a few files before it allows another upload, but I don't even have that many files.
All otherwise it appears to work as expected.
-
@edgars-batna I'm having similar symptoms that after it gets into some confused state, uploads slow down drastically normally at 450-600kbps, then they plumin to 160-180k, so it seems it has something better to do. There seem to be other glitches, so I went back rc5
-
@hurzhurz m119 was showing not triggered for me and led was working, end stops on the duet proper were ok, just appear to not work with end stops on the expansion which for me starts with my 2nd gantry - w axis. I tried bridging the wires by had remocing the plug, only reboot cleared it..
-
I'm having weird homing behavior related to dual limit switches with 2.02. Though, I reverted to rc5 and the problem was still there.
https://forum.duet3d.com/topic/8307/dual-z-homing-weird-behavior-on-u-limit-first/7
-
@leonmf I replied on that thread -- hope that helps you, dual (or more ) z homing works fine in RC5 -- I believe there are some transient issues in 2.02 final -- possibly started with RC7 -- I notice that after a long period of on time there is some issue that builds up which results in a few other oddities, @dc42 -- i.e I noticed a slow down behavior between moves -- for example it moves, then thinks then moves again, the move is not slow (I've see that before), but it thinks a good bit before the next move -- in that state is when it starts to lose end stop triggers.
-
David, I am running rc5 and after over 20 hours of printing, no issues with end stops, it's a 30 hour print, but I just checked the diagnostic page while it's printing and checked the end stops on the duex5 and they work fine. Definitely there was an issue with the new firmware and duex5 end stops.
