New experimental firmware 1.20beta2

dc42

I've just released this for the Duet Wifi and Duet Ethernet in the usual Edge folders in github. Highlights of this release include:

Faster response to loss of power
Initial support for polar printers
More network diagnostics for the Duet WiFi
Bug fixes to the motion planning system, which should result in smoother motion in some situations and might fix other motion-related issues

For the full change list and upgrade notes, see https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md.

KeeganB

OOOOOOO, I'll get this uploaded tonight!

just the standard upgrade process and order for these David?

kazolar

Can't wait to try it out – super excited. 40 minutes left in the office -- then kids, dinner -- then printer...

roboduet

M915: Configure motor stall detection
Rn Action to take on detecting a stall from any of these drivers: 0 = don't pause print, 1 = pause print, 2 = pause and execute the restart macro

Is it possible to log stall detection events into log file instead of pausing?

dc42

@KeeganB:

OOOOOOO, I'll get this uploaded tonight!

just the standard upgrade process and order for these David?

If you are already on 1.20beta1 then the upgrade order doesn't matter.

dc42

@roboduet:

M915: Configure motor stall detection
Rn Action to take on detecting a stall from any of these drivers: 0 = don't pause print, 1 = pause print, 2 = pause and execute the restart macro

Is it possible to log stall detection events into log file instead of pausing?

Good idea, I'll probably add that in the next version.

Jarery

my part fans seem to have stopped working since update, may not be related, but right now can't control fan with any of the 3 sliders on the browser page, including the hotend fan.
will test more….

kazolar

Definitely improved from b1 – I did get into the weird slow state 1 time -- I had all axis homed, and then moved Z up 4 or 5 times 50mm at time via the screen, and it started to think a lot before each move. After a reboot I was moving Z up and down with no issues, but only Z was homed at that point (Z+U in my config) didn't freeze up during repeated home moves, and multiple other axis moves and G32 and G30 commands. So for my issue it's mostly fixed. I'm going to try tomorrow and see if I can switch the Z lead screws to be Z and B instead of Z and U -- as that would be the ideal configuration as I'd be able to hide B. Also homing Z works fine no matter how far it has to travel (tried homing from near the bottom -- around 400mm -- it homed fine)

I see there is a new feature for M585 -- I have each of the 4 independent hotends equipped with a piezo, so they all can probe the bed. I don't think I understand how G10 and M585 relate.
I was trying to configure G32 bed.g to use 2 of the hotends to probe the bed in order to compute leadscrew adjustments. I did it kinda wonky, I moved tool 0 to X10 Y267 (Y267 is the middle where the lead screws are) -- then did a G30, then I moved V (2nd X carriage) to V600 and then moved X to -32 -- which is off the bed and then I used G92 to set X to 600 as tool 0 can't reach X600, but tool 1 can, so then I used G30 to probe 2nd point. Ideally I could somehow have the machine know the Z offsets between tool 0 and tool 1 and use tool 0 to probe one lead screw point and tool 1 to probe the other.

zlowred

I'm getting wifi connection issues after upgrading to the latest version. When using DuetWiFiServer 1.20beta2 the printer becomes unreachable via wifi in around 1 minute after starting it. M122 says wifi sleep mode: modem
When using DuetWiFiServer 1.20alpha1 it seems to work fine; M122 says wifi sleep mode: unknown

darookee

After updating my CoreXY can't home. At first it reported X-62Y-123 (or similar), at the second try it reported X0Y-0.4 and now it reports X-0.0Y-100.3 after trying to home X and Y. It also reports

Error: Homing failed

These are in my config.g

M574 X1 Y1 Z0 S0
M208 X-11 Y-0.75 Z0 S1
M208 X200 Y200 Z240 S0

Could this be because of the stall detection feature? I have not configured it, so I was thinking that it will not be used…?

dc42

The "Homing failed" message has nothing to do with the stall detection feature. What it means is that it ran a homing file in response to the homing command you gave it, but the same axes were flagged as not homed after running the file as before.

Were you trying to home all, or specific axes? Which axes show up in DWC as homed, before and after sending the command? Have you created any additional axes using M584?

kazolar

Now I am able to use Z and B for my Z lead screws – homes correctly -- just did a quick test -- swapped U back to my 2nd Y gantry. Now B is use appropriately. So far outside of one freeze up where it looks like it got confused how long moves take after I was move Z up and down after machine was homed -- it's been working.
PS -- any use case instructions for M585 .. the docs are not clear how to apply it.

darookee

@dc42:

Were you trying to home all, or specific axes? Which axes show up in DWC as homed, before and after sending the command? Have you created any additional axes using M584?

First I did home all, then I quickly hit the emergency stop button, because it tried to move waaay out of the printer frame, as it was reporting Y-169 and my Z-homing point is at X100Y100. Then I tried homing X and Y seperately. Directly they were marked as 'not homed' (all buttons orange). I only have X Y Z (and E).

dc42

@darookee:

@dc42:

Were you trying to home all, or specific axes? Which axes show up in DWC as homed, before and after sending the command? Have you created any additional axes using M584?

First I did home all, then I quickly hit the emergency stop button, because it tried to move waaay out of the printer frame, as it was reporting Y-169 and my Z-homing point is at X100Y100. Then I tried homing X and Y seperately. Directly they were marked as 'not homed' (all buttons orange). I only have X Y Z (and E).

At which point(s) did you get the "Homing failed" message?

The buttons will be marked as "not homed" when you ask to home those axes. They should change to "homed" status as each one is completed.

darookee

@dc42:

At which point(s) did you get the "Homing failed" message?
The buttons will be marked as "not homed" when you ask to home those axes. They should change to "homed" status as each one is completed.

The message appeared directly after the homing procedure, the buttons did not change.

Here is my homex.g

; Lift Z relative to current position
G91
G1 Z5 F12000
G90

; Move quickly to X axis endstop and stop there (first pass)
G1 X-205 F1800 S1

; Go back a few mm
G91
G1 X5 F12000
G90

; Move slowly to X axis endstop once more (second pass)
G1 X-205 F360 S1

; Lower Z again
G91
G1 Z-5 F12000
G90

homey.g is the same, just with X. I think I didn't change anything after generating it with the configurator. I certainly did not change anything here after the update.

andreduplessis

@darookee:

After updating my CoreXY can't home. At first it reported X-62Y-123 (or similar), at the second try it reported X0Y-0.4 and now it reports X-0.0Y-100.3 after trying to home X and Y. It also reports

Error: Homing failed

These are in my config.g
M574 X1 Y1 Z0 S0
M208 X-11 Y-0.75 Z0 S1
M208 X200 Y200 Z240 S0
Could this be because of the stall detection feature? I have not configured it, so I was thinking that it will not be used…?

I have the same homing issue on coreXY. After some digging around, I think that the issue creeps in the code where the endstops are checked.
In DDA.cpp around line 1270 the function is returned and part just below it which sets the homed axes is never invoked on a platform that shares drives:

if (endStopsToCheck == 0 || kin.QueryTerminateHomingMove(drive))
{
	MoveAborted();									// no more endstops to check, or this axis uses shared motors, so stop the entire move
	return;
}

I may be smoking something, but that is the only location that I could find where the AxesHomed bits are set. After removing the return, the axes homed like before (barring everything else that might now be broken )

dc42

You are right, it's a bug. I shouldn't have added the 'return' at line 1274. I'll release a new beta tomorrow. In the meantime, CoreXY users should revert to version 1.20beta1.

KeeganB

Is anyone seeing any weird behavior with controlling heaters?

on fresh power up both the hot end and the bed heaters are set to "off." When I click them in DWC I can cycle through to active, but then it goes into "changing tool" mode and I can't do anything until it hits target temp…?

dc42

That's normal behaviour if you have tool change files that wait for your tools to reach temperature.

KeeganB

@dc42:

That's normal behaviour if you have tool change files that wait for your tools to reach temperature.

Ah, I found it! I think these must have been created by the RRF configurator. I recently used it to redo all of my config files fresh in an attempt to solve my wifi issues. Thanks David.