Stable firmware 2.01 (Duet 2) and 1.22 (Duet 06/085) released
-
@dc42 said in Stable firmware 2.01 (Duet 2) and 1.22 (Duet 06/085) released:
Do you mean that the display is working, but the panel does not respond to touch? If so then it's most likely the touch panel on the display that is faulty. If you have the non-integrated version, then it's possible but not very likely that the PanelDue controller board has developed a fault.
I have a separate PanelDue controller card,
I used the display yesterday, got the printer on again today, and now half of the touchscreen is working -
This post is deleted! -
@gideon said in Stable firmware 2.01 (Duet 2) and 1.22 (Duet 06/085) released:
@dc42 said in Stable firmware 2.01 (Duet 2) and 1.22 (Duet 06/085) released:
Do you mean that the display is working, but the panel does not respond to touch? If so then it's most likely the touch panel on the display that is faulty. If you have the non-integrated version, then it's possible but not very likely that the PanelDue controller board has developed a fault.
I have a separate PanelDue controller card,
I used the display yesterday, got the printer on again today, and now half of the touchscreen is workingYou can try re-running the touch calibration, but if that doesn't work you will need a new display, unless you can find a replacement touch panel for it.
-
I have made a simple mistake when positioning the raw material on the CNC and the very last set of GCodes were outside the machine limits. As the spindle VFD is controlled through M3 and M5 commands, the GCode file had those as well. The GCodes outside the machine limits have been simply ignored, but the M5 was executed before the already queued moves finished, practically doing the final moves while the spindle was slowing down.
Luckily it was just a 2.5D cut, during the final passes, and no harm was really done, but if it were something different the end mill would have broken.
Could be added a safety check in the code for M5 to insure that there is no queued move to execute before powering down the spindle?
Later: Wrong! It always cuts the power of the spindle before finishing all queued moves!
-
@catalin_ro said in Stable firmware 2.01 (Duet 2) and 1.22 (Duet 06/085) released:
The GCodes outside the machine limits have been simply ignored
When in CNC mode, with firmware 2.0 and later any attempt to perform movement outside the machine limits should result in an immediate stop. Did this not happen, or are you running older firmware?
-
It is latest firmware! But it was nothing like an immediate stop...
No more GCodes were executed from the file but the already queued ones were allowed to completely finish and the final M5 was also executed, before actually ending any movements.
When doing another machining, with everything within machine limits, I found out that the M5 was also executed before all movements were finished (the spindle was actually fully stopped while the end mill was still moving through the material!!!).
A quick and dirty workaround was to replace M5 by G4 P0 M5, no properly waiting for any movements to fully finish. Shouldn't M5 wait for the movement queue to be empty before executing by default?
-
I installed a maestro on a printer with a 12864 display. With previous versions of the firmware the display would have the name and a number. Turning the encoder knob would increase or decrease the number.
With the latest version I get the following:
Error Loading menu
File Main
Can't open menu fileHowever, pressing the button on the display causes an emergency stop and the SD card reader works as well.
From the information that I have found I know it's not something that is fully featured or supported, but what is the current expected behaviour?
-
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
I can't connect to DWC and other than repitier usb to send m552 s1 I have no other way to control machine. Now what do I do? I installed this stable firmware and the DWC found a few line below on same page. Board turns on psu with m80 command when I plug in usb. That might be a repitier thing. I type ip address and nothing. Now I've been printing for more than a year with this, worked with the files many times and read every word of the instructions. I performed every step correctly. I had 1.21rc1 running before this upgrade. and DWC 1.22. now I loaded the versions found in this post and I'm no-longer printing.
-
Router page show ip config as static and full packets sending receiving. It's online full access enabled. But web interface doesn't load.
-
I see a blank white window after typing ip in my browser. router show it connected and I don't get an internet connect error. Where is the screen set?
-
@sjason1377, please send M552 from USB to see whether the Duet is connected t the network and confirm its IP address.
-
Thanks.
It looks like this is still in the early stages. It states that the "following commands will be supported", is the number command currently support? If so, how is the identifier determined?
What I am currently interested in is the current and active temps for tool0 and bed heaters. Maybe the fraction printed.
-
Items that should be able to be displayed and adjusted where applicable are:
0+n Heater n current temperature
100+n Heater n active temperature
200+n Heater n standby temperature
300+n Fan n speed
399 Current print cooling fan speed
400+n Extruder n extrusion factor
500 Speed factorThis is the value of the N parameter in the 'value' command.
The 'image' command doesn't work yet. The 'files' command doesn't work in my fork, but M3D has a build that implements it. I plan to merge their code into my fork before the 2.02 release.
HTH David
-
Just got to upgrade to 2.01, I'd been at 2.01b2. Got a bit of a surprise.
I'd used some old output from the gcode console to configure my current and microstepping. Specifically around the E field and the number of values. It had reported 9, so I set 9.
In 2.01 I discovered the fun way that if you have more than 7 E values configured, weird things happen:
M906
Motor current (mA) - X:1500, Y:1500, Z:1500, E:0:0:1500:1500:1500:0:0, idle factor 60%(Similar for M203, forgot to copy it before I fixed it)
Lowering the number of fields in my config.g fixed it. Obviously I shouldn't have had that many, but it was being defined based on the number previously reported:
M203
Microstepping - X:16(on), Y:16(on), Z:16(on), E:16(on):16(on):16:16:16:16:16:16:16Running an extruder with zero current and the incorrect microstepping does some weird stuff!
Edit:
The output at the gcode console was good at explaining what was wrong, so I fixed it quickly once I realized there was an issue:M906 X1500 Y1500 Z1500 E700:1500:1500:1500:1500:1500:1500:1500:1500 I60
Error: GCodes: Attempt to read a GCode float array that is too long: M906 X1500 Y1500 Z1500 E700:1500:1500:1500:1500:1500:1500:1500:1500 I60Last edit: I see this was covered in the release notes in whatsnew. I just missed it. This is just a bit of insight on what happens in that case. Carry on!
-
Neither M561 nor G29 S2 adjusted the user Z coordinate if bed compensation was previously active (G29 S2 did if you ran it twice)
From the release notes and not mentioned in later releases ... Im not sure I understand from this bug fix description, what this means and is doing ... but suspect it may resolve an issue I have been experiencing from day 1 on my cartesian Prusa MK3 style printer and mesh bed leveling and Z height adjusting on Layer 1
I can never really seem to get a stable proper 1st layer height between prints and have to make rather large adjustments [ Z height baby stepping ] between prints and manually dial in Z with baby stepping - every print - even when printing on the same day or within the same hour.
It always seem like the layer height adjustments were being compounded or stacked - even if I ran M561 between. Only way to seem to get a fresh start was a reboot of the machine. And then the baby step dial in after Mesh Bed Comp was run and Dual Z lead screw tilt correction macros were run.
Im currently on 2.0 - wondering if this is a potential fix for my issue[s]
