RADDS work now stable with RepRap Firmware

@GroupB : Uploading to the RADDS SD over Octoprint has always been super slow for me too: My RPi is connected over cat5 (wifi caused waaaaay to many problems), and it took me 30 seconds to upload a 60kb file. If I upload that same file directly the to RPi (also to SD), it's basically instant.

Alright so its not my wireless then, took 20 minute for 2.5mb. Maybe that the streaming thing , I just dont understand why octoprint have to rewrite the whole file and not just dump it there. Look at your terminal when you upload , it said write file , then you see all code line by line writing to the sd.

Quote
GroupB
Alright so its not my wireless then, took 20 minute for 2.5mb. Maybe that the streaming thing , I just dont understand why octoprint have to rewrite the whole file and not just dump it there. Look at your terminal when you upload , it said write file , then you see all code line by line writing to the sd.

Well, USB is a serial interface so just "dumping" the file to the SD card on the RADDS board is going to be slow. Particularly since the gcode commands for this stuff are line-oriented: send a line of gcode, get the response, send the next line, get the response. It's slow. Mind you, the actual SD writing by RRF on RADDS is as fast as it can get: SPI run as fast as can be negotiated with the ASIC in the SD card and DMA used for the data transfers. So, it's faster than, say, Repetier which doesn't use DMA. However, those speed gains are lost in the noise: they are swamped out by the slowness of the protocol required by the M28 command as realized over serial USB. (Note that on Duet hardware, the SD card doesn't use SPI and instead uses the ARMs high speed HSMCI/MMC interface. Arduino Due doesn't expose that hardware interface and thus RADDS cannot use it and has to go with the far slower SPI interface.)

Yeah im aware of the due having that faster interface but the pin is hidden under the cpu, It just too bad they did not expose it. Lets hope they release a updated version with that interface expose or even a clone version with a expose interface will be great , I will buy it right away to be able to download faster.
I guess I will have to wire a external SD card put it in the side of the machine and do it manually.

Just a question Why do we have to wait for the OK for every line ? are we not using a usb with control flow ? If octoprint and RRF can remove that OK confirmation every line will the USB print directly from octoprint become more reliable?

Quote
GroupB
Just a question Why do we have to wait for the OK for every line ? are we not using a usb with control flow ? If octoprint and RRF can remove that OK confirmation every line will the USB print directly from octoprint become more reliable?

Yes, it should do. Some host programs including Repetier and Simplify3D can be configured not to wait for OK, and I published a patch to Pronterface a couple of years ago to not wait for OK. I'm surprised that Octoprint doesn't have that option.

Edited 1 time(s). Last edit at 06/02/2016 01:37PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
GroupB
Yeah im aware of the due having that faster interface but the pin is hidden under the cpu, It just too bad they did not expose it. Lets hope they release a updated version with that interface expose or even a clone version with a expose interface will be great , I will buy it right away to be able to download faster.
I guess I will have to wire a external SD card put it in the side of the machine and do it manually.

First, I've never been able to usefully upload print files to the RADDS' SD card from Octoprint because Octoprint changes the file name from

blah.g

to

/blah.gco

By putting that leading slash onto the filename -- changing it from a relative path to an absolute path -- it causes RRF to put it exactly where the absolute path specifies, the root directory on the SD card. That then causes RRF to not see it as a file to print from SD card since it expects to find those files in /gcodes/. (I suppose we could make the M28 command strip any leading / from the file name?) With Octoprint I've always had to print over USB from the Octoprint machine. Either that or put the print file onto the RADDS' SD card via an alternate method and then letting Octoprint see it with M20 and tell the RRF to print the file from the RADDS' SD card.

On to another point.

Quote

Just a question Why do we have to wait for the OK for every line ? are we not using a usb with control flow ?

As to USB having flow control, look to the majority of 3DP electronics. The underlying processors more often than not lack USB support (e.g., ATmega 1280/2560 and 328P). These 3DP electronics have a USB to serial converter elsewhere on the motherboard and the microprocessor is then presented with just TX and RX lines with absolutely no flow control whatsoever. The microprocessor then has to handle incoming bits at interrupt level, competing with the stepper interrupt(s) trying to effect fast, smooth motion. And that's a real bottleneck readily exhibited by trying to print small, fine detail fast over USB/serial on an AVR. The 3DP gcodes have to cater to this limitation. And the limitation is coupled with the fact that the majority of 3DP electronics also do not have much available RAM (again, ATmegas). As such, it's hard for them to have a large input buffer to handle a lot of unsync'd commands. These two issues are why the default behavior of programs like Octoprint is to send a single command and then wait for a response. They are catering to the lowest common denominator of 3DP electronics.

Quote
dnewman
First, I've never been able to usefully upload print files to the RADDS' SD card from Octoprint because Octoprint changes the file name from...

Whew: I was getting the same behavior, and was thinking "man, yet another bug I need to ask about...".
Ok, that's unfortunately the expected behavior.
But since it takes so long to upload anyway, I (like you mentioned) manually copy it over regardless.

I just tried Printrun/Pronterface for grins. It took a bit under 15 minutes for a 2.48 MB file. However, it left it's own little droppings: a naked M110 command at the end of the file... Some sort of bug in Pronterface I guess. And, of course, that 2.48MB file was actually less than 2.48MB once all the comments were stripped which Pronterface does as it transmits the file for uploading.

P.S. I just uploaded

RepRapFirmware-1.13beta1-dc42-radds.bin

to the Release/ directory of my dc42 fork, https://github.com/dcnewman/RepRapFirmware/tree/dev/Release. I've done a couple of simple prints with it on one of my Core-XY printers and it appears to be working fine.

Noob here with a stupid question: where do I connect my Z-probe microswitch to on the RADDS board?

Quote
spinor
Noob here with a stupid question: where do I connect my Z-probe microswitch to on the RADDS board?

Depends upon how it works. If it presents just like a Z endstop, then hook it to the Z endstop. An inductive Z-probe is connected as per

https://github.com/dcnewman/RepRapFirmware/blob/dev/doc/RADDS-v1.5.md#inductive-z-probe

and needs to be configured via gcode however is appropriate for RepRapFirmware. (I don't use such probes myself, so I don't know offhand but it likely involves M558 and perhaps G31 (http://reprap.org/wiki/G-code#M558:_Set_Z_probe_type). Note that I didn't add that support to the RADDS build until a month or two back. Was up a few pages in this thread and might be searchable with E0_AXIS as the string.

Thanks - it's just a simple endstop switch activated when the nozzle presses against the bed. So, just to clarify, am I right in assuming it connects to the Z-max endstop pin (while the tower endstop connects to Z-min)?

Edited 1 time(s). Last edit at 06/02/2016 05:17PM by spinor.

Quote
spinor
Thanks - it's just a simple endstop switch activated when the nozzle presses against the bed. So, just to clarify, am I right in assuming it connects to the Z-max endstop pin (while the tower endstop connects to Z-min)?

That won't work: with RepRapFirmware there is only a single endstop per axis. In gcode you tell it if the endstop is a minimum or maximum endstop. Consequently, there is only one Z endstop pin. I think you have a type "4" Z probe (M558) in which case you would hook to the E0_AXIS pin which is Arduino Due D39 and labelled as "RADDS PWM3" on the RADDS board. You'll set the logic level (active HIGH or LOW) with "M574 E1 Sn" command with "n" set to 0 for active LOW and 1 for active HIGH. (And yes, M574 should allow specification of "E" -- the underlying code allows it.)

For reference, the Z-probe pins for RRF on RADDS are

D32 -- RADDS Z min -- Z axis endstop (configured via gcode as min or max)
D39 -- RADDS PWM3 -- E0_AXIS
A5 -- RADDS ADC -- Analog Z-probe pin
D34 -- RADDS X max -- Digital pin to turn on/off an IR LED for a differential IR Z probe

Quote
dnewman

Quote
spinor
Thanks - it's just a simple endstop switch activated when the nozzle presses against the bed. So, just to clarify, am I right in assuming it connects to the Z-max endstop pin (while the tower endstop connects to Z-min)?

That won't work: with RepRapFirmware there is only a single endstop per axis. In gcode you tell it if the endstop is a minimum or maximum endstop. Consequently, there is only one Z endstop pin. I think you have a type "4" Z probe (M558) in which case you would hook to the E0_AXIS pin which is Arduino Due D39 and labelled as "RADDS PWM3" on the RADDS board. You'll set the logic level (active HIGH or LOW) with "M574 E1 Sn" command with "n" set to 0 for active LOW and 1 for active HIGH. (And yes, M574 should allow specification of "E" -- the underlying code allows it.)

For reference, the Z-probe pins for RRF on RADDS are

D32 -- RADDS Z min -- Z axis endstop (configured via gcode as min or max)
D39 -- RADDS PWM3 -- E0_AXIS
A5 -- RADDS ADC -- Analog Z-probe pin
D34 -- RADDS X max -- Digital pin to turn on/off an IR LED for a differential IR Z probe

Thanks - that's really helpful. Forgive me for being stupid - I just don't want to accidentally fry anything - the only PWM3 I can find is labelled "SERVO PWM3" in the wiring diagram in the RADDS user guide. It's in a 3x4 block of contacts in the lower-left corner of the board but there aren't any actual pins on my board (so I would need to solder it myself) - is that correct?

Quote
spinor
Thanks - that's really helpful. Forgive me for being stupid - I just don't want to accidentally fry anything - the only PWM3 I can find is labelled "SERVO PWM3" in the wiring diagram in the RADDS user guide.

That's the pin. You may want to search this thread for the prior discussion where we added to the RADDS build this support. (It was already present in the Duet build.) When you find that discussion, you can see who was requesting this change, PM them, and see if things worked for them. (I'm pretty sure that things did work; I recall them providing a nice follow up at which point I made the change permanent for the RADDS build.) The advantage of contacting them is that they may have some experience-based suggestions for you.

Quote
dnewman

Quote
spinor
Thanks - that's really helpful. Forgive me for being stupid - I just don't want to accidentally fry anything - the only PWM3 I can find is labelled "SERVO PWM3" in the wiring diagram in the RADDS user guide.

That's the pin. You may want to search this thread for the prior discussion where we added to the RADDS build this support. (It was already present in the Duet build.) When you find that discussion, you can see who was requesting this change, PM them, and see if things worked for them. (I'm pretty sure that things did work; I recall them providing a nice follow up at which point I made the change permanent for the RADDS build.) The advantage of contacting them is that they may have some experience-based suggestions for you.

Will do. Thanks again for all your help.

... I used the Servo PWM1-3 pins on RADDS with previously soldered sockets for controlling pulse-driven piezo-dispensers without problems -- and now changed to an adapter across the pololu-sockets, extracting the extruder-pulse pins to do the same for less hassle with renaming pins in the firmware

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Soooo, now that I'm trying in ernest, I'm unable to print of the RADDS SD via Octoprint, either via their front-end, or by M commands. I can print off the Octopi's SD via Octoprint, or off the RADDS SD via Simplify3D's USB serial connection by issuing M codes.

I've added gcode data to both the root of the SD, and to the /gcodes folder, each with different names. When I connect to the RADDS via Octoprint, it prints:

Send: M20
Recv: Begin file list
Recv: 3DBenchy_rrf_gc.gcode
Recv: End file list
Recv: ok

the _gc file is the one I put in the /gcode directory. Sounds good.

I go to 'open it' via the Octoprint front end 'open folder' icon:

Send: M23 /3dbenchy_rrf_gc.gcode
Recv: GCode file "/3dbenchy_rrf_gc.gcode" not found
Recv: File opened
See octoprint.log for details
Changing monitoring state from 'Operational' to 'Error: See octoprint.log for details'

And I completely loose connection to the board. Plus as you can tell, that path is wrong, it's /gcodes/3dbenchy_rrf_gc.gcode, not the root path listed above.

So I try to print via M codes:

M23 3DBenchy_rrf_gc.gcode
Recv: File opened
See octoprint.log for details
Changing monitoring state from 'Operational' to 'Error: See octoprint.log for details'

At which point I loose connection again.
Note, this fails too:

M23 /gcodes/3DBenchy_rrf_gc.gcode

I got to look at the logs, but it doesn't actually seem to be storing anything in them.

Doing this in Simplify3D works just fine though:

M23 3DBenchy_rrf_gc.gcode
M24

Thoughts\opinions?

thanks

Octoprint doesn't want to see "File opened" as the response from M23.

Instead try

M32 3DBenchy_rrf_gc.gcode

As to your issue with "/gcodes/3DBenchy_rrf_gc.gcode", it may again be OP not liking RRF's response for M23. But using that path may not anyway. Internally, if there's no leading "/" then RRF pre-pends "0:/gcodes/" to create the full file path. If you specify "/gcodes/blah" then RRF may not pre-pend the "0:" -- I'd have to check to the code to be positive. And if that "0:" isn't prepended, then I believe things won't work either. (Think of the "0:" as a drive letter. But in this case it's the SD card's partition number.)

I remember having to whack on Octoprint initially to get it to work correctly with RRF: (1) to not intercept M0 thinking it was a pause, (2) to include the Snnn parameter when switching the print cooling fan on, and (3) to handle SD cards in keeping with how RRF works, not how Marlin/Repetier works. As regards (3), I believe I changed it to use M32 and I ran a whacked RRF which would strip any leading /. The Octoprint folks implemented (2) and were going to work on (1) and (3) as part of a rewrite of the comms layer. I haven't followed their progress.

Edited 1 time(s). Last edit at 06/02/2016 11:14PM by dnewman.

Thanks Dan. I gave the M32 a shot, got the same error\disconnect as above.

I noticed though, it does say (like the other above errors):
Recv: File opened
So after I reconnect, I shoot it a M24: It tells me "no file is selected". Ok, I don't think anything of it.

As I'm typing this post, it starts printing. Chaos I tell you.

I tried this also:
M32 0:/gcodes/3dbenchy_rrf_gc.gcode
same error\disconnect.

I've posted this issue to their group here:
[plus.google.com]

So your guys telling me all those time when I spend HOURS to upload to sd with octoprint then LOAD it using the "load" button on the file I just upload, it was not printing from SD card but still printing USB ?

There a plugin for the M0 thing, I guess to remove the OK is harder than just write a quick plugin? Since octoprint lose they sponsor I doubt we will ever see a "remove OK" option unless someone who understand coding and have interest in it focus on that.

For the fan thing its true its not working with they fan on off button , I made 2 extra custom button with one of the "add button plugins" and there working on/off calling the right command ( never try to put a slider there for speed %, I guess it will work too)

Well, this is all Octoprint. If I use a PanelDue, these operations all work fine. A PanelDue is no different than Octoprint in this respect: it sits at one end of a serial line with the RADDS board at the other. It gets a file list with M20, deletes files with M30, and starts prints with M32. It all works just fine; it isn't accorded any special treatment. The difference is the expectations to the command responses: Octoprint, given its origins, tends to expect Marlin-like behavior and also is well versed in Repetier. It's not well versed in some of the other firmwares though.

Quote

There a plugin for the M0 thing, I guess to remove the OK is harder than just write a quick plugin?

The problem is that Octoprint assumes that M0 means "pause print". It would see an M0 and silently eat it, not sending it to the printer. It would suspend sending any further commands to the printer until a manual "unpause" was done. Problem with that is that M0 is generally accepted to mean "stop everything" and not "pause". As in a software E-Stop which stops, well, everything including heaters. So, having OP intercept that command, M0, and not send it on to the printer is something of a Bad Thing if you use one of the firmwares which implement it as a stop and you have your gcode leverage it as the "end of print, shut things down" command. Your print ends, you expect the heaters to turn off but what has OP done but intercept the command leaving your printer idling with the heaters on.... And even if you disagree with the semantics of M0, having OP eat it and not pass it on to the firmware means that OP is assuming it knows what all the firmware does when in receipt of a M0 command and thus can safely decide to not pass it thru. That's not a good assumption. The OP folks agreed and indicated it could be addressed via their ongoing work to redo the comms layer. (Not too sure when that work will appear given the funding situation.)

That's the issue I was referring to. I believe it crept into OP owing to how Marlin implements M0. While the Marlin sources comment that M0 is an "unconditional stop", it actually implements M0 as M1 (pause, sleep). Given the Marlin heritage of OP, I can see why OP behaves that way. Again, however, it's a problem for the other firmwares which actually implement M0 as an actual stop everything command.

Quote

For the fan thing its true its not working with they fan on off button , I made 2 extra custom button with one of the "add button plugins" and there working on/off calling the right command ( never try to put a slider there for speed %, I guess it will work too)

Update your OP -- they pulled Mark Walker's fix for that months ago and incorporated it into the stable release. We couldn't find any firmware which wouldn't accept Snnn. And there were several firmwares which required Snnn (Teacup, RRF, older smoothieware, and, IIRC, machinekit, not that anyone is likely to use OP with mk).

I dont see the M0 as so important, I use the plugins that probably intercept it. After a print my end gcode turn off heater, home and disable motor and cooling fan there no need to M0 there I guess ( maybe I dont understand the purpose of M0)

M112 still work as E stop, it just dont finish the move in the buffer and stop right away

Quote
GroupB
I dont see the M0 as so important, I use the plugins that probably intercept it. After a print my end gcode turn off heater, home and disable motor and cooling fan there no need to M0 there I guess ( maybe I dont understand the purpose of M0)

It's fine that you don't use it yourself. However, there's a group of users who do use it as their ending gcode. For example, the sample gcode files provided with the RepRapFirmware and the reprap.org / reprappro.com printers. That then leads to RRF users emulating what they see in those examples in their own starting and ending gcode thereby promoting its usage.

I'm just catching up on the M0 thing, as I was fine-tuning my macros. What's throwing me for a loop is cancel.g, and stop.g :
This doc says that stop.g is called during an M0, and if I shoot a M0 to the machine, it stops, but nothing else happens: Fans stay on, no homing \ retraction, etc (that is present in my stop.g).
And the same doc, while discussing cancel.g, doesn't seem to really explain exactly how it's called to. it just says "cancel.g is called if the print is cancelled". Ok... how do you 'cancel' a print if not M0 or M112?

I put two different behaviors into both stop.g and cancel.g, and neither execute during an M0, or after a pause\M24 then M0.

What blindingly fundamental thing am I missing this time?

On a side note, I'm testing a dev branch of Octoprint they claim allows for printing off of the SD in RRF, but unfortunately it still throws the same errors. Waiting to hear back from the dev's.

Edited 1 time(s). Last edit at 06/04/2016 06:01PM by AK_Eric.

Quote
AK_Eric
I'm just catching up on the M0 thing, as I was fine-tuning my macros. What's throwing me for a loop is cancel.g, and stop.g :
This doc says that stop.g is called during an M0, and if I shoot a M0 to the machine, it stops, but nothing else happens: Fans stay on, no homing \ retraction, etc (that is present in my stop.g).

The stop.g file must be in the sys/ directory, correct?

Quote

And the same doc, while discussing cancel.g, doesn't seem to really explain exactly how it's called...

If the print is paused and then an M0 or M1 is received, then the print is canceled using cancel.g.

Thanks Dan:
All my macros are in /sys, correct.
I'm just not seeing that behavior: After pause, M0 just stops everything in its tracks, doesn't execute anything in cancel.g

I'll try M1 later (not that it should be any diiferent?).

M0 it runs 0:/sys/stop.g

M1 it runs 0:/sys/sleep.g

https://github.com/dcnewman/RepRapFirmware/blob/dev/src/GCodes.cpp#L2804[/url
https://github.com/dcnewman/RepRapFirmware/blob/dev/src/GCodes.cpp#L1061

Quote
dnewman

Quote
spinor
Thanks - that's really helpful. Forgive me for being stupid - I just don't want to accidentally fry anything - the only PWM3 I can find is labelled "SERVO PWM3" in the wiring diagram in the RADDS user guide.

That's the pin. You may want to search this thread for the prior discussion where we added to the RADDS build this support. (It was already present in the Duet build.) When you find that discussion, you can see who was requesting this change, PM them, and see if things worked for them. (I'm pretty sure that things did work; I recall them providing a nice follow up at which point I made the change permanent for the RADDS build.) The advantage of contacting them is that they may have some experience-based suggestions for you.

Just to let you know that I got my mechanical z-probe working via PWM3 as you described. As a temporary measure I stuffed breadboard jumpers into the PWM3 and ground holes, and secured them with blu-tak and wishful thinking. Thanks again for all your help!

Incidentally, when I flashed the firmware via the programming port I experiencing the same problem others reported, ie bossac pausing for a second before returning "No device found on ttyACM0" even though it worked OK last time (I'm running Fedora 21 by the way). I had to separate the boards to press erase and flash via the native port.

FYI, thanks to work by Mark Walker, he got a dev build of Octoprint that now supports printing from the SD in RRF, via the web UI. I'm doing it right now...
If you want to pick that build up, the discussion / install steps are here on the Octoprint Google Group:
[plus.google.com]