New firmware 1.21RC4
-
Continuing on from RC3 thread regarding my Duet Ethernet thinking it is a wifi. I flashed it to RC4 and again lost ethernet. I ran M115 and the last part of the line says "…ELECTRONICS: Duet W" so I am assuming it thinks it is a wifi. You said I should check the 2 pins closest to the edge. I'll need to remove it from its case to do this a bit of a job. I'll do this and check the connections and see if I need to repair. I believe this issue is only rearing it's head now because of the combination of both firmwares into one correct? I am hoping it is an easy fix as if not I'll need to send it back overseas. I will post an update in a bit.
thanksUPDATE:
Removed the duet ethernet and looked at the 2 pins under the board. There were connection issue with both. I resoldered and tested and it now thinks it is a "Duet E"I am glad you resolved it. Was it the soldering on the Duet or the soldering on the Ethernet daughter board that was bad? I don't suppose you took a photo of it before you repaired it?
One of those 2 pins (I can't remember which) is grounded on the daughter board but not on the WiFi module, so the firmware looks to see whether that pin is grounded to determine which network interface is fitted.
-
I can confirm working on delta and the issue with corexy that was present in rc3 is now solved. Prints completed on both machines.
One suggestion - for those of us using PS ON and OFF via relays/ssr's might it be possible for any attempt to send a command that would require power to be on when it is off, i.e. movement command or heating commands, should throw a warning rather than attempt to complete the action. Example:
I sent a home all G28 to a machine which had its power relay off, this effectively locks the device. I don't know if there is a timeout after which it will respond.
-
I'm seeing an issue with the new pre-homed movement restrictions in corexy config. I'm performing double-tap homing, and I've added [c]S2[/c] to the moves for 1.21:
G91 G1 X260 F6000 S1 G1 X-5 F6000 S2 G1 X10 F600 S1 G1 X-1 F6000 S2The problem I'm seeing is that after the halt from the first [c]S1[/c] move, if I use [c]S2[/c] to retreat from the endstop, that appears to trigger the "drive only one motor" behavior that's documented for deltas, i.e. it moves the head at a diagonal on corexy, rather than back along the axis. I can back away from the endstop by using [c]G1 X-5 Y-5 F6000 S2[/c] and manually driving both motors. Is that what's expected now for this scenario on corexy?
-
Upgraded to RC4 on my Mini Kossel Duet 0.6
Nothing new I'm afraid, still the same reboot loop when the ethernet cable is inserted and DHCP is active. I can live with this. It's nothing that hampers the use of this board in a serious way. Once back to fixed IP, all is working fine.Thanks for your report; I'm sorry it is still not fixed. I think there must be a timing difference between DHCP on your system and mine, or else the DHCP response from your router is different from mine.
Your trace shows that it is in dhcp_recv again. I'm starting to wonder whether this cause is a compiler bug, because I switched compiler versions around the release that the problems were first reported. The dhcp_recv function is full of goto statement (ugh!), and goto statements are (a ) difficult for compiler writers to translate correctly because the stack and register states at the point of the goto have to be matched to the states expected at the label, and (b) probably not very well tested, because very few developers use goto statements. For the release or next RC I may try rewriting that function without using goto.
-
I'm seeing an issue with the new pre-homed movement restrictions in corexy config. I'm performing double-tap homing, and I've added [c]S2[/c] to the moves for 1.21:
G91 G1 X260 F6000 S1 G1 X-5 F6000 S2 G1 X10 F600 S1 G1 X-1 F6000 S2The problem I'm seeing is that after the halt from the first [c]S1[/c] move, if I use [c]S2[/c] to retreat from the endstop, that appears to trigger the "drive only one motor" behavior that's documented for deltas, i.e. it moves the head at a diagonal on corexy, rather than back along the axis. I can back away from the endstop by using [c]G1 X-5 Y-5 F6000 S2[/c] and manually driving both motors. Is that what's expected now for this scenario on corexy?
You don't need to add S2 to those moves, because the X axis is already homed when they are executed. The typical case for needing to add S2 is when you want to raise Z a little at the start of X or Y homing.
-
I can confirm working on delta and the issue with corexy that was present in rc3 is now solved. Prints completed on both machines.
Thanks!
I sent a home all G28 to a machine which had its power relay off, this effectively locks the device. I don't know if there is a timeout after which it will respond.
The timeout will be the time it would take to execute the G1 S1 move it if had to travel the full X, Y or Z distance specified.
Why not put a M80 command at the start of homeall.g?
-
Thanks David, I will. If there is a timeout then that's not a problem, at least I know it will respond when I forget to power it up before testing something.
The other possible issue is if the machine has to be reset for some reason, the power does not restore so hotend cooling does not resume. Might it be worthy of consideration having a routine that checks the hotend temperature, and if it is above x deg C, initiates an M80 so the fan/water cooler can begin working again as soon as possible? I appreciate there are implication with thermal safety here. I'd propose 50 deg C for x, since that covers the glass transition temperature of PLA, the lowest of commonly printed materials.
-
I'm still able to repeat the m116 being skipped or ignored with RC4. In answer to your reply in the RC3 thread, my tool change macros (tfree*, tpost*, tpre*) are all empty (other than comments.) As well, everything works fine if the build plate is not fully pre-heated. This issue ONLY occurs when my build plate is already at temperature. Here's the (only) contents of the gcode file I used to verify this:
…Thanks. From that file I think I have worked out what is happening.
1. You send command G1 X150 Y70 Z30 F6000. That gets queued because it is a movement command. It will start executing almost immediately if there are no other moves in the queue.
2. The M291, M190 (if the bed is hot) and M292 commands will execute immediately, before the G1 has finished.
3. The M300 and the two G10 commands will be queue to be executed when the G1 move has completed.
4. The M291 command will be executed immediately.
5. The M116 command will be executed immediately. As the G10 command has been delayed pending completion of the G1 command, there will be nothing to wait for.So it's a problem with out-of-order execution. I think the fix I need to do is to make the M116 wait until there are no queued moves left before it checks whether there is anything to wait for. Meanwhile, if you insert a M400 command anywhere between the G1 command and the M116 command, that should work around the problem.
-
…
The other possible issue is if the machine has to be reset for some reason, the power does not restore so hotend cooling does not resume. Might it be worthy of consideration having a routine that checks the hotend temperature, and if it is above x deg C, initiates an M80 so the fan/water cooler can begin working again as soon as possible? I appreciate there are implication with thermal safety here. I'd propose 50 deg C for x, since that covers the glass transition temperature of PLA, the lowest of commonly printed materials.You could connect a small signal diode, cathode to your hot end FAN- pin and anode to PS_ON, so that when the hot end fan cuts in it will turn the power on automatically.
-
I updated to RC4 over RC3, and can confirm that leaving the firmware filename as Duet2CombinedFirmware.bin on my computer when uploading via the Setting tab on DWC worked fine.
Basic web/DWC connectivity seems fine. Homing, heating, fans, and basic XYZ movement on my Kossel Mini delta were also fine. That is all I was able to accomplish today.
John
-
You don't need to add S2 to those moves…
I must have been tired when I updated my scripts, because I didn't think that worked the first time around on RC3. Yes, it's happy now without the S2. (Sorry for the trouble there.)
A couple other nonblocking odds and ends:
-
I noticed that I needed to add a recovery time to my M558 commands where previously I did not need it. My homing scripts switch between different probes (M558, G31, G30) and on RC4 now those G30 commands that were previously happy are now reporting "Z probe already triggered". Adding an R0.1 to the M558 resolved it.
-
On a fresh reboot, using the web console to jog around while unhomed looks to pop state while empty. Doesn't affect me really, but I suppose if someone had previously M120'd, this web console action might steal that stack slot rather than its own.
M120 G91 G1 X-10 F6000 M121 Error: G0/G1: insufficient axes homed Error: Pop(): stack underflow! -
-
Thanks for that report, I can see why the underflow message is appearing and I will deal with it.
I can see why a recovery time would be needed when switching probe types, it's because the averaging filters need to accumulate data for the new probe unless you are changing to type 8. Using G4 after M558 to put a small delay there should be another way of fixing it.
-
CoreXZ homing issue is sorted, thanks for that!
-
Great idea I'll try that. Thank you.
…
The other possible issue is if the machine has to be reset for some reason, the power does not restore so hotend cooling does not resume. Might it be worthy of consideration having a routine that checks the hotend temperature, and if it is above x deg C, initiates an M80 so the fan/water cooler can begin working again as soon as possible? I appreciate there are implication with thermal safety here. I'd propose 50 deg C for x, since that covers the glass transition temperature of PLA, the lowest of commonly printed materials.You could connect a small signal diode, cathode to your hot end FAN- pin and anode to PS_ON, so that when the hot end fan cuts in it will turn the power on automatically.
-
Or just include M80 in your config file, works for me
-
After updating to 1.21RC 4 my machine, again, has the issue of long pauses between executing commands. It seems that it is processing 2 commands at a time, pausing for 8 seconds or so, and then executing the next 2. This time, it did it at the beginning of a print though whereas before it did it at the end.
-
Just upgraded from 1.21 RC3 to RC4 with the latest Web Control as well, and when I press "Home X" (or Y or Z or all) in DWC, I get a [c]G0/G1: insufficient axes homed[/c] error.
I downgrade back to RC3 and it worked - am I missing something?
From the RC3 upgrade notes:
[[language]] On Cartesian and CoreXY printers, normal G0 and G1 moves are no longer allowed before the corresponding axes have been homed. In particular, if your homex.g, homey.g and homeall.g files raise Z a little at the start and lower it at the end, you will need to add the S2 parameter to those G1 Z moves. Otherwise the G1 Z move will be refused unless Z has already been homed and the homing macro will be terminated.Thanks. I guess I didn't notice it because homing in RC3 works fine for me, and none of the changes in RC4 explained it.
-
Upgraded today and my coreXYUV is working correctly.
Thank you dc42 -
I can confirm that the laser mode with I1 now works as expected. Thanks!
-
After updating to 1.21RC 4 my machine, again, has the issue of long pauses between executing commands. It seems that it is processing 2 commands at a time, pausing for 8 seconds or so, and then executing the next 2. This time, it did it at the beginning of a print though whereas before it did it at the end.
Which Duet is this?
