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.
-
@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
-
@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?
-
@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? -
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.
-
@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
-
Yes I saw that; but Luke has a similar problem with a tool board.
-
-
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.
-
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
-
@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 -
@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?
