v3.2.0 release, babystepping laggy

Cheule

I have been using my PanelDue v3 hardware with generic 4.7" panel for months. It shipped with v1.2.x firmware, and I never bothered to update it.

6 months in, I'm noticing burn-in on key words that are white. I upgrade to 3.2.0 release to see if burn-in has been addressed with a screen saver, and voila! it has.

I immediately notice that the babystepping control as a print starts is very laggy. i.e. i'll push to move the nozzle closer, and the display shows that I have actually done it about 2-3 seconds later. This was instantaneous with the old firmware.

I've felt the Z coupler while babystepping under 3.2.0, and I notice that the actual stepper movement is instantaneous. So it's just a display issue. I contacted a friend of mine with the same PanelDue and generic panel, and he doesn't have the issue, but he's running v3.2.0 rc4. I'm assuming RC4 and release might even be the same code?

Any thoughts on babystepping being laggy to report current Z-Offset?

Thanks so much, and if you need any further info or clarification I'd be glad to provide it.

Phaedrux

Just for clarity what firmware are you running on your Duet and what board?

peter247

@Phaedrux

I think the same problem is on version 3.1.1 .
If you add a model and tell it to print and the bed is now warming up and you go "I need a offset" the offset will add until the bed hits temp.

wilriker

@Cheule This is an unfortunate side-effect of using the ObjectModel as a data source. Once you change the babystep value by pressing the button on PanelDue RRF will update the internal model and with the next default status update PanelDue will see that it will need to fetch one extra detail data block to get the changed babystep value.

Since it only fetches data once per second it will take around 2 seconds to update.

arhi

@wilriker said in v3.2.0 release, babystepping laggy:

Since it only fetches data once per second it will take around 2 seconds to update.

uh, that makes babystepping almost unusable?!

how does it work from the latest DWC ? same or it works like it used to?

wilriker

@arhi said in v3.2.0 release, babystepping laggy:

how does it work from the latest DWC ? same or it works like it used to?

DWC uses the exact same technique it just updates 4 times/s instead of only once per second - that makes the result available in max 500ms. I am looking into improving update rate in the next version. That might help.

arhi

@wilriker thanks. I don't think any other operation is as time sensitive from dwc/panel as is babystepping .. 250ms is acceptable but 1sec is really a problem. This changed only on 3.2 or ?

wilriker

@arhi said in v3.2.0 release, babystepping laggy:

@wilriker thanks. I don't think any other operation is as time sensitive from dwc/panel as is babystepping .. 250ms is acceptable but 1sec is really a problem.

As I said before DWC also takes around 500ms.

This changed only on 3.2 or ?

Yes, as mentioned before this is a side-effect of switching to the ObjectModel as data source.

Cheule

Thanks for the explanations. At least I know it’s working as intended and not something wrong with my configuration. I’ll stay with 3.2 for now, I’ve learned to deal with the lag, because it is only on the display side, the actual babystepping in the motors is instantaneous. I can deal with that.

Cheule

@Phaedrux said in v3.2.0 release, babystepping laggy:

Just for clarity what firmware are you running on your Duet and what board?

I’m running Duet 3 board, with whatever the latest DSF/DWC is from apt-get. I did an apt-get update and install just this week via SBC. Sorry to not quote the actual version number, but the printer/sbc is off at the moment and I’m away from my workshop.

nhof

Could you just locally cache and display the babystep request on the paneldue, until the object model updates it for real? Kinda hacky but it might help smooth out the user experience if you can't get the update rate up enough.

wilriker

@nhof said in v3.2.0 release, babystepping laggy:

Could you just locally cache and display the babystep request on the paneldue, until the object model updates it for real? Kinda hacky but it might help smooth out the user experience if you can't get the update rate up enough.

That's the plan.