On 13/10/2015 10:13 AM, William Cook wrote:
> Would you consider RepRapFirmware for RADDS to be stable at this point?
Stable for testing, yes. I've been printing with it for about 6 days now and no
surprises. But not enough people have used it yet on RADDS to consider it stable.
That said, this is a port to new hardware of a very stable firmware. As such,
the underlying firmware itself is quite stable. In question is just how many
dumb things I did.... For example, the SD card support uses the higher level
FAT32 support in the RepRapFirmware (based on the Atmel ASF libraries). I pulled
in the Atmel ASF hardware SPI library (spi_master), the Atmel ASF MMC SD library
(mmc_sd_spi or some name like that), and then put it my own DMA support. Seems
to work.... But that's an area which needs more usage to establish confidence.
> What is the targeted hardware setup (RADDS + RADDS LCD? RADDS + PanelDue?
> RADDS + UDOO Quad + OctoPrint?)
First a comment on the UDOO: it is NOT 100% Arduino Due compatible despite
UDOO's claims. Namely, they didn't provide the MISO/MOSI/... connector for
shields. That means, if you choose to use an UDOO, you will need to wire
from their off-to-the-side hardware SPI connector over to the RADDS connector
which expects to mate with the matching connector on a real Due board.
You can use a wire-wrap tool to do that or tag solder or whatever. But, to
get the SD card working you have to do something. And the RepRapFirmware
likes to have an SD card (but can operate without one).
There is no native LCD support at present. I plan to add it in the very
near future but have a lot of demands on my time right now so no promises.
And, I happen to like Octoprint a lot and use it with mine. And there
is some effort to make Octoprint work more cleanly with the RepRapFirmware
1. Recently David Crocker made the common branch of the RepRapFirmware
default to behaving like Marlin as regards responses to serial commands.
(It is configurable over gcode; having it default to Marlin behavior is
one less thing to configure for use with Octoprint).
2. In the development branch of Octoprint, Foosel gave Mark Walker the go ahead
to make the Control Panel's "fan on" button default to sending "M106 S255"
instead of just "M106". While many firmwares allow the S255 to be omitted,
not all do. For example, Teacup and RepRapFirmware require "S255" to enable
the fan.
3. Mark Walker is working on having Octoprint not assume that a "M0" command
behaves the same for all firmwares. It doesn't. The RRF crowd uses M0 to
end their prints and for RRF it, among other things, turns heaters off.
For Marlin, for example, it's a pause with the heaters left on. Octoprint
presently intercepts the M0 and pauses. Not good for RRF. Work on solutions
are in progress. If you use Octoprint with RRF at present, just don't use
"M0" as your end gcode. Instead explicitly turn things off with individual
commands.
To answer your question though, at present the target is to support on RADDS
optional native LCD UI
optional Panel Due
optional Octoprint and similar
The second and third are supported today. Missing is native LCD UI support.
Dan