RepRapFirmware 2.0 with RTOS in development
-
Sign me up for Alpha. I have a Duet that is not in a printer at the moment, and I've been "Playing with things" on that one…
-
Sign me up for Alpha. I have a Duet that is not in a printer at the moment, and I've been "Playing with things" on that one…
+1
-
When will the Duet Maestro be announced for purchase?
-
Sign me up for Alpha. I have a Duet that is not in a printer at the moment, and I've been "Playing with things" on that one…
+1
-
What upgrades will this new hardware have over the existing Duet 2 series?
Will it be compatible with the existing accessories: panelDue, smart effector, duex5 / duex?
-
I will try the Alpha on my DuetWifi IDEX printer. Sign me up.
-
When will the Duet Maestro be announced for purchase?
When we can provide a shipping date for it. Currently there are only 3 prototypes in existence. Just to be clear, it is a lower-specification board than the Duet Ethernet.
-
When will the Duet Maestro be announced for purchase?
When we can provide a shipping date for it. Currently there are only 3 prototypes in existence. Just to be clear, it is a lower-specification board than the Duet Ethernet.
David
Can you share the basic specs of it it may interest some people out there as I assume the price will be reduced as well and may attract more people into the Duet Family so to speak.
Doug
-
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.
-
When will the Duet Maestro be announced for purchase?
When we can provide a shipping date for it. Currently there are only 3 prototypes in existence. Just to be clear, it is a lower-specification board than the Duet Ethernet.
David
Can you share the basic specs of it it may interest some people out there as I assume the price will be reduced as well and may attract more people into the Duet Family so to speak.
Doug
We did the work with an OEM who is going to be releasing the information soon. They own the timeline for this!
-
I was aware that the work was for an OEM shame they haven't announced anything yet wonder if they will try and keep it to themselves or let you guy's have it in your shop as well.
Good to hear that you have the initial port David very excited to actually give it a go
I have a Ethernet with Duex5 sitting here just ready for some testing to happen until I can get the CoreXY to a state ready to take the controller (That will have a Smart effector re-purposed for it) Carriage for that is already doneKeep up the excellent work.
Doug
-
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?
-
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.
-
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.
