Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    issues after upgrading to RRF3.2 beta3

    Scheduled Pinned Locked Moved
    Beta Firmware
    5
    45
    1.5k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Marco Bonaundefined
      Marco Bona
      last edited by

      @dc42, The "Assertion failed" error began to occur with RRF3.2 beta2, then I tried to downgrade to beta 1 and finally to 3.1.1 but in both cases it continued to give problems. I do not understand whether it is a consequence or whether there is any other problem that occurred at that time.
      I also tried to format and replace the sd card but nothing changed.
      For this error " Error: Failed to get macro response within 8000ms from SBC (channel File)" it seems that it concerns the clean_nozzle.g file that I allege, initially if I remember correctly it was (channel daemon) or something similar. I had to delete the daemon.g file which contained a voltage check because it was repeated every 10 seconds.
      Remember that the file clean_nozzle in RRF3.2 has no problem, I am still using it in standalone mode. I check in the morning if with beta3 in standalone mode it creates problems and I let you know.
      clean_nozzle.g

      1 Reply Last reply Reply Quote 0
      • dc42undefined
        dc42 administrators
        last edited by

        Thanks for providing the file.

        The "Assertion failed" errors are a known issue with 3.2beta2 (fixed in beta3) when you use M701 or M702. Do you use those commands?

        Duet WiFi hardware designer and firmware engineer
        Please do not ask me for Duet support via PM or email, use the forum
        http://www.escher3d.com, https://miscsolutions.wordpress.com

        1 Reply Last reply Reply Quote 0
        • Marco Bonaundefined
          Marco Bona
          last edited by

          @dc42, no, I'm not using them. The behavior is blocking when printing and restarting the SBC.
          I'm going to cheer up an old report that I saved myself, I hope it can help.

          === Diagnostics ===
          RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode)
          Board ID: 08DJM-956L2-G43S4-6JKF0-3S86T-9A5YD
          Used output buffers: 1 of 40 (24 max)
          === RTOS ===
          Static ram: 154604
          Dynamic ram: 164252 of which 44 recycled
          Exception stack ram used: 272
          Never used ram: 74044
          Tasks: NETWORK(ready,1968) HEAT(blocked,1188) CanReceiv(suspended,3512) CanSender(suspended,1488) CanClock(blocked,1452) TMC(blocked,192) MAIN(running,4488) IDLE(ready,76)
          Owned mutexes:
          === Platform ===
          Last reset 00:00:35 ago, cause: software
          Last software reset at 2020-10-24 09:35, reason: Assertion failed, spinning module GCodes, available RAM 72892 bytes (slot 2)
          Software reset code 0x4123 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a80f BFAR 0x00000000 SP 0x2045fe9c Task MAIN
          Stack: 00000194 00484cd0 00463dbf 00000000 00000000 00000001 2044cff8 2044cfa8 2043f1a8 00000001 2043f120 
          Error status: 0
          MCU temperature: min 25.2, current 25.8, max 26.0
          Supply voltage: min 24.1, current 24.1, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
          12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0
          Driver 0: standstill, reads 41315, writes 19 timeouts 0, SG min/max 0/0
          Driver 1: standstill, reads 41315, writes 19 timeouts 0, SG min/max 0/0
          Driver 2: standstill, reads 41318, writes 17 timeouts 0, SG min/max 0/0
          Driver 3: standstill, reads 41317, writes 18 timeouts 0, SG min/max 0/0
          Driver 4: standstill, reads 41319, writes 17 timeouts 0, SG min/max 0/0
          Driver 5: standstill, reads 41319, writes 17 timeouts 0, SG min/max 0/0
          Date/time: 2020-10-24 09:36:26
          Slowest loop: 5.83ms; fastest: 0.14ms
          === Storage ===
          Free file entries: 10
          SD card 0 not detected, interface speed: 37.5MBytes/sec
          SD card longest read time 0.0ms, write time 0.0ms, max retries 0
          === Move ===
          Hiccups: 0(0), FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms
          Bed compensation in use: none, comp offset 0.000
          === MainDDARing ===
          Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
          === AuxDDARing ===
          Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
          === Heat ===
          Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = 3 -1 -1 -1
          Heater 1 is on, I-accum = 0.0
          === GCodes ===
          Segments left: 0
          Movement lock held by null
          HTTP* is ready with "M122" in state(s) 0
          Telnet is idle in state(s) 0
          File is idle in state(s) 0
          USB is idle in state(s) 0
          Aux is idle in state(s) 0
          Trigger* is idle in state(s) 0
          Queue is idle in state(s) 0
          LCD is idle in state(s) 0
          SBC is idle in state(s) 0
          Daemon* is doing "G4 S30" in state(s) 0 0, running macro
          Aux2 is idle in state(s) 0
          Autopause is idle in state(s) 0
          Code queue is empty.
          === Network ===
          Slowest loop: 1.29ms; fastest: 0.01ms
          Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
          HTTP sessions: 0 of 8
          - Ethernet -
          State: disabled
          Error counts: 0 0 0 0 0
          Socket states: 0 0 0 0 0 0 0 0
          === CAN ===
          Messages sent 156, longest wait 2ms for type 6018
          === Linux interface ===
          State: 0, failed transfers: 1
          Last transfer: 21ms ago
          RX/TX seq numbers: 44842/1122
          SPI underruns 0, overruns 0
          Number of disconnects: 0
          Buffer RX/TX: 0/0-0
          === Duet Control Server ===
          Duet Control Server v3.1.1
          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: 4096
          Configured SPI speed: 8000000 Hz
          Full transfers per second: 22.78
          
          
          1 Reply Last reply Reply Quote 0
          • Marco Bonaundefined
            Marco Bona
            last edited by

            @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

            1 Reply Last reply Reply Quote 0
            • dc42undefined
              dc42 administrators
              last edited by

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

              Duet WiFi hardware designer and firmware engineer
              Please do not ask me for Duet support via PM or email, use the forum
              http://www.escher3d.com, https://miscsolutions.wordpress.com

              1 Reply Last reply Reply Quote 0
              • Marco Bonaundefined
                Marco Bona
                last edited by

                @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

                1 Reply Last reply Reply Quote 0
                • jay_s_ukundefined
                  jay_s_uk
                  last edited by

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

                  Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

                  1 Reply Last reply Reply Quote 0
                  • Marco Bonaundefined
                    Marco Bona
                    last edited by

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

                    1 Reply Last reply Reply Quote 0
                    • Marco Bonaundefined
                      Marco Bona
                      last edited by

                      @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_ukundefined 1 Reply Last reply Reply Quote 0
                      • jay_s_ukundefined
                        jay_s_uk @Marco Bona
                        last edited by

                        @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

                        Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

                        1 Reply Last reply Reply Quote 0
                        • Marco Bonaundefined
                          Marco Bona
                          last edited by

                          @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

                          1 Reply Last reply Reply Quote 0
                          • jay_s_ukundefined
                            jay_s_uk
                            last edited by

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

                            Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

                            1 Reply Last reply Reply Quote 0
                            • Marco Bonaundefined
                              Marco Bona
                              last edited by

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

                              1 Reply Last reply Reply Quote 0
                              • jay_s_ukundefined
                                jay_s_uk
                                last edited by

                                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.

                                Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

                                1 Reply Last reply Reply Quote 0
                                • Marco Bonaundefined
                                  Marco Bona
                                  last edited by

                                  @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

                                  1 Reply Last reply Reply Quote 0
                                  • Marco Bonaundefined
                                    Marco Bona
                                    last edited by

                                    @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

                                    1 Reply Last reply Reply Quote 0
                                    • Marco Bonaundefined
                                      Marco Bona
                                      last edited by

                                      @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
                                      
                                      1 Reply Last reply Reply Quote 0
                                      • Marco Bonaundefined
                                        Marco Bona
                                        last edited by

                                        @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?

                                        dc42undefined 1 Reply Last reply Reply Quote 0
                                        • dc42undefined
                                          dc42 administrators @Marco Bona
                                          last edited by

                                          @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.

                                          Duet WiFi hardware designer and firmware engineer
                                          Please do not ask me for Duet support via PM or email, use the forum
                                          http://www.escher3d.com, https://miscsolutions.wordpress.com

                                          1 Reply Last reply Reply Quote 0
                                          • Marco Bonaundefined
                                            Marco Bona
                                            last edited by

                                            @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

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Unless otherwise noted, all forum content is licensed under CC-BY-SA