issues after upgrading to RRF3.2 beta3



  • @dc42 , @chrishamm, I'm pointing out the issues I'm experiencing after upgrading to RRF3.2 beta3:
    -it seems that thermistor and heater on the expansion board are not recognized

    Error: M308: Unknown sensor type name "thermistor"
    Warning: M950: Sensor number 3 has not been defined
    

    -a nozzle cleanup file is not detected within sys when present but it runs (in RRF3.2 beta2 it was working properly)

    Warning: Macro file clean_nozzle.g not found
    

    -printing is finished before you start (the bed and heater remain active). I have to restart the printer because in your opinion the print file is still active

    Finished printing file 0:/gcodes/SANDING.gcode, print time was 0h 2m
    

    -this error i don't understand what it refers to

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

    I attached report immediately after print end error:

    M122
    === Diagnostics ===
    RepRapFirmware for Duet 3 MB6HC version 3.2-beta3 running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode)
    Board ID: 08DJM-956L2-G43S4-6JKF0-3S86T-9A5YD
    Used output buffers: 6 of 40 (28 max)
    === RTOS ===
    Static ram: 122124
    Dynamic ram: 140868 of which 88 recycled
    Never used RAM 129112, free system stack 122 words
    Tasks: Linux(ready,73) HEAT(blocked,296) CanReceiv(blocked,869) CanSender(blocked,346) CanClock(blocked,352) TMC(blocked,20) MAIN(running,713) IDLE(ready,19)
    Owned mutexes: HTTP(MAIN)
    === Platform ===
    Last reset 00:03:23 ago, cause: software
    Last software reset at 2020-11-07 16:33, reason: User, none spinning, available RAM 129152, slot 2
    Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0xffffffff Task Linu
    Error status: 0x00
    MCU temperature: min 25.1, current 25.5, max 25.6
    Supply voltage: min 23.9, current 24.1, max 24.2, 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: position 2996, standstill, reads 3060, writes 30 timeouts 0, SG min/max 0/1023
    Driver 1: position -23796, standstill, reads 3061, writes 30 timeouts 0, SG min/max 0/1023
    Driver 2: position 33685, standstill, reads 3064, writes 28 timeouts 0, SG min/max 0/1023
    Driver 3: position 0, standstill, reads 3060, writes 33 timeouts 0, SG min/max 0/979
    Driver 4: position 0, standstill, reads 3070, writes 24 timeouts 0, SG min/max 0/168
    Driver 5: position 160401, standstill, reads 3077, writes 17 timeouts 0, SG min/max 0/0
    Date/time: 2020-11-07 16:36:44
    Slowest loop: 8000.23ms; fastest: 0.11ms
    === 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: 371, MaxWait: 48748ms
    Bed compensation in use: mesh, comp offset 0.000
    === MainDDARing ===
    Scheduled moves 72, completed moves 72, StepErrors 0, LaErrors 0, Underruns [0, 0, 1], CDDA state -1
    === AuxDDARing ===
    Scheduled moves 0, completed moves 0, StepErrors 0, LaErrors 0, Underruns [0, 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 0 is on, I-accum = 0.2
    Heater 1 is on, I-accum = 0.6
    === GCodes ===
    Segments left: 0
    Movement lock held by null
    HTTP* is doing "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 idle in state(s) 0
    Aux2 is idle in state(s) 0
    Autopause is idle in state(s) 0
    Code queue is empty.
    === CAN ===
    Messages sent 882, send timeouts 879, longest wait 1ms for type 6042, free CAN buffers 47
    === SBC interface ===
    State: 0, failed transfers: 0
    Last transfer: 19ms ago
    RX/TX seq numbers: 6294/6296
    SPI underruns 0, overruns 0
    Number of disconnects: 0, IAP RAM available 0x20aa0
    Buffer RX/TX: 0/0-0
    === Duet Control Server ===
    Duet Control Server v3.2.0-beta3
    File:
    Finishing macro clean_nozzle.g, started by M98 P"clean_nozzle.g"
    > Next stack level
    Suspended code: G92 E0
    Suspended code: G1 X0 Y160 Z0.15 F2000
    Suspended code: M82 ;absolute extrusion mode
    Suspended code: M117 P"rinting..."
    Suspended code: M82 ;absolute extrusion mode
    Suspended code: M83 ;relative extrusion mode
    Suspended code: M83 ;relative extrusion mode
    Suspended code: G10
    Suspended code: ;LAYER_COUNT:150
    Suspended code: ;LAYER:0
    Suspended code: M107
    Suspended code: M204 T1000
    Suspended code: M566 X720 Y720
    Suspended code: G0 F2400 X16.46 Y-23.203 Z0.2
    Suspended code: M204 P750
    Suspended code: M566 X480 Y480
    Suspended code: G11
    Suspended code: G1 X18.744 Y-21.761 E0.09209
    Pending code: G1 X21.156 Y-20.333 E0.09556
    Pending code: G1 X23.55 Y-19.006 E0.09332
    Pending code: G1 X26.008 Y-17.733 E0.09437
    Pending code: G1 X28.442 Y-16.557 E0.09216
    Pending code: G1 X31.006 Y-15.408 E0.09579
    Code buffer space: 4096
    Configured SPI speed: 8000000 Hz
    Full transfers per second: 31.86
    File /opt/dsf/sd/gcodes/SANDING.gcode is selected, processing
    

    I attached the config.g file that has not been changed since the previous version. For the moment I'm going back to work in standalone mode. I would like answers as soon as possible.
    config.g



  • I am having similar issues after updating to beta 3 - My M308 calls for pt1000 or thermistor are "unknown" and fails out other heater/tool creation. Toolboard+main board are both Beta3.


  • administrators

    @Marco-Bona, I'm sorry to hear that you are experiencing problems. Do you have similar problems in standalone mode, using 3.2beta3?



  • @dc42 ,unfortunately I'm using RRF3.2 beta2 in standalone mode because I have work to finish. If you want tomorrow I can do a check with beta3 so i can give you feedback, I hope positive........
    Given the previous problems I've had, is it possible that my raspberry has a problem?



  • @dc42, I confirm that the problem of thermistors also occurs in standalone mode on RRF3.2 beta3


  • administrators

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

    @dc42, I confirm that the problem of thermistors also occurs in standalone mode on RRF3.2 beta3

    Thanks for testing this. Did you check using M115 that the tool boards were running 3.2beta3 as well as the main board?


  • administrators

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

    I am having similar issues after updating to beta 3 - My M308 calls for pt1000 or thermistor are "unknown" and fails out other heater/tool creation. Toolboard+main board are both Beta3.

    Very strange, I am running a Duet 3 with two tool boards and I don't see any errors. Please provide our config.g file.

    Does the error message appear again if you re-run M98 P"config.g" ?



  • @dc42, I verified that the main board and expansion board were on RRF3.2 beta3.
    The config.g file is attached in the first post below. If you find any errors please report it to me so as to avoid unnecessary error reports.
    Another point that I find strange, in standalone mode I can see messages with "echo" command on panel due while in SBC mode nothing is displayed on panel due or even on the DWC screen, is it a known problem?


  • administrators

    I've just managed to reproduce the "unknown sensor type" on an expansion board, but not yet on a tool board. I am looking into it now.


  • administrators

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

    @dc42, I verified that the main board and expansion board were on RRF3.2 beta3.
    The config.g file is attached in the first post below. If you find any errors please report it to me so as to avoid unnecessary error reports.
    Another point that I find strange, in standalone mode I can see messages with "echo" command on panel due while in SBC mode nothing is displayed on panel due or even on the DWC screen, is it a known problem?

    Is the echo command inside a while-loop ?



  • @dc42, excuse me but I use an expansion board, not a toolboard


  • administrators

    Yes I saw that; but Luke has a similar problem with a tool board.



  • @dc42, no, I'm using an if loop. I attached file to be clearer

    bed.g


  • administrators

    I have located and fixed the problem with EXP3HC boards reporting unknown temperature sensor type and updated the Duet3Firmware-EXP3HC.bin file at https://github.com/Duet3D/RepRapFirmware/releases/tag/3.2beta3. This issue only affected EXP3HC boards.


  • administrators

    Thanks for the file. I'll ask @chrishamm to take a look.



  • @dc42, Thank you. I would like to go into the problem of SBC mode in more detail. If necessary, I remain available to carry out tests


  • administrators

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

    @dc42, Thank you. I would like to go into the problem of SBC mode in more detail. If necessary, I remain available to carry out tests

    @Marco-Bona, I think the issue is that when running with attached SBC, if output is generated inside a while-loop then DSF does not report that output until the entire loop has completed. We found this on Friday but we didn't want to hold up the release any more. Your bed.g file contains several echo commands inside while-loops.

    Until this is fixed, the workaround is to use M118 to output the messages instead of echo.



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


  • administrators

    @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


  • administrators

    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


  • administrators

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



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


Log in to reply