Firmware 2.02 Release candidate 3 now available

Synapsis

I have been using it without any real problem but a funny one.
While I was connected I had to turn my router off. When the router was back online the duet reconnected but the web interface would not connect again, even after a refresh of the page. I closed the browser and reopened it, but nothing it would not connect to the duet.
I had to turn the duet off then on and all was back to normal.

timcurtis67

If you have a panel due try sending an M552 S1to restart the Wifi.

See https://duet3d.dozuki.com/Wiki/GCode#Section_M552_Set_IP_address_enable_disable_network_interface

chrishamm

@adrian52 Thanks for the note, I'll fix this shortly.

@k3lag I'm afraid I cannot reproduce this. I tried it on Firefox (Win+Linux), Edge and Safari (OS X) but it never scrolls up for me. Can you check if the toggling the option "Always show info area and menu" on the Settings makes a difference?

Edit: There you go - v1.22.4 is now official: https://github.com/chrishamm/DuetWebControl/releases/tag/1.22.4

k3lag

@k3lag I'm afraid I cannot reproduce this. I tried it on Firefox (Win+Linux), Edge and Safari (OS X) but it never scrolls up for me. Can you check if the toggling the option "Always show info area and menu" on the Settings makes a difference?

Edit: There you go - v1.22.4 is now official: https://github.com/chrishamm/DuetWebControl/releases/tag/1.22.4

I can't duplicate now either. It was consistent for a few days now suddenly it seems fine. I'll let you know if the problem returns and I'll pay attention to any change in circumstances that may cause it.

k3lag

@k3lag said in Firmware 2.02 Release candidate 3 now available:

@k3lag I'm afraid I cannot reproduce this. I tried it on Firefox (Win+Linux), Edge and Safari (OS X) but it never scrolls up for me. Can you check if the toggling the option "Always show info area and menu" on the Settings makes a difference?

Edit: There you go - v1.22.4 is now official: https://github.com/chrishamm/DuetWebControl/releases/tag/1.22.4

I can't duplicate now either. It was consistent for a few days now suddenly it seems fine. I'll let you know if the problem returns and I'll pay attention to any change in circumstances that may cause it.

It just started doing it again and I noticed what's going on but I don't know why. My printers name on the network is "bigbox.local". If the URL in address bar is "bigbox.local" it does not exhibit the problem. Somehow the URL is changing to "bigbox.local." (notice the "." at the end) and when it is that way it scrolls back to the top after scrolling down. I'm not sure where the extra "." is coming from. If I manually put the "." on the end when it's working correctly the behavior will start as well. For some reason the extra "." is getting added to the end of URL on its own somehow.

BlueDust

Z Baby Stepping doesn't seem to work any more.
I just updated DWC to 1.22.4 to see if that would fix it, and it did not.

Current version
Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet Ethernet 1.02 or later
Firmware Version: 2.02RC3(RTOS) (2018-10-17b2)
Web Interface Version: 1.22.4

Is anyone else having this problem?

garyd9

@bluedust said in Firmware 2.02 Release candidate 3 now available:

Z Baby Stepping doesn't seem to work any more.

It seems to be working for me from both the 1.22.4 DWC (that was just put out today) and from the PanelDue 1.22 released a couple days ago. (It's annoying from the Paneldue due to the "response" popups, but it seems to work.)

What symptoms are you seeing that suggest it's not working?

claustro

M557 now supports a P parameter to set the number of X and Y points, as an alternative to using the S parameter to set the spacing

So I can write M557 X30:260 Y15:245 P9
Instead M557 X30:260 Y15:245 S57.5
and the firrmware automatically calculate probe point spacing right?
i

dc42

@claustro said in Firmware 2.02 Release candidate 3 now available:

M557 now supports a P parameter to set the number of X and Y points, as an alternative to using the S parameter to set the spacing

So I can write M557 X30:260 Y15:245 P9
Instead M557 X30:260 Y15:245 S57.5
and the firrmware automatically calculate probe point spacing right?
i

Yes, that's correct.

fma

@k3lag said in Firmware 2.02 Release candidate 3 now available:

@dc42 updated to 2.02rc3 and dwc 1.22.4-b1. Since upgrading whenever I scroll down in DWC it automatically scrolls back up a couple seconds later. Very irritating. I'm using Safari 12.0. This hasn't been a problem with any previous version. It seems to print fine however.

Could it be related to this bug? https://www.thingiverse.com/thing:2448907

On previous versions of Chromium, I was able to set the 'enable-scroll-anchoring' to true, and it fixed the problem. But in recent versions, this flag does not exists anymore, and the bug came back (on Thingiverse, I didn't try Duet latest firmware).

BlueDust

@garyd9
I press the neagtive or positive buttons and the nozzle doesn't get any closer or further from the bed. I use this all thr time adjust the squish during the first layer.
I didn't reboot my printer a second time after installing the 3rd beta of the firmware. I will do that when I get home and see if that fixes it.

garyd9

@bluedust said in Firmware 2.02 Release candidate 3 now available:

@garyd9
I press the neagtive or positive buttons and the nozzle doesn't get any closer or further from the bed. I use this all thr time adjust the squish during the first layer.
I didn't reboot my printer a second time after installing the 3rd beta of the firmware. I will do that when I get home and see if that fixes it.

How big are your baby steps configured for? Does DWC claim that the baby steps are taking place? (It shows the current babystep.) On mine, I never actually measured the nozzle distance to ensure that the babysteps were happening, but I know that I'm about 0.04mm too high on my manual level, and if I don't babystep, everything curls up.

SupraGuy

I hadn't thought much about this, but I'm seeing something similar.

Baby steps are configured as 0.05mm, but I'm not seeing any effect on the machine. It changes the compensation factor on the DWC, (I had it showing up to a full 3mm of compensation at one point) but it didn't move the Z axis motors at all, so far as I could see.

My last few prints, I just stopped using it, because I thought that it might be something in my Z speed/acceleration settings not letting it get started for such a small move.

This started when I upgraded to 2.02RC2, still happening with RC3, however I also changed my Z lead screws when I upgraded to 2.02RC2 from 5mm/0.8mm lead to 8mm/8mm lead (4000 steps/mm to 400 steps/mm.) I had assumed that it had to do with the change in lead screws. I don't have those values from my config.g in front of me at the moment.

BlueDust

@garyd9
Default change is .05mm and it does say its changed. Usually I change this value from .25 to .35. After a 5 point calibration, start a print, change this Z level to around .25 / .35 to get a good squish going.
Usually stays pretty close to that initial adjustment after many 5 point calibrations until I power off/on again. And then I have to make this adjustment again.

Right now when I push the button - or + no changes are made, and as such, my prints don't always stick. This was working a 2 days ago. Appears like it stopped a day or two after I installed beta 3. I don't reboot the machine often so I may have rebooted it for the first time after installing the beta, but emergency stopping a print or something, that started this issue... Just saying that possible. Will reboot again when I get home. If that doesn't fix it will reinstall the current beta and if that doesn't help may reinstall beta 2 to confirm, as it was working for me.

Thanks

garyd9

@bluedust

WARNING: What follows is a WAG. Well, and educated WAG, but still a guess.

I wonder what the actual gcode DWC is sending - in particular if its actually sending a M290 R0 or M290 R1.

I wonder this because there's a commit that appears to be functionally different for R0. Previously, it would call PushBabyStepping(val - current). Now it's calling PushBabyStep(val)

I really don't understand the code I'm looking at, and my initial impression is that this change fixes a bug where the absolute mode (R0) was doing relative changes instead of absolute changes.

dc42

The only change made to baby stepping in RRF 2.03RC3 is to remove the limit of +/-1mm change when using absolute mode.

Old code:

const bool absolute = (gb.Seen('R') && gb.GetIValue() == 0);
float difference = (absolute) ? fval - currentBabyStepZOffset : fval;	
difference = constrain<float>(difference, -1.0, 1.0);
currentBabyStepZOffset += difference;

New code:

const bool absolute = (gb.Seen('R') && gb.GetIValue() == 0);
float difference;
if (absolute)
{
	difference = fval - currentBabyStepZOffset;
	currentBabyStepZOffset = fval;
}
else
{
	difference = constrain<float>(fval, -1.0, 1.0);
	currentBabyStepZOffset += difference;
}

garyd9

Like I said (typed...)

@garyd9 said in Firmware 2.02 Release candidate 3 now available:

I really don't understand the code I'm looking at, and my initial impression is that this change fixes a bug where the absolute mode (R0) was doing relative changes instead of absolute changes.

For some reason when I was staring at the diff, it wasn't clicking in my head and I wanted to be clear about that when I posted. I had intended to followup when I got home, but I'm married with children. (I think that explains everything.)

I did see some weirdness with babystepping last night myself, but that was a case of the paneldue reporting an offset of 0.00 while DWC was reporting -0.02. I think DWC was correct, but it's very difficult to measure 0.02mm while the nozzle is moving.

tjb1

@garyd9 said in Firmware 2.02 Release candidate 3 now available:

@bluedust

WARNING: What follows is a WAG. Well, and educated WAG, but still a guess.

I wonder what the actual gcode DWC is sending - in particular if its actually sending a M290 R0 or M290 R1.

I wonder this because there's a commit that appears to be functionally different for R0. Previously, it would call PushBabyStepping(val - current). Now it's calling PushBabyStep(val)

I really don't understand the code I'm looking at, and my initial impression is that this change fixes a bug where the absolute mode (R0) was doing relative changes instead of absolute changes.

You can see what DWC is sending the Duet by opening the Developer Tools for your browser (usually F12), select the Network tab and then click any of the buttons and you'll see something along the lines of http://ip_address/rr_gcode?gcode=

BlueDust

@garyd9
I would expect it to be impossible (or close to) to measure those small changes. I just print and change it during that first layer and see the difference. But even changing it 1mm + or - doesn't do anything anymore. And that should make big obvious changes to the print.
I am back to recalibrating Z with every power on (before I discovered the baby stepping button). Not a big deal, just takes more time.

Thanks for looking into this.

3DOeste

Hi, I have a problem when running G29 to probe the bed. For some reason the moving speed between probe point it's extremely slow. I have M558 P9 H3 F100 T2000, but no matter what T value I put, it always moves at 1.7mm/s.

It was working fine last time I used it, and I sincerely don't remember to have modified anything else (but perhaps I did...)

Any clue?