RepRapFirmware road map as at 15 February 2020
-
@garyd9 said in RepRapFirmware road map as at 15 February 2020:
There was talk in the past of adding support in RRF3 to redirect certain file system related gcodes to DSF so that PanelDue could be fully utilized with a Duet3 attached to DSF.
Is this still on the road map?
Yes I hope to implement that, but it needs support in DSF, which may not be implemented in time for 3.02.
-
@dc42 said in RepRapFirmware road map as at 15 February 2020:
- Triggers (M581) and wait-for-input (M587) supported on expansion and tool boards
M587 is Add WiFi network. Do you mean M577? I would very much like a 'Wait for external trigger' function
BLV MGN Cube w/Hemera, K8200, Sunlu S8
-
dc42,
I have an interest in beginning an effort to continue development on RRF 2 until end of life. RRF 2 in its current state is just splendid for me, and I see potential value in maintaining it as a sort of "long-term-support" firmware that users can rely on to always be available to troubleshoot or implement in mission critical machines.
Do you have any thoughts about RRF 2.0 you could document before leaving it to the community? I think you did some seriously magnificent things with RRF 2, and you seem off to the races with RRF 3. A short-medium length debrief of your thoughts about how you left it and what you may have wished to implement had development continued would be super-welcomed.
Thanks! You are literally one of the most important people in the RepRap community. I will continue directly supporting your products as long as you continue to produce them.
-
@littlehobbyshop said in RepRapFirmware road map as at 15 February 2020:
@dc42 said in RepRapFirmware road map as at 15 February 2020:
- Triggers (M581) and wait-for-input (M587) supported on expansion and tool boards
M587 is Add WiFi network. Do you mean M577? I would very much like a 'Wait for external trigger' function
Thanks for pointing that out. I have corrected it.
-
@dc42 said in RepRapFirmware road map as at 15 February 2020:
Support switch-type Z probes on expansion and tool boards
Bit confused by this on the road map for RRF3.02. I already have the Metrol switch that I use as a Z (nozzle) probe configured as a simple switch (using M574) and connected to an expansion board. Did you mean "non switch-type Z probes on expansion boards? Or did you mean add type 5 to M558 for expansion boards?
-
@deckingman said in RepRapFirmware road map as at 15 February 2020:
@dc42 said in RepRapFirmware road map as at 15 February 2020:
Support switch-type Z probes on expansion and tool boards
Bit confused by this on the road map for RRF3.02. I already have the Metrol switch that I use as a Z (nozzle) probe configured as a simple switch (using M574) and connected to an expansion board. Did you mean "non switch-type Z probes on expansion boards? Or did you mean add type 5 to M558 for expansion boards?
M574 configures it as an endstop switch, not a Z probe.
-
@dc42
I think it might be a good idea to concentrate on getting the dsf up to date on duet3 rpi first??I was referring to conditional gcode does not work on duet3 with SBC and anything regards console feedback e.g G32 does not either.
-
When will you have time to address the SD card connection issues with the PanelDue and Duet3 running from a RPi? Thanks
-
@gfisher said in RepRapFirmware road map as at 15 February 2020:
When will you have time to address the SD card connection issues with the PanelDue and Duet3 running from a RPi? Thanks
See my earlier reply https://forum.duet3d.com/post/135146.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
Any plans for M80/M81 support for meanwell PSUs?
I know I asked this before. Like many other. Is this anywhere on a plan? -
@copystring said in RepRapFirmware road map as at 15 February 2020:
Any plans for M80/M81 support for meanwell PSUs?
I know I asked this before. Like many other. Is this anywhere on a plan?Do you mean to invert the PS_ON signal, or something else?
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 Yes. This.
-
@dc42 said in RepRapFirmware road map as at 15 February 2020:
The high speed SPI bus is on the socket for the Ethernet module.
USB serial port not fast enough?
-
@arhi said in RepRapFirmware road map as at 15 February 2020:
@dc42 said in RepRapFirmware road map as at 15 February 2020:
The high speed SPI bus is on the socket for the Ethernet module.
USB serial port not fast enough?
The idea was to keep the USB serial port free and the the SPI bus runs at 5MHz (depending on how you have it configured) and uses less resources on the Duet. Didn't make sense to develop 2 different ways to communicate between the Duets and SBC.
-
@dc42 said in RepRapFirmware road map as at 15 February 2020:
@Danal said in RepRapFirmware road map as at 15 February 2020:
The Pi to Duet 3 interface is SPI. Duet 2 does bring SPI out to the expansion connector.
Pure speculation on my part... but I'd expect nothing will need to be removed, just hook up the SPI and run the correct firmware.
The plan in the short term is to use a Duet 2 Ethernet without the Ethernet module. The high speed SPI bus is on the socket for the Ethernet module.
Will Duet2 WiFi be useable with RPi?
-
@dc42 said in RepRapFirmware road map as at 15 February 2020:
@gfisher said in RepRapFirmware road map as at 15 February 2020:
When will you have time to address the SD card connection issues with the PanelDue and Duet3 running from a RPi? Thanks
See my earlier reply https://forum.duet3d.com/post/135146.
@dc42 Thank you. I’ve found this to make demoing our machines very challenging when taking them offsite.
-
@gtj0 said in RepRapFirmware road map as at 15 February 2020:
@arhi said in RepRapFirmware road map as at 15 February 2020:
@dc42 said in RepRapFirmware road map as at 15 February 2020:
The high speed SPI bus is on the socket for the Ethernet module.
USB serial port not fast enough?
The idea was to keep the USB serial port free
TBH I'd rather have my USB port taken out byt SBC (currently attached to that USB port) than lose the ETH port by SBC (that's currently using the USB port). As compared to the setup ATTM where SBC attached to USB and ETH attached to DUET (and SBC) I will lose any outside connection to Duet2 and have USB port free.
and the the SPI bus runs at 5MHz (depending on how you have it configured) and uses less resources on the Duet.
Unfortunately, most MCU's have USB "hardware" that uses a lot of resources from MCU but I don't see how will it use more than what it is using right now. It is already implementing CDC that's one of the most resource-hungry ones.
I have zero experience with SAM's (tried, found ERRATA too late, gave up) but I doubt it's much different from STM32 so there should be 12MHz USB support out there. With all the overhead USB creates it should match the 5MHz SPI or come at least close to it. A secondary benefit would be that code on the SBC would be tad more portable as accessing /dev/tty* is much more portable than accessing (and enabling) SPI port on the expansion port of a SBC (as for e.g. one wanna use opi and not rpi or maybe fully open source ROCK pi ).
Didn't make sense to develop 2 different ways to communicate between the Duets and SBC.
That makes sense, but duet3 have USB too IIRC. Anyhow, decisions are already made, so I'll shut up now
-
The Duet2 does actually have 2 additional SPI ports on the temp daughterboard and 50pin connectors but based on @dc42's comment above, maybe he thinks they won't be fast enough.
-
We chose dedicated SPI for the Duet 3 so that we can be sure it will be fast enough and won't suffer from contention on either the Duet shared SPI bus or the RPi USB interface (which may be handling webcam, keyboard, mouse/touch screen, ascanner and goodness knows what else). We're not planning to rewrite that for Duet 2. If you connect a RPi to a Duet, you don't need the Duet to provide a webserver, because that's already in the RPi.
Currently we don't need high speed on the SPI bus, but that may change soon when DSF tracks the RRF object model and plugins need up-to-date values. The RPi to Duet SPI bus works reliably up to 20MHz, higher in some cases.
Another reason the shared SPI bus isn't suitable is because the RPi is the bus master when talking to the Duet.
-
Once Raspberry/DSF is supported on Duet2 I suppose we can also take off the Wifi module of the Duet2Wifi and hook up the SPI bus to J16?
I think I would like that.
Wouldn't it make sense business-wise to spend more development effort towards Duet3/DSF and less towards Duet2? If Duet2 gets all the shiny new features too I never have a good reason to upgrade, which is not good for the amount of food on your table
