[3.4.0rc1] DWC and RRF feedback/bug report

MaxGyver

After updating to 3.4.0rc1 I am experiencing the following issues:

I have a Duet3 6HC with attached SBC with a fresh installation of the latest firmware.

When an M999 command is executed , messages from before the M999 command are still being displayed after the printer restarts. This is very confusing.
M291 does not work anymore
deamon.g does not work anymore
The Printer/interface becomes unresponsive when a macro containing a "while loop" is executed as the long as condition is "true"

Example: This macro will block any input as long as the heater 2 temperature is over 60°C

while heat.heaters[2].current>=60
  M118 S"Fan ON"
  M106 P0 S1 X0.5; turn on force cooling fan 
  G4 S2 ; wait a sec

M106 P0 S0 ;turn fan off
M118 S"Fan OFF"
G4 S1 ; wait a sec

When an axis end stop is already triggered at the start of a homing sequence, the head will crash into the endstop. I came up with a workaround to check if the endstop is triggered and move the head before proceeding with the normal homing sequence. While this works, I recon that this is not the intended behavior.

Y-Homing sequence with endstop check:

; Y-Homing
G91					; relative positioning

if sensors.endstops[1].triggered=true ;check if Y-Endstop is already triggered
 M564 H0 ; allow movement of unhomed axes
 G1 H0 Y-5  ; go back a few mm
 M564 H1 ; forbid movement of unhomed axes
endif

G1 H1 Y+330 F8000	; coarse home Y
G1 H0 Y-5  			; go back a few mm
G1 H1 Y+6 F600		; fine home Y
G90					; absolute positioning

dc42

@maxgyver said in [3.4.0rc1] DWC and RRF feedback/bug report:

After updating to 3.4.0rc1 I am experiencing the following issues:

When an M999 command is executed , messages from before the M999 command are still being displayed after the printer restarts. This is very confusing.

I agree, it's confusing. We'll look at fixing this.

M291 does not work anymore

It's working for me, and I don't think anyone else has reported it. There has been a minor change to when some M291 messages are displayed, see the release notes.

deamon.g does not work anymore

I presume you mean daemon.g. Again, it's working for me, and I don't think anyone else has reported it.

The Printer/interface becomes unresponsive when a macro containing a "while loop" is executed as the long as condition is "true"

It's always been the case that when you run a macro, further input from the input channel that invoked the macro is blocked. Input from other channels should not be blocked.

When an axis end stop is already triggered at the start of a homing sequence, the head will crash into the endstop. I came up with a workaround to check if the endstop is triggered and move the head before proceeding with the normal homing sequence. While this works, I recon that this is not the intended behavior.

This is an issue when the axis motor concerned is driven from a CAN-connected expansion board. I've just fixed it, and the fix will be in the forthcoming RC2. Meanwhile there is a preview build at https://www.dropbox.com/sh/2dt7sbqpx6l74np/AADn4-lpcil1iqnWKkiVri3Ia?dl=0.

MaxGyver

@dc42

I agree, it's confusing. We'll look at fixing this.

Thank you!

It's working for me, and I don't think anyone else has reported it. There has been a minor change to when some M291 messages are displayed, see the release notes.

I did not find anything in the release notes that would explain my Problem.

M291 seems to run without displaying a message.

M291 P"This is a Test" R"Test" S0 T3

Will not display or do anything.

M291 P"This is a Test" R"Test" S1 T0

Will not display the message and block the rest of the macro. M292 resumes the execution.

I presume you mean daemon.g. Again, it's working for me, and I don't think anyone else has reported it.

Correct, sry for the typo!
I got it working by removing the space that I must have accidentally put in the filename of daemon.g

This is an issue when the axis motor concerned is driven from a CAN-connected expansion board. I've just fixed it, and the fix will be in the forthcoming RC2. Meanwhile there is a preview build at https://www.dropbox.com/sh/2dt7sbqpx6l74np/AADn4-lpcil1iqnWKkiVri3Ia?dl=0.

This resolved the issue. Thank you very much!

dc42

@maxgyver where are you sending the M291 command from, and where are you expecting it to be displayed?

The relevant line in the release notes is this:

M291 commands are now executed as soon as they are processed. Previously, non-blocking M291 messages were delayed until previous movement commands had been completed.

MaxGyver

@dc42

I am expecting the message to be displayed on the web interface when a macro file run that contains a M291 command. When I run a macro, no message is displayed and if the M291 is blocking the macro will only be executed until the M291 command.

When I send M291 command from the web interface command line, I get the same result.

On 3.3 beta7 message boxes where displayed correctly

dc42

@maxgyver are you running in standalone mode or with attached SBC?

Do you have an attached PanelDue, and if so, is the M291 message displayed on that?

Do you have just one DWC session to the Duet, or more than one?

Related report: https://forum.duet3d.com/topic/27253/3-4rc1-issue-with-m291-in-start-g

MaxGyver

@dc42

I am running with attached SBC (RPI4+RPI Display) So I am running two DWC sessions at once most of the time. The messages do not show up on the RPI Display as well.

M291 S3 messages are not being displayed in DWC when called from a macro (with or without if statements), start.g or command line.

I can also confirm that M291 Was working through all the betas.

chrishamm

@maxgyver Can you please share some demo macros that let me reproduce this problem? I tried different M291 S combinations, multiple browser sessions, and a PanelDue as well. M291 inside an if block worked for me, too.

MaxGyver

@dc42

I have also noticed regular short pauses of roughly 500ms during printing moves. The issue is more prominent during the first few lines of a Print. I did not notice this during jogging the axis or when running a simple speed test macro that is moving the printer's axis at increasing speeds. I am printing in closed loop mode at the moment. Pressure advance, heater feedforward and input shaping are deactivated.

I have a 6HC Mainboard+SBC + 3HC Expansion (RRF 3.4.0rc1) + four 1HCL v1.0 Boards (RRF 3.4.0rc1+2)

EDIT: I just did another test. In open loop mode, the described pauses do not happen!

MaxGyver

@chrishamm

Most of my macros use M291. They all worked flawless in b7. None of them works in rc1.

Here are some examples:

Change Material Tool0.g
bed.g
M291 Test.g

The "M291 Test" Macro shows the M118 messages until M291 S3

EDIT: And blocking M291 can be continued by sending M292. So the issue is really just the message box not being displayed.

dc42

@maxgyver thanks for those macros. I've tested the M291-test.g file on a MB6HC in standalone mode with one DWC session and a PanelDue. It works for me except that if I close the Test2 message in DWC as soon as it appears then the Test3 message does not appear.

chrishamm

@maxgyver Thanks, but all three macros complete as expected on my rc1 setup. Can you disable your adblocker (in case you're using one) and check if that has any effect? Every single message box showed up as intended both on rc1 and my latest rc2 candidate.

PS: When the message box is supposed to be shown but it isn't, it may be worth having a look in the JS console as well (open via F12).

chrishamm

@maxgyver @oozeBot I just finished two new preview builds for DWC for SBC and standalone mode. I did find potential problems in the message box component but they've never shown up on my test setup, so please check if this version fixes your problem.

droftarts

@chrishamm said in [3.4.0rc1] DWC and RRF feedback/bug report:

@maxgyver @oozeBot I just finished two new preview builds for DWC for SBC and standalone mode. I did find potential problems in the message box component but they've never shown up on my test setup, so please check if this version fixes your problem.

This is the correct link for the standalone version.

Ian

MaxGyver

@chrishamm

unfortunately the new version did not fix the issue:

I tried Chrome and Firefox with all plugins/Adblocker disabled.

I also ran a macro containing M291 and was able to log the attached error report from the browser console. log.txt

dc42

@maxgyver please see this post https://forum.duet3d.com/post/271971 and run the test I described there.