Unsolved Issues with macros halting the printer.

[dc42]

@brunofporto said in Issues with macros halting the printer.:

M291 P"Please wait while the bed is being heated up" R"Please Wait" S0 T0 ; Display message
M140 S60 ; Set bed temp to 60
G32 ; Home all axis
M116 ; Wait for heating
M292 Close message
M291 P"Please wait while the bed is being heated up" R"Please Wait" S3 T0 ; Display message
M98 P/MACROS/SUBMACROS/BEEP.G

I'm sorry, I can't reproduce the problem using either your test macro or the full macro (I had to make up the contents of 4 more macros thai it called).

By the way, your test macro is missing a semicolon before the comment "Close message" on the M292 line.

How reproducible is the problem?

My best guess as to why it is hanging is that when you cancel the M291 message box, the M292 command to tell the Duet that it has been cancelled is not being received and/or processed. So I have two suggestions:

1. Connect a PC running YAT or Pronterface etc. and send M111 S1 P3 to enable GCodes debugging. Then you will be able to see whether the M292 command is received.

2. Next time it appears to be stuck, try sending M292 and see whether that un-freezes it.

[brunofporto]

Just happened again...

Freshly started board.

G32

Sent the macro from the 22/11/2018 message above. Appeared the messages informing that the bed and hotend would be heated. Clicked ok and.... halted.

[dc42]

So did you try my suggestions?

[brunofporto]

The complete sequence and used files:

Sent G32 and waited for it to finish:

Executed the Macro:

Clicked ok and then.... halted doing nothing:

Attached bed.g, calibration macro and all sub macros related.

Thanks.

6_1543257949998_bed.g 5_1543257949998_4_Calibrate_ZProbe.g 4_1543257949998_beep.g 3_1543257949998_Center_Nozzle.g 2_1543257949998_Center_Probe.g 1_1543257949998_m_set_low_speeds.g 0_1543257949998_m_set_normal_speeds.g

[brunofporto]

@dc42 I'll..... But the printer is far from a computer and heavy...... As soon as I am able to move it and connect an USB directly I'll try

[brunofporto]

@dc42 Please, in order to avoid moving it unnecessarily, is it possible to monitor via telnet or something?

[dc42]

@brunofporto said in Issues with macros halting the printer.:

@dc42 Please, in order to avoid moving it unnecessarily, is it possible to monitor via telnet or something?

Yes, use the M586 command to enable Telnet.

[brunofporto]

@dc42 said in Issues with macros halting the printer.:

Next time it appears to be stuck, try sending M292 and see whether that un-freezes it

ok.... It receives the M292 command, confirms it, but the printer still busy doing nothing

m111 s1 p3
Debugging enabled for modules: GCodes(3)
Debugging disabled for modules: Platform(0) Network(1) Webserver(2) Move(4) Heat(5) DDA(6) Roland(7) Scanner(8) PrintMonitor(9) Storage(10) PortControl(11) DuetExpansion(12) FilamentSensors(13) WiFi(14) Display(15)
ok
m292
ok
m292
ok

[dc42]

Can you send M122 and get a report?

[brunofporto]

@dc42 Sure! Did while "busy" doing nothing after reproducing the issue:

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02RC4(RTOS) running on Duet Ethernet 1.02 or later
Board ID: 08DGM-956GU-DJMSN-6J9D4-3SJ6S-1BNHD
Used output buffers: 1 of 20 (16 max)
=== RTOS ===
Static ram: 27476
Dynamic ram: 98660 of which 12 recycled
Exception stack ram used: 496
Never used ram: 4428
Tasks: NETWORK(ready,328) HEAT(blocked,1232) MAIN(running,1660) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 00:03:59 ago, cause: software
Last software reset at 2018-11-26 17:26, reason: User, spinning module GCodes, available RAM 4436 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 24.7, current 25.8, max 26.3
Supply voltage: min 24.5, current 24.6, max 24.7, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max 0/250
Driver 1: standstill, SG min/max 0/242
Driver 2: standstill, SG min/max 0/162
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max 0/177
Date/time: 2018-11-26 17:30:11
Cache data hit count 546791891
Slowest loop: 51.83ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 237, MaxWait: 95242ms, Underruns: 0, 0
Scheduled moves: 35, completed moves: 36
Bed compensation in use: none
Bed probe heights: -0.024 -0.046 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 3 allocated, 1 in use
Movement lock held by null
http is doing "M291 P"Please wait while the bed and tool is being heated up" R"Please Wait" S1 T0 " in state(s) 0 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 51.30ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(2) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplex
=== Filament sensors ===
Extruder 0 sensor: position 8.22, ok, framing errors 0, parity errors 0, no calibration data

[dc42]

Thanks. I can see two odd things in that report:

http is doing "M291 P"Please wait while the bed and tool is being heated up" R"Please Wait" S1 T0 " in state(s) 0 0

It is still waiting for the M291 message box to be acknowledged, as if it hasn't received M292. So sending M292 should get it running again.

Scheduled moves: 35, completed moves: 36

Doing one more move than was scheduled doesn't sound right. But I don't think this is part of the problem you are seeing.

I'll review the M292 handling and see if there is any way that a M292 command might be missed.

[brunofporto]

@dc42 Thanks!

I am not sure when this issues started (I think it is with this latest 2.02 series of betas and RCs) but I did not have them before with the same macros.

For now I'll just comment all non critical M291 from these macros

[brunofporto]

@dc42 Same issue with RC5 - not using M291 S0 T0, swapped all of them to S1. The first M291 S1 message does not even appear.

[dc42]

@brunofporto said in Issues with macros halting the printer.:

@dc42 Same issue with RC5 - not using M291 S0 T0, swapped all of them to S1. The first M291 S1 message does not even appear.

If it doesn't appear, no wonder it gets stuck! It's waiting for the M292 command to be returned from DWC to tell it that you have acknowledged the message box. I can't think why it wouldn't appear, other than a network issue. Does your system have a PanelDue, and if so does the message box appear on it?

[brunofporto]

@dc42 Yes I have a PanelDue. No... it does not appear there even when the macro is executed from PanelDue.

Same behavior as DWC: Right after resetting the macro works (it halts at the end of the macro but works until that). But If I execute anything before it (like a G32) it does halt after the first M291 S3 as Busy and does nothing.