RepRapFirmware 2.0 with RTOS in development

DaveA · 3 Apr 2018, 18:07

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.

S1lencer · 4 Apr 2018, 15:52

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.

dc42 · 4 Apr 2018, 18:00

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.

S1lencer · 4 Apr 2018, 18:46

Jep did mean M303

DaveA · 4 Apr 2018, 21:53

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.

dc42 · 4 Apr 2018, 22:03

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.

Captain_sq · 5 Apr 2018, 20:46

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.

dc42 · 5 Apr 2018, 21:44

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.

cgcafer · 6 Apr 2018, 12:11

Hi David,
This is the first run for me with RTOS, here you can find M122 result

M122
=== 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

dc42 · 6 Apr 2018, 17:23

Thanks, those figures look good, but let me know if you get any unexplained behaviour.

AS-3D Druck · 6 Apr 2018, 17:52

Quick Question on this point.
What exactly will change if you're done with Version 2.0?

Is it just more compact or can it operate faster?
Is it a performance jump like from Windows Vista to Windows 7?
Sry but i don't get it.

dc42 · 6 Apr 2018, 18:09

The use of RTOS will make it much easier for us to implement some types of new feature. I hope it will also allow us to improve file upload speed a little.

Captain_sq · 6 Apr 2018, 18:33

@AS-3D:

Quick Question on this point.
What exactly will change if you're done with Version 2.0?

Is it just more compact or can it operate faster?
Is it a performance jump like from Windows Vista to Windows 7?
Sry but i don't get it.

In short: More efficient use of the microcontrollers and development resources.

Which means that you can do more things with the resources you have at your disposal without sacrificing performance. In plain english that means that you can add more features, speed up certain parts and shorten development times.

For the developer a lot of things becomes easier as the abstraction level is significantly raised. Code becomes more robust as you don't have to twiddle around with low-level error prone code that often incurs limitations that makes the entire code base hard to maintain. Hunting for bugs becomes somewhat easier too.

mhackney · 7 Apr 2018, 01:31

Firmware Version: 2.0(RTOS)alpha1 (2018-04-05b2) installed on one of my Ultibots D300VS deltas. 1 print completed. Amazing progress David.

whosrdaddy · 4 Aug 2018, 11:55

Completed 2 5 hour prints on 2.0 alpha without any issues, amazing stuff David!.

2 (minor) problems I found so far:

sometimes the ESP8266 would not boot a power up (blue led won't light up) ( a power cycle solves this).
DWC Disconnects at the end of an upload.

for reference:

Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later
Firmware Version: 2.0(RTOS)alpha1 (2018-04-05b2)
WiFi Server Version: 1.21
Web Interface Version: 1.21.1-b1

Here is the last completed print on 2.0 alpha

mhackney · 8 Apr 2018, 12:41

I've uploaded multiple files from DWC with no disconnects. I'll keep my eye open for this and if it happens, report back.

timcurtis67 · 8 Apr 2018, 16:19

After updating to 2.0(RTOS)alpha1 (2018-04-03b2) I ran a few small test calibration cubes. Everything was working fine. On the third run I walked out of the room for a few minutes and came back to the printer frozen (not moving).

I reset the printer and ran an M122.

Here are the results

12:01:24 PMM122
=== Diagnostics ===
=== RTOS ===
Static ram used: 26196
Dynamic ram used: 95340
Recycled dynamic ram: 1344
Handler stack ram used: 324
Never used ram: 7868
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.0 or 1.01 + DueX5
Board ID: 08DAM-999TL-MQ4S4-6JKDA-3S06M-95HMY
Last reset 00:00:26 ago, cause: software
Last software reset at 2018-04-08 12:00, reason: User, spinning module GCodes, available RAM 7860 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f000, BFAR 0xe000ed38, SP 0xffffffff
Used output buffers: 8 of 32 (18 max)
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 30.4, current 30.7, max 31.1
Supply voltage: min 23.9, current 24.0, max 24.2, 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
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Expansion motor(s) stall indication: no
Date/time: 2018-04-08 12:01:23
Slowest main loop (seconds): 0.008095; fastest: 0.000070
=== 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
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 2 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 60:01:94:0c:4f:6d
WiFi Vcc 3.39, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 17192
WiFi IP address 10.0.0.137
WiFi signal strength -43dBm, reconnections 0, sleep mode modem
Socket states: 2 0 0 0 0 0 0 0
=== Expansion ===
DueX I2C errors 0

Not sure what happened? Maybe something in here will help you?

Running DuetWifi IDEX (2 X carraiges) With these specs

Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.0 or 1.01 + DueX5
Firmware Version: 2.0(RTOS)alpha1 (2018-04-03b2)
WiFi Server Version: 1.21
Web Interface Version: 1.21-RC4

timcurtis67 · 9 Apr 2018, 16:40

I ran a few longer running prints without anymore freeze ups. Some web disconnects but zero issues with printing. The disconnects are new for me but not really an issue.

The firmware is working great so far.

Will there be a revised web interface to try out uploading files while printing? I tried it but the button is locked out in the current version I am running.

dc42 · 9 Apr 2018, 21:34

@timcurtis67 said in RepRapFirmware 2.0 with RTOS in development:

Will there be a revised web interface to try out uploading files while printing? I tried it but the button is locked out in the current version I am running.

I've asked chrishamm to look at doing this.

dc42 · 10 Apr 2018, 18:11

RRF 2.0beta 1 has now been released. Please post further comments and feedback in the thread I have created about that release, https://forum.duet3d.com/topic/4871/reprapfirmware-2-0beta1-available.