RepRapFirmware 2.0 with RTOS in development
-
Just ran a test print on my Anycubic delta. Printed fine. I did have a problem when I realized I had selected the wrong file to print and attempted to pause/cancel. The pause seemed to hang everything. The bed was still heating but I couldn't kill the print. I needed to power cycle the printer and re-connect to start again. Other than that everything seems good.
This is with a Duet Ethernet. -
@DaveA, thanks for that. I'll add pause/resume to the list of things to be tested before the next release.
-
Downloaded and installed the 2.0(RTOS)alpha1 (2018-04-02b3). Uploaded and installed via the DWC dialogs. Everything worked, and it came back online quite quickly.
This is a Duet WiFi (reads as Duet WiFi 1.02 or later) with nothing attached except power. Home switch configurations are set so that a G28 succeeds (NC, I think). Everything that I can test with nothing attached looks good.
I'll put this duet in a printer over the next few days so I can test more.
-
Vin seems to read a fraction high, as compared to an Eventek benchtop power supply, and a Mastech DVM. They agree to within 0.02.
At 12.0 V on the power supply, 12.02 on the DVM, DWC shows 12.2.
At 24.0 V on the power supply, 24.02 on the DVM, DWC shows 24.4.This may be entirely within normal tolerance, I did not check it on the "old" firmware.
-
The tolerance is +/-4.5% but it should typically be within +/-2%.
-
I've just pushed a new version to github. This one runs the network processes as a separate task, and doing that has restored the file upload speed to about what is was before. Further improvement should be possible in future.
Pause seems to be working. I suspect it was a stack overflow, as I has to increase one of the stack sizes to fix another issue.
If you try this version, please keep an eye on the stack sizes using M122 (but see below), and let me know if any of the "stack rem" figures fall below 100.
Known bug in this version: if you send M122 from DWC, it sometimes disconnects because of a JSON error, and you can't reconnect DWC without rebooting the Duet. M122 from USB is OK. I'll fix this in the next release.
-
2.0(RTOS)alpha1 (2018-04-03b2) loaded successfully through DWC.
Successfully simulated a print, and uploaded a file at the same time. About 454 K/Sec.
-
After the sim and upload in parallel.
[[language]] 8:51:45 AMM122 === Diagnostics === === RTOS === Static ram used: 26196 Dynamic ram used: 95116 Recycled dynamic ram: 1568 Handler stack ram used: 280 Never used ram: 7912 Task NETWORK: state 0 stack rem 676 Task HEAT: state 2 stack rem 172 Task MAIN: state 1 stack rem 428 === Platform === RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)alpha1 running on Duet WiFi 1.02 or later Board ID: 08DGM-9568A-F23SD-6JTDJ-3SD6S-TTNMF Last reset 00:10:41 ago, cause: software Last software reset at 2018-04-02 21:44, reason: Hard fault, spinning module GCodes, available RAM 3488 bytes (slot 0) Software reset code 0x4033 HFSR 0x40000000, CFSR 0x00008200, ICSR 0x0441f803, BFAR 0x41010000, SP 0x20001fb4 Stack: 0040a643 00432e5c 01070000 ffffffff 20002524 ffffffff 0040ac2d 004384e4 a1070000 200091f0 00443477 20002008 ffffffff 00000000 00000000 200091f0 00000000 ffffffff a0000001 2000219c 0044352b 20002020 20002064 20007cb0 Used output buffers: 10 of 32 (23 max) Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 168.9ms MCU temperature: min 37.2, current 38.1, max 39.1 Supply voltage: min 12.1, current 12.2, max 12.3, under voltage events: 0, over voltage events: 0 Driver 0: standstill, SG min/max not available Driver 1: standstill, SG min/max not available Driver 2: standstill, SG min/max not available Driver 3: standstill, SG min/max not available Driver 4: standstill, SG min/max not available Date/time: 2018-04-03 08:51:45 Slowest main loop (seconds): 0.219054; fastest: 0.000065 === Move === MaxReps: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0 Scheduled moves: 0, completed moves: 0 Bed compensation in use: none Bed probe heights: 0.000 0.000 0.000 0.000 0.000 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 === GCodes === Segments left: 0 Stack records: 1 allocated, 0 in use Movement lock held by null http is idle in state(s) 0 telnet is idle in state(s) 0 file is idle in state(s) 0 serial is idle in state(s) 0 aux is idle in state(s) 0 daemon is idle in state(s) 0 queue is idle in state(s) 0 autopause is idle in state(s) 0 Code queue is empty. === Network === Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0) HTTP sessions: 1 of 8 - WiFi - Network state is running WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.21 WiFi MAC address 2c:3a:e8:0a:ec:ba WiFi Vcc 3.38, reset reason Turned on by main processor WiFi flash size 4194304, free heap 15952 WiFi IP address 192.168.86.110 WiFi signal strength -45dBm, reconnections 0, sleep mode modem Socket states: 2 0 0 0 0 0 0 0 === Expansion === -
Danal, thanks.
Which time zone are you in? The software reset data says:
Last reset 00:10:41 ago, cause: software
Last software reset at 2018-04-02 21:44, reason: Hard fault, spinning module GCodes, available RAM 3488 bytes (slot 0)but I don't think they can refer to the same reset unless your computer clock is more than 16 hours behind mine.
EDIT: now that I think about it, the automatic reset after uploading new firmware won't update the software reset data, so that explains it.
-
I have another duet wifi and i updated RTOS firmware via DWC. After that duet wifi continuously reset
NOTE : Duet wifi board connected usb port and no any other connection (any motor, any sensor etc only duet wifi board v1.02)
-
Things are not going so well after the latest build.
I've been getting a number of disconnects due to syntax errors in the JSON. I wasn't getting these in the previous build.
I've not been able to print Benchy with the new build. It will start printing and then some random time later it will just stop with a 100% complete message. I've not been able to print beyond 40-50 layers before stopping.
I reinstalled the 1.21 build and Benchy is now almost complete without error. I didn't keep the previous RTOS build so I can't try it.I did try to cancel a print and it seemed to work but it had to complete the bed warming before it would it cancel. Maybe this is expected behavior.
-
Hi, i think i found a kink in the new RTOS Firmware, if you try to run an autocalibration "M302 H1 S240" DWC said the usual stuff but not long after that the Board reboots.
-
I've just pushed a new version to github. I've fixed some issues with the C library not being reentrant, which were causing occasional crashes.
@S1lencer, thanks for your report. Did you mean M303? I haven't tried heater tuning with v2 yet, and as the heater control is now a separate process it may be that the stack for that process is too small to handle heater tuning. I'll add this to the bug list.
@DaveA, I've seen that DWC will disconnect after a while with a JSON parse error too. Do you have a PanelDue? I suspect that this may not happen without one. Putting the PanelDue on the Setup page (so that it stops polling) may avoid it.
I've fixed a couple of issues unrelated to RTOS:
- If multiple devices are connected to a Duet via the network and DWC, and one of them goes to sleep without disconnecting first, this will be recognised after 8 seconds so the other device will no longer receive repeated messages.
- M114 reports user coordinates first and machine coordinates at the end.
-
Jep did mean M303
-
I do have a PanelDue. I disconnected it and had no further disconnects. Didn't try putting it in Setup.
Tried three prints today. All Benchys.
First print completed successfully.
Second print never starting printing before claiming 100% done and returning to idle. Don't know if heating completed.
Third print completed successfully.
I didn't reset between these prints. Just picked the print again button. -
Thanks. I put my Panel Due on the Setup page and had no further disconnects. I thought I had protected all the critical places in the output buffer management system with a mutex, but it looks like I must have missed one.
-
Exiting!
I'll be following this closely. We had an earlier discussion about G code look-ahead to enable rising/lowering of extruder temperature according to the current extrusion speed. I hope this is on the list somewhere.
Another thing I have been pondering is a "predictive" and self-adjusting start time for the heating up of the hotend in relation to the timeline of the heating of the bed in order to save some time when starting a print. With the PID parameters resulting from the auto-tune of the heated bed, one should be able to estimate the time when the bed reaches the target temperature. The same goes for the hotend. With these estimated predictions, one should be able to start the heating of the hotend at a certain time during the heating of the bed so that both the bed and hotend reaches the target temperature at the same time.
Small adjustment to this factors can be made by measuring the actual time each print. Over time, the prediction factors will "home in" on the correct value as the printer is being used. -
I've just released another 2.0 alpha. The two bugs in the previous release (crash if you tune a heater, and DWC disconnecting after a while if a PanelDue is also connected) are believed fixed. Nevertheless, I caution against using this release for doing long-running prints. The DWC disconnects were caused by printf in the GNU C library not being re-entrant if you use floating point formats. There may be other issues in the library with lack of reentrancy that I haven't mitigated yet.
-
Hi David,
This is the first run for me with RTOS, here you can find M122 resultM122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)alpha1 running on Duet WiFi 1.02 or later
Board ID: 08DAM-9K9K2-NGNSN-6J9D6-3S46J-TPSMJ
Used output buffers: 2 of 40 (31 max)
=== RTOS ===
Static ram: 28484
Dynamic ram: 97188 of which 0 recycled
Exception stack ram used: 384
Never used ram: 5016
Task NETWORK ready, free stack 316
Task HEAT blocked, free stack 572
Task MAIN running, free stack 3808 -
Thanks, those figures look good, but let me know if you get any unexplained behaviour.
