issues after upgrading to RRF3.2 beta3

Marco Bona

@dc42, this is the error I made when I read the daemon.g file in SBC mode:

Error: Failed to get macro response within 8000ms from SBC (channel Daemon)

It is repeated every 10 seconds, although there is a 30 seconds delay in the file

dc42

Thank. Please provide the daemon.g file you were using.

Marco Bona

@dc42 ,Here it is, as you can see it is a very simple command.

daemon.g

Now I'm trying to reformat sd card and perform step-by-step installation. I'll update you as soon as possible

jay_s_uk

@Marco-Bona
daemon.g is ran every second so adding a 60 second delay really isn't a good idea.

Marco Bona

@jay_s_uk, the purpose is to view the voltage periodically, it always worked

Marco Bona

@dc42 , i reset everythingand I encounter the same problems as before. When I recall the file with M98 P"clean_nozzle.g" now this error also appears:

Error: Failed to get macro response within 8000ms from SBC (channel HTTP)
Warning: Macro file clean_nozzle.g not found

I also point out that the machine is very slow when performing homing while if I delete daemon.g during homing it works correctly

jay_s_uk

@Marco-Bona said in issues after upgrading to RRF3.2 beta3:

I also point out that the machine is very slow when performing homing while if I delete daemon.g during homing it works correctly

@Marco-Bona yes, because you're blocking a system file by delaying it for 60 seconds which, as i pointed out before, is not a good idea. it gets ran every second and then blocks for 60 seconds, which will block system resources

Marco Bona

@jay_s_uk , I would like to give you reason but even eliminating the delay does not change the behavior, explain it to me now

jay_s_uk

did you wait at least 60 seconds for the queue to flush? or even better, restart the machine?

Marco Bona

@jay_s_uk , of course, I also took off the power to be sure

jay_s_uk

Could be due to the issue that dc42 mentioned about echos.
Try using M118.
And why send a message when the voltage is ok? why not just limit to sending a message when its not ok. That way, you won't get deluged by messages.

Marco Bona

@dc42, I did some evidence, it would seem that by deleting this part

if move.axes[2].userPosition <= 40
 G90
 G1 Z40 F900 ;move z bed for clearance

of clean_nozzle.g there are no errors. Politely you can verify that the code is right even if I do not explain why in standalone mode it has no problems. The curious thing is that it would seem that eliminating conditional instructions there are no problems

Marco Bona

@jay_s_uk , I tried with M118 but the problem persists. As for using the file it was a simple proof that unfortunately it doesn't work as it should

Marco Bona

@dc42, I confirm that the problem is related to conditional codes, I put these instructions inside daemon.g and the errors are gone

; daemon.g
;Constantly runs in background to check outputs etc
M300 S3000 P500                                             ; sound alert, required deviation could not be achieved
G4 S30

Marco Bona

@dc42, I found what causes the error, it turns out to me that if I enter any command before the if loop you do not receive error messages, for example in my file clean_nozzle.g I entered an M400 command before the if loop and the error was no longer repeated, as in daemon.g inserting "M300 S3000 P500; sound warning, the required deviation was not reached" before the if loop seems to be working properly. Can you verify that it's correct please?

dc42

@Marco-Bona said in issues after upgrading to RRF3.2 beta3:

@dc42, I found what causes the error, it turns out to me that if I enter any command before the if loop you do not receive error messages, for example in my file clean_nozzle.g I entered an M400 command before the if loop and the error was no longer repeated, as in daemon.g inserting "M300 S3000 P500; sound warning, the required deviation was not reached" before the if loop seems to be working properly. Can you verify that it's correct please?

I'll ask @chrishamm to look into that. It appears that in SBC mode there are still some issues with the way commands are executed and responses handled.

I took a look at the assertion failure that you reported for RRF 3.1.1 but unfortunately the stack trace was not deep enough for me to determine the cause. The RRF 3.2beta firmwares provide a longer stack trace.

Marco Bona

@dc42, if you want to delve deeper into this, maybe it might help.

M122
Diagnostica .
RepRapFirmware per Duet 3 MB6HC versione 3.2-beta1 in esecuzione su Duet 3 MB6HC v0.6 o 1.0 (modalità SBC)
ID scheda: 08DJM-956L2-G43S4-6JKF0-3S86T-9A5YD
Buffer di output usati: 1 di 40 (22 max)
RTOS .
Ariete statico: 154820
Ariete dinamico: 134956 di cui 24 riciclati
Stack di eccezioni utilizzato: 272
Ariete mai utilizzate: 103144
Attività: HEAT(blocked,308) CanReceiv(blocked,901) CanSender(blocked,372) CanClock(blocked,356) TMC(blocked,49) MAIN(running,1140) IDLE(ready,19)
Mutex di proprietà:
Piattaforma .
Ultimo ripristino 00:00:06 fa, causa: software
Ultima reimpostazione software a 2020-10-24 10:47, motivo: AssertionFailed, GCodes spinning, disponibile RAM 101936, slot 0
Codice di reimpostazione software 0x4123 HFSR 0x0000000 CFSR 0x00000000 ICSR 0x0444a80f BFAR 0x00000000 SP 0x2045fea4 Attività MAIN
Stack: 00000193 00485260 004666f3 a5a5a5 2042f5f4 20412b68 20445e20 20446590 2043f4f0 00000001 2043f468 2043f58c 2043f588 20412934 0046bb15 00000003 004328cf 2043efe8 000d880c 20435b68 000bd098 2043efe8 00000002 20435b68 000bd098 00000000 0000 eaa60
Stato di errore: 0x020
Temperatura MCU: min 25,8, corrente 26,4, max 26,5
Tensione di alimentazione: min 24.1, corrente 24.1, max 24.1, eventi di tensione: 0, eventi di tensione: 0, potenza buona: sì
12 anni Tensione ferroviaria V: min 12.0, corrente 12.1, max 12.1, sotto eventi di tensione: 0
Driver 0: posizione 0, fermo, letture 29819, scrive 19 timeout 0, SG min/max 0/0
Driver 1: posizione 0, fermo, legge 29820, scrive 19 timeout 0, SG min/max 0/0
Driver 2: posizione 0, fermo, letture 29822, scrive 17 timeout 0, SG min/max 0/0
Driver 3: posizione 0, fermo, legge 29822, scrive 18 timeout 0, SG min/max 0/0
Driver 4: posizione 0, fermo, legge 29823, scrive 17 timeout 0, SG min/max 0/0
Driver 5: posizione 0, fermo, legge 29823, scrive 17 timeout 0, SG min/max 0/0
Data/ora: 2020-10-24 10:48:19
Ciclo più lento: 5,12ms; più veloce: 0,14ms
Archiviazione di archiviazione
Voci file gratuite: 10
Scheda SD 0 non rilevata, velocità interfaccia: 37,5MByte/sec
SD scheda più lunga tempo di lettura 0.0ms, tempo di scrittura 0.0ms, massimo tentativi 0
Spostamento .
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms
Compensazione del letto in uso: nessuno, comp offset 0.000
Il controllo MainDDAring
Spostamenti pianificati: 0, spostamenti completati: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 stato CDDA: -1
AuxDDARing
Spostamenti pianificati: 0, spostamenti completati: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 stato CDDA: -1
- Calore
Riscaldatori per letti : 0 -1 -1 -1 -1  -1 -1 -1 -1 -1 -1 -1, chamberHeaters - 3 -1 -1 -1
Riscaldatore 1 è su, I-accum 0,0
GCodes
Segmenti a sinistra: 0
Blocco di movimento mantenuto da null
HTTP è pronto con "M122" in stato/i 0
Telnet è inattivo nello stato(i) 0
Il file è inattivo nello stato(i) 0
L'USB è inattivo nello stato(s) 0
Aux è inattivo in stato/i 0
Trigger sta eseguendo "G4 S5" in stato(s) 0 0, esecuzione macro
La coda è inattiva nello stato(s) 0
LCD è inattivo in stato/i 0
SBC è inattivo nello stato(s) 0
Daemon sta eseguendo "G4 S30" in state(s) 0 0, eseguendo macro
Aux2 è inattivo in stato/i 0
La stampa automatica è inattiva nello stato(s) 0
La coda di codice è vuota.
Rete .
Slowest loop: 0.00ms; fastest: 5726623.00ms
Stati del risponditore:
Sessioni HTTP: 0 di 8
- Ethernet -
Stato: disabilitato
Numero di errori: 0 0 0 0 0
Stati socket: 0 0 0 0 0 0 0 0 0 0
- Può
Messaggi inviati 38, timeout di invio 38, attesa più lunga 2ms per il tipo 6021, buffer CAN liberi 48
Interfaccia SBC
Stato: 0, trasferimenti non riusciti: 1
Ultimo trasferimento: 17ms fa
Numeri seq RX/TX: 21208/197
Sottoccarichi SPI 0, sforamenti 0
Numero di disconnessioni: 0
Buffer RX/TX: 72/184-0
Server di controllo del duetto
Server di controllo duet v3 .2.0-beta1
Grilletto:
Buffered code: G4 S5
Buffered code: M42 P6 S70
Buffered code: M400 ; wait for current moves to finish
Buffered code: M18
==> 112 bytes
Executing macro config.g, started by system
> Next stack level
Daemon:
Buffered code: G4 S30 ; delay running again or next command for at least 60 seconds
==> 32 bytes
Executing macro daemon.g, started by system
> Next stack level
Code buffer space: 3912
Configured SPI speed: 8000000 Hz
Full transfers per second: 19.92

Now I'm doing tests in SBC mode with beta3 and it looks like it's working properly. I update you in case I encounter other problems.
Thanks.
Marco

Luke'sLaboratory

@dc42 I apologize for not seeing your message sooner. My error was on a 3HC, not a toolboard. I flashed the fixed firmware and it works again. I'll test out a print later this afternoon.

Thank you VERY much. Sorry about the headache of trying to find a toolboard flaw.

Luke

dc42

@Luke-sLaboratory said in issues after upgrading to RRF3.2 beta3:

@dc42 I apologize for not seeing your message sooner. My error was on a 3HC, not a toolboard. I flashed the fixed firmware and it works again. I'll test out a print later this afternoon.

Thank you VERY much. Sorry about the headache of trying to find a toolboard flaw.

Luke

No problem!

chrishamm

@Marco-Bona Thanks, I could reproduce and fix the macro timeout problem. I suppose you could work-around this problem by calling a code before the first if-statement in daemon.g. We'll include this fix in the upcoming 3.2-b1+1 hotfix release.