RepRapFirmware road map as at 15 February 2020

dc42

@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.

chas2706

@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.

oozeBot

When will you have time to address the SD card connection issues with the PanelDue and Duet3 running from a RPi? Thanks

dc42

@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.

copystring

Any plans for M80/M81 support for meanwell PSUs?
I know I asked this before. Like many other. Is this anywhere on a plan?

dc42

@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?

copystring

@dc42 Yes. This.

arhi

@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?

gtj0

@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.

tekkydave

@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?

oozeBot

@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.

arhi

@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

gtj0

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.

dc42

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.

DaBit

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

A Former User

@DaBit said in RepRapFirmware road map as at 15 February 2020:

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?

the ethernet and wifi boards are otherwise identical so if the intial plan is to use a ethernet board, then yes.

dc42

@DaBit said in RepRapFirmware road map as at 15 February 2020:

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

True; but we value our users!

[rant] Also I get disgusted with kit that ceases to be fully functional because the manufacturer can't be bothered to update the firmware. Right now am really annoyed by my Humax PVR which can still record TV programs, but the internet-connected functions have slowly stopped working. The only app worth having that it can still run is BBC iPlayer, and even that crashes one in three times that I start it. Even when I first connected it to my network, I had to change my WiFi password because the set of password characters that the firmware allowed was very restricted, and although this was a known problem Humax said they wouldn't fix it. I've had similar problems with my one and only iPhone and the Motorola Android phone that followed it. OTOH, Samsung has been good at providing updates to my last 2 phones.[/rant]

Also, Duet 3 is expensive and overkill for most 3D printing applications. So RRF3 will continue to support Duet 2 for as long as it fits in the available memory. We have plans to replace Duet 2 as the platform for users who don't need the expandability of Duet 3; but that won't happen for a while, and we'll still go on making the existing Duet 2 range while our OEMs need them.

Adding RPi support working through the network SPI connection of Duet 2 is in theory a fairly simple project, but it's not our priority right now.

DaBit

@dc42 said in RepRapFirmware road map as at 15 February 2020:

True; but we value our users!

And I am grateful for that!
I have become quite fond of the Duet controller in short time. Bought the Duet2Wifi out of curiosity. Toy with it, see what it is all about, sell it. Never even thought it would really be a decent contender to LinuxCNC with it's endless possibilities to make things work the way I want them to work. And the first experience was indeed like a naked plunge in subfreezing water. No conditional G-code, a weird way to use homeswitches not exactly at the end of travel, blah. But here we are, a few months later, and the water is nice and warm. Not considering moving back. Mainly because of you, your insane drive to move forward and efforts put in RRF3, and the insanely quick fixing of issues.

[rant] Also I get disgusted with kit that ceases to be fully functional because the manufacturer can't be bothered to update the firmware.

As a consumer I totally agree. Not only the software, also the actual technical life and irrepairability of 'modern stuff'. After a few years it becomes hard to get parts. Kept my old xperia X10 phone running for a bit over 6 years, cannot do that anymore it seems. Bought 10 year old motorcycles and ran them until they were 20 years old, then only sold them because I longed for something else. Not sure I can do that with my shiny new KTM; I highly doubt that the TFT screen they use for dashboard lasts that long, and build quality is more optimized towards cost and weight instead of durability.

As one of the designers at an electronics company I am not so convinced. IMHO the worst thing you can do for customers is going out of business or having to find other sources of money which lowers the amount of resources that can be put into the original product line. Given the fact that development time is a limited resource there is a point where the hours spent on maintaining compatibility is preventing staying ahead of the rest on the new hardware and just costing money. It often makes sense to create a 'light' version of the more current hardware or lower pricing on the full version a little. Which you can since you save money elsewhere. A bit on the increased volume, a bit on the development, a bit on the support. It adds up.
Also, the Duet is not a PC, phone or PVR where 3rd party software stops working due to the system being too old. If I stop updating today the Duet will happily keep printing for the next decade just like it does today. Many of your users are probably not updating the software anyway. If it ain't broken....

All this is personal opinion only, of course.

Also, Duet 3 is expensive and overkill for most 3D printing applications.

Yes, you have chosen nice and expensive motor drivers that almost no 3D printer needs. I bet a large part of the additional cost come from those
I did not check the BOM, but a Duet3 with 5x TMC2660 instead of the 5160's should not cost that much more than Duet2 to produce, and more alike platforms usually means faster development and less issues. However, I am aware that initial cost for a new board is high.

Anyway, I love what you are doing, and I am happy to get to use all the useful new stuff with a click on the 'upload system files' button.

DocTrucker

@copystring just ordered one of these power supplies myself. You need an external psu for the duet anyway so isn't all you need a resistor?

There is RC+ and RC-. The PSU wants near zero volts for on, and 4-10V for off, and only draws something like 20mA. So feed 5V to the ps_on pin via a current limiting resistor and also connect ps_on to the rc+. Then connect rc- to the 0V of the power supply?

You'll need to appropriately size your resistors and be aware that a 5V psu failure will cause the enabling of the VIN power supply, so not a great safety feature.

Edit: Pic

stefma

@dc42 Thanks for the overview! Do you have any plans to implement an EtherCAT master in near future?