issues after upgrading to RRF3.2 beta3
-
@dc42, the issues that worry me most are those related to the "Assertion failed" error which is from the downgrade to version 3.1.1 that are bothering me and this "Error: Failed to get macro response within 8000ms from SBC (channel File)" which I cannot understand what it refers to. I look forward to your feedback so that we can correct the mistakes and work in total serenity. I believe that duet boards work properly, unfortunately I have no way to verify the proper functioning of raspberry, I would also be willing to replace it if it may be necessary as many users seem to be not going to give problems. I believe that duet cards work properly, unfortunately I have no way to verify the proper functioning of the raspberry, I would also be willing to replace it if it may be necessary as many users seem to be not going to give problems. Let me know, thank you again.
Marco -
@Marco-Bona said in issues after upgrading to RRF3.2 beta3:
@dc42, the issues that worry me most are those related to the "Assertion failed" error which is from the downgrade to version 3.1.1 that are bothering me and this "Error: Failed to get macro response within 8000ms from SBC (channel File)" which I cannot understand what it refers to.
To be clear: the "Assertion failed" only occurred after you downgraded to 3.1.1. Correct?
I will ask @chrishamm to look at the "Failed to get macro response within 8000ms from SBC" error. When do you see that error? If running a particular macro provokes it, please provide that macro file.
-
@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 -
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?
-
@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 -
@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
-
Thank. Please provide the daemon.g file you were using.
-
-
@Marco-Bona
daemon.g is ran every second so adding a 60 second delay really isn't a good idea. -
@jay_s_uk, the purpose is to view the voltage periodically, it always worked
-
@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 foundI 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 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
-
@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
-
did you wait at least 60 seconds for the queue to flush? or even better, restart the machine?
-
@jay_s_uk , of course, I also took off the power to be sure
-
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. -
@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 clearanceof 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
-
@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
-
@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 -
@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?
