RepRapFirmware 2.0 with RTOS in development
-
The basic port to use RTOS is now working. Currently RepRapFirmware is running with just two tasks (one for heating control and one for everything else). The next step is to separate out the networking subsystem into a separate task, followed by GCode processing and movement. I've not yet decided whether to use a task for generating the step pulses or to leave that as an ISR.
The RTOS I chose is FreeRTOS. It is small and lightweight, ideally suited to embedded applications on ARM Cortex processors. It's coded to high standards - it claims compliance with the MISRA-C coding standard, which is the one used widely for critical C software in automotive, aerospace and other sectors.
Does this mean we might see the ability to upload a file at the same time as printing?
Yes, I hope to support that. In the longer term more complicated stuff, like simulating newly uploaded files in the background so that an accurate print time is known.
Any chance on being able to store/recall variables and use if/then, addition/subtraction logic statements in macros?
-
That's planned, but not directly related to RTOS.
-
Further progress yesterday and today. RepRapFirmware 2.0 alpha now has a thread-safe file system! This paves the way for splitting the code into more tasks. The next work item will be to make PrintMonitor and the interfaces between Network and the rest of the system thread-safe, after that the network subsystem can run as a separate task. That will allow more network stuff to happen in parallel with SD card access, which should speed things up a little.
-
Does this mean that eventually we won't have the problem where the system pauses while the hot end is heating when using the PanelDue? The system becomes unresponsive to any commands until the heating is is complete. Any commands issued (ie: homing) during that period would only happen after the hot end heater reaches the temp.
-
Does this mean that eventually we won't have the problem where the system pauses while the hot end is heating when using the PanelDue? The system becomes unresponsive to any commands until the heating is is complete. Any commands issued (ie: homing) during that period would only happen after the hot end heater reaches the temp.
The 'system' doesn't pause when the hot end is heating. The command channel that you sent the heating command from won't accept further commands if the heating command is defined to wait until temperature is reached of course, so if you send such a command from PanelDue then of course it will become unresponsive.
-
Thanks for the clarification.
-
I should add that:
1. Setting temperatures in PanelDue on the Control and Print pages does not use commands that wait for temperature.
2. Even if you do invoke a "set temperature and wait" command from PanelDue (e.g. in one of your own macro files, or by selecting a new tool when there is a set-and-wait command in one of the tool change macro files), the status will continue to update while waiting unless you are using very old main firmware.
-
More progress yesterday and today. It turned out that there are a lot of chunks of code that are not thread-safe, especially in the older code - which is understandable, because it was written before using a RTOS was envisaged. Anyway, I've now made all the output channels thread safe, also the tool list and the mechanism used to extract print data from GCode files.
I've started including a binary of the latest RTOS build for the Duet WiFi and Ethernet in the github commits. It's at https://github.com/dc42/RepRapFirmware/blob/v2-dev/EdgeRelease/Duet2CombinedFirmware.bin. If you like taking risks, follow that link and click Download. I've included a couple of bug fixes in this one too:
- Fixed issue with G1 S1 Ennn on delta printers
- The FileInfo parser now has a timeout if called from DWC, to prevent the connection being lost when getting info from a large file with a small SD card cluster size. You will no longer get disconnected, but you probably won't get object height or filament required information.
It's compatible with version 1.21 of iap4e.bin, DuetWiFiServer.bin and DuetWebControl.zip.
-
Hi David,
This morning i updated, after that i can't connect via wifi and fan2 (now it is connected to laser head) it was flashed one in 3-5 second.I was busy so after that i reinstall to regular version (1.12). If you want to diagnostic i can try it again.
Thanks
Cafer -
I presume you mean 1.21 not 1.12.
What was the problem with Fan2?
The RTOS build is working on my delta, except that the first time I booted it up this morning the wifi was off and I had to send M552 S1 from PanelDue to enable it. I have a new build almost ready, but I'll do some tests powering up from cold to see if that problem occurs again.
-
Yes you are right 1.21
laser led turned on and off(like flashing) in 3-5 seconds
I was tried M552 S1 but no success. -
Just updated my D-Bot and all good so far. No issues after update with warm and cold restarts and a successful small print.
Edit: Running a Duet Wifi -
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 ===
