RADDS work now stable with RepRap Firmware

If scons gives that error, it means that your current working directory does not have a SConstruct file in it. Which, in turn, means you've not parked yourself in the top-level directory of the repo you've downloaded to your computer. That's Step 7 of the INSTALL.md document. If you are in the directory, then you're missing parts of the repo if you don't have a file named "SConstruct".

Why not use a ready made .bin ready to flash ? is there something really important you need that the .bin dont have ? That the thing with RRF you dont need to compile it you flash the .bin and your done.

Thanks Dan: I swear I tried that, even went searching for that file (SConstruct) on my HD and couldn't come up with anything in that depot. I'll give it a shot again tonight.

GroupB: Yes, I'd like to do that too in fact. And I'm going to state my grand ignorance here, but I can't find anything that explains how to actually do that bit (get that bin on the due) that didn't involve scons, which I couldn't get working I've been reading stuff online for hours and I'm staring to feel like I'm colorblind to some part of this process.

Greatly appreciate the help: I have Repetier on my bot right now, and while that whole experience has been pleasant, these weird, very regular lines are showing up in my prints that weren't there when I was using a Rumba\Marlin. So I want to change to this firmware to rules out it being a firmware issue. Plus I just want to see how RRF compares to Marlin & Repetier on the same machine

Edited 4 time(s). Last edit at 05/26/2016 12:30PM by AK_Eric.

Quote
AK_Eric
Just got through 9 pages of this thread: Thought I'd give RRF a go on my Due\RADDS coreXY bot. I've used Sailfish, Marlin & Repetier in the past,... but I'm having a heck of a time getting this installed. I feel like I'm missing the secret handshake or something.
I've been following this page:
[github.com]

When I run scons though (I'm on a Mac), it constantly gives me this:
scons: *** No SConstruct file found.

I've been using Python for years, but never scons. I've been searching all over the web for what to do about this, but there is surprisingly little. Mainly it's just 'make a SConstruct file'... very not helpful.
This is probably a noob mistake, but can someone help me out here?
thanks!

With RRF you don't need to build the firmware yourself, because everything important can be configured in the config.g file on the SD card.- So just download a binary from the Release folder in dcnewman's repository and upload that to your Due.

---

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

Specifically, you can use .bin files from

https://github.com/dcnewman/RepRapFirmware-RADDS/tree/master/Release

If, however, you try to build dcnewman/RepRapFirmware at the moment it will fail (for RADDS or Duet). Right now, the current dc42/RepRapFirmware is not in sync with the current dc42/CoreNG library. The dc42/RepRapFirmware still references the older Arduino.h header file while the current dc42/CoreNG library uses Core.h (or some name like that). My dcnewman/CoreNG and dcnewman/RepRapFirmware are tracking dc42's repo and thus have the same issue. You can roll back a week or two and successfully build. Or just use the 1.10 build in my older dcnewman/RepRapFirmware-RADDS repo. (That repo is based upon the slightly older CoreDuet library.) I've not posted any RADDS builds to my more current dcnewman/RepRapFirmware fork/repo owing to lack of time to test. Once things are again building, I'll go ahead and post a 1.12 binary.

@dc42 : "...and upload that to your Due." : That's the main part of the puzzle I'm missing. Maybe it's a terribly obvious billboard in my face, but I'm failing to find how to actually do that step. Is that the scons bit from step 8 here:
[github.com]

And if so, again apologies on my ignorance, how do you specify which .bin to upload since there are quite a few available in that distro.
scons platform=radds upload port=/dev/
Seems to not specify any specific .bin file.

Thanks again everyone. I'm sure the pieces will start to click eventually with your help

Quote
AK_Eric
@dc42 : "...and upload that to your Due." : That's the main part of the puzzle I'm missing. Maybe it's a terribly obvious billboard in my face, but I'm failing to find how to actually do that step. Is that the scons bit from step 8 here:
[github.com]

If you just have a .bin file for a SAM3X8E then you follow directions for how to use bossac. (An AVR analogy is if you have a .hex file, you might then follow directions for how to use avrdude.) Since the RADDS board is on a Arduino Due, you can try searching for directions on uploading a .bin file to an Arduino Due with bossac. You'll want to use a method which doesn't require use of the ERASE button on the board as the RADDS shield makes accessing it very difficult.

Quote
AK_Eric
And if so, again apologies on my ignorance, how do you specify which .bin to upload since there are quite a few available in that distro.

You'd want the most recent .bin file with "-radds" in the name.

Quote
AK_Eric
scons platform=radds upload port=/dev/
Seems to not specify any specific .bin file.

scons is a build tool. For building from sources. When you use it to upload a .bin to a board, it's going to want to build the sources first. So, to use that method you need to have sources building correctly with scons.

AH, that helps explain things, thanks Dan: I don't do a lot of building\compiling stuff (if you haven't noticed) and I kept reading that your port 'used scons' instead of bossac. scons for building, bossac for uploading.
I'll give it a shot, thanks!

Edited 1 time(s). Last edit at 05/26/2016 06:51PM by AK_Eric.

Under the hood, I've rigged

scons upload

to drive bossac. So it uses bossac but insulates you from some of it. (It even tickles the device port to kick it into programming mode.) HOWEVER, this doesn't help you unless you have scons first building the sources for you. If you just go straight to the .bin file then you need to also go straight to bossac (and all that entails).

Progress, I've got this going on:

I press the reset button on the RADDS board (I've also tried the LCD reset too) and execute:
$ /path/to/bossac --port=cu.usbmodem621 -e -w -v -U false -b /path/to/RepRapFirmware/Release/RepRapFirmware-1.12a-dc42.bin

But it keeps coming back telling me:
No device found on cu.usbmodem621
I tried plugging it into my other usb port, cu.usbmodem411, but it has the same response.
I can press the reset button, hold it, but always the same response.

Both the Arduino IDE & Simplify 3d tell me that's the port it's plugged into (and I close all apps before I run this code).
I have the USB plugged into the right (programming) port on the Due.

In fact, I know that something is pinging the due during that command, since when it boots (and its always done this), it hangs until I press the reset button, then Repetier fires up.
So I can boot it, it hangs, I run the above code, it immediately unhangs, then print there's no device.

Any thoughts appreciated.

Edited 2 time(s). Last edit at 05/26/2016 11:52PM by AK_Eric.

Also... I just figured out whenever I run the above bossac command, it resets the board on its own. Maybe that's part of the problem? Or the fact I already have Repetier on there? Maybe this is more bossac specific questions than RRF, but I thought I'd give it a shot here.

Quote
AK_Eric
Progress, I've got this going on:

I press the reset button on the RADDS board (I've also tried the LCD reset too) and execute:
$ /path/to/bossac --port=cu.usbmodem621 -e -w -v -U false -b /path/to/RepRapFirmware/Release/RepRapFirmware-1.12a-dc42.bin

Why are you loading Duet firmware onto a Due? That's not going to work if you have a RADDS board attached to the Due. Go back and read my prior posts of today where I pointed you at the most recent .bin file for RADDS.

Quote

But it keeps coming back telling me:
No device found on cu.usbmodem621

If this is a mac then that is indeed the wrong device: it'll be something like tty.usbmodel621.

Thanks for your patience Dan: While I read your earlier words, I completely missed you had a dcnewman/RepRapFirmware-RADDS repository. I was using the wrong one (dcnewman/RepRapFirmware). There was no -radds stuff in there, but... I just presumed I was on the right course.

On a tangent: At work, I feel like I'm you in this conversation, and have to deal with people like me

OK, so now I'm using this:
$ /path/to/bossac --port=cu.usbmodem621 -e -w -v -U false -b /path/to//RepRapFirmware-RADDS/Release/RepRapFirmware-1.10+4-dc42-radds.bin

I get the exact same issues:
No device found on cu.usbmodem621

I can connect to the Due via cu.usbmodem621 via Adruino & Simplify3D on my Mac. It's the port I use to update Repetier on. I tried blanking the Due with the 'bare minimum' sketch (via that port), which worked so far as it killed Repetier. But I still couldn't upload RRF.

Per your suggestion I tried switching cu to tty:
$ /path/to/bossac --port=tty.usbmodem621 -e -w -v -U false -b /path/to//RepRapFirmware-RADDS/Release/RepRapFirmware-1.10+4-dc42-radds.bin

Still gives me the:
No device found on tty.usbmodem621

And it's the same behavior over 'cu' or 'tty' : Whenever I run bossac, it first resets the Due... meaning, it does actually connect (or touches it), then appears to loose connection immediately after.

In the meantime, I also installed the Bossa Mac app: In the Gui lists cu.usbmodem621 as the thing I want to connect to (there is no tty ports present), but when I choose it I get a "Could not connect to device".

I can't wait to light my Mac on fire and move back to PC...

Edited 2 time(s). Last edit at 05/27/2016 02:22AM by AK_Eric.

Are you running El Capitan perhaps? USB devices are pretty hosed in it. I have no idea what you might have to do to get things working. I'm on Mavericks and using tty.usbmodemXXXX always works for me. Of course, you should be using the Due's programming port and not the native port for programming. That's the port closer to the power jack. You talk to it from S3D via the native port, the port further from the power jack. You can actually program over either port, but you may have better luck using the actual programming port.

You also need to get the -U switch correct for the Due port. It's

-U true

for the native port (port farthest from power jack). And

-U false

for the programming port (port closest to the power jack). You were using false in which case you needed to be using the programming port.

I'm on Yosimite, 10.10.5.
I'm using the programming port for all my communication, have never used the native one for anything... ever. Arduinio & S3D both talk to the board just fine over the programming port.

A few observations:
* If I change my usb port to something that's not there (like, cu.usbmodem623), bossac immediately says it can't connect as soon as I press enter.
* But if I give it a port that does exist, it does the 'board reset, pause, can't connect' scenario. So some form of communication is happening.

At this point I think my only recourse is to unwire everything from RADDS, pull the whole thing out of its case, remove the RADDS from the due, and maybe give this a shot via the native port using the erase\reset combo.
It is a long weekend...

Again, thanks for all the help.

Edited 4 time(s). Last edit at 05/27/2016 10:45AM by AK_Eric.

The command without the erase never work for me, I always push erase on the due and use the programming port before an update use some kind of wooden popsicle stick and get in there without removing the radds and press the erase, after its done I connect via native port to my Pi .

I know its not a PC but when you ready to flash it In the device manager of windows the port change to bossac something, its mean your erase press work and you can flash now.

I got it working: Took everything apart off my board, pried it out of the case, popped off the RADDS, and did the erase\reset combo using the Due's native port, running this:

$ /path/to/bossac --port=tty.usbmodem2621 -e -w -v -U true -b /path/to/RepRapFirmware-RADDS/Release/RepRapFirmware-1.10+4-dc42-radds.bin

Interesting how the native port calls it tty.usbmodem2621, while the programming port called it cu.usbmodem621
Also interesting that the bossa ui I installed still won't detect it, even over the native port.

Now... the real work begins. Thanks again everyone for all the help getting me this far.

One more question: I read the RADDS LCD isn't spoorted (yet?) : Does that mean I need to use the micro-sd slot on the RADDS instead of the normal SD slot in the LCD board?

Edited 2 time(s). Last edit at 05/28/2016 01:48AM by AK_Eric.

Quote
AK_Eric
Interesting how the native port calls it tty.usbmodem2621, while the programming port called it cu.usbmodem621

That's normal. The Due is a differrent device when in programming mode.

Quote
AK_Eric
Also interesting that the bossa ui I installed still won't detect it, even over the native port.

If you are using the bossa UI downloaded from Shumatec, that's normal too. It doesn't support the SAM3X. However, someone on the Arduino forum updated it and has published a binary for Maverick OS.

Quote
AK_Eric
One more question: I read the RADDS LCD isn't spoorted (yet?) : Does that mean I need to use the micro-sd slot on the RADDS instead of the normal SD slot in the LCD board?

I think so, but Dan will be able to confirm this. If you want a touch-screen control panel, PanelDue is supported.

---

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

Correct, direct attach, "dumb" LCD displays are not presently supported. I had a very rough port of Repetier's support but haven't finished it and now need to rework it some to get it to even build with the new code layout. It has not been a priority for me.

Thanks Dan & dc42. I've dumped a lot of work into this process over the past few days: I've got both Octoprint & Simplify3D talking to it now, getting the g files configured. Just wanted to say thanks (again) to both of you on all of the work you've both put into it your forks, allowing people like me to access it!

For the config start with a premade one and drop everything about lan connection in the config.g and also the software current for the stepper. I dont know what stepper driver you will be running but if you run dvr8825 you will encounter some speed problem if its the case just tell us. Ill send you the right .Bin with the modified timing for them if needed.

Thanks GroupB: I'm using SD6128s at 1/32 microstepping, same thing I had with Repetier on the same hardware. I'll comment out the stepper current stuff per your suggestion.
I got a config.g from a guy using a similar printer (but using a Duet), so hopefully that'll steer me in the right direction to begin with

If I have questions about configuring RRF macros, is this thread the best place for it? Or is there a more appropriate RRF forum? I've been searching and not found any RRF-centric forums.

For example, I'm using fan0 tool cool the hotend, fan1 to cool the extruded pla. H0 is heating the hotend, and I hijacked (in Repetier) H2 to drive my case cooling fan since that heater is unused.
Since it' a heater connection,... do I need to register it as a new tool via M305, or is there a better way?

I don't want to spam this thread with macro questions if it's not the best place.

thanks!

Since I'm on a roll, here's my config issues:

#1: Endstops not being detected.
Same endstops attached to the same min plugs used in Repetier (and Marlin). All three are in minimum headers on RADDS, using 'makerbot style' switches, which are 'normally open'.
Neither of these detect them at all:
M574 X1 Y1 Z1 S1
M574 X1 Y1 Z1 S0
I can hold the switch down, but the toolhead just keeps moving...
Note: I disconnected the 5v line that hooks up the LED, so only two wires (sig, -) are running into the board. Repetier ran fine with this. Any thoughts on why they wouldn't work with RRF?

#2 My filament cooling fan is constantly on.
I have my hotend fan wired into F0, and my PLA cooling fan in F1 : When the board turns on, F1 gets hit at 100% power. I've done a lot of troubleshooting, and narrowed it down to my tool definition line:
M563 P0 D0 H1
If I comment out that line, the fan't doesn't turn on, but neither does my tool get defined. What's going on there?

#3 : My hotend is not the correct temp
I'm using a E3d-V6, an in their docs they say to set the beta value in RRF to 4267K. So this is my config:
M305 P1 T100000 R1000 B4267
But I have to set it upwards of 260 deg to just barely get my PLA to barely extrude. I noticed however... I don't recall ever putting an 'inline resistor' into the mix: Should I set R to 0?

I'm excited I can actually move the toolhead & bed around, so that's progress.
Any thoughts to my above issues, or again, a more appropriate post location is appreciated.

Quote
AK_Eric
Since I'm on a roll, here's my config issues:

#1: Endstops not being detected.
Same endstops attached to the same min plugs used in Repetier (and Marlin). All three are in minimum headers on RADDS, using 'makerbot style' switches, which are 'normally open'.
Neither of these detect them at all:
M574 X1 Y1 Z1 S1
M574 X1 Y1 Z1 S0
I can hold the switch down, but the toolhead just keeps moving...

And you included the "S1" parameter in your G0/G1 command so that the endstops will be honored?

Quote

#2 My filament cooling fan is constantly on.
I have my hotend fan wired into F0, and my PLA cooling fan in F1 : When the board turns on, F1 gets hit at 100% power. I've done a lot of troubleshooting, and narrowed it down to my tool definition line:
M563 P0 D0 H1
If I comment out that line, the fan't doesn't turn on, but neither does my tool get defined. What's going on there?

The output may be inverted from what your fan expects. Try configuring the fan as inverted.

Quote

#3 : My hotend is not the correct temp
I'm using a E3d-V6, an in their docs they say to set the beta value in RRF to 4267K. So this is my config:
M305 P1 T100000 R1000 B4267
But I have to set it upwards of 260 deg to just barely get my PLA to barely extrude. I noticed however... I don't recall ever putting an 'inline resistor' into the mix: Should I set R to 0?

The RADDS board uses a 4700 ohm resistor, not a 1000 ohm. Specify R4700 and not R1000.

Attached is the config.g file I use with my RADDS + CoreXY bot

Thanks so much Dan. I'm getting closer!

Issue#1 : Endstops, still problems:
I was not using the G1 S1: Was just driving the toolhead around with S3D's jog control. Not used to the G1 S1, but I'm getting more familiar.
So I tried this:

G91
G1 X-10 F600 S1

With either of these endstop config:

M574 X1 Y1 Z1 S0
M574 X2 Y2 Z2 S0

And while the toolhead is moving, I can press the endstops, and nothing happens.

So I give these two configs a shot just to rule things out:

M574 X1 Y1 Z1 S1
M574 X2 Y2 Z2 S1

And I can't get it to move with G1 S1 at all, endstops open or close. Setting it to G1 S0 let's it move, but obviously isn't good.


Issue #2 PLA Cooling fan always on: Fixed, but new issue:
Interestingly enough, I after reading what a 'theromstatic fan' was, I set this so my extruder cooler (F0) will auto kick on when the toolhead hist 60c (which it successfully does):

M106 P0 T60 H1

And once I did that, the PLA cooling fan (F1) stopped turning on, on boot. Weird, but true.
However, I can't get the PLA cooling fan to respect PMW settings (did in Repetier). It will only turn on full blast with :

M106 P1 I1

And off with

M106 P1 I0

The S parameter seems to have no effect For example, this does nothing:

M106 P1 S255

And this still turns it on full blast:

M106 P1 S32 I1

Since it's a 24cfm fan for a volcano nozzle, I really need some control over that air-blast.

Issue #3 : Bad extrusion temp: Fixed!
The correct resistor setting fixed that. I had read the 1000\4700 ohm stuff, I guess I got it backwards. My heated bed is happier now too.

As ever, thanks for all the help!

Quote
AK_Eric
Thanks so much Dan. I'm getting closer!

Issue#1 : Endstops, still problems:
I was not using the G1 S1: Was just driving the toolhead around with S3D's jog control. Not used to the G1 S1, but I'm getting more familiar.
So I tried this:

G91
G1 X-10 F600 S1

With either of these endstop config:

M574 X1 Y1 Z1 S0
M574 X2 Y2 Z2 S0

And while the toolhead is moving, I can press the endstops, and nothing happens.

So I give these two configs a shot just to rule things out:

M574 X1 Y1 Z1 S1
M574 X2 Y2 Z2 S1

And I can't get it to move with G1 S1 at all, endstops open or close. Setting it to G1 S0 let's it move, but obviously isn't good.

My guess: you've not connected the endstops to the correct pins on the RADDS board. Go back and look at the documentation in my repo for how to wire the RADDS board for RepRapFirmware. You must use the documented pins. And since the RADDS board has both min and max hookups for each endstop, it's possible to use the wrong pins.

Quote

Issue #2 PLA Cooling fan always on: Fixed, but new issue:
Interestingly enough, I after reading what a 'theromstatic fan' was, I set this so my extruder cooler (F0) will auto kick on when the toolhead hist 60c (which it successfully does):

M106 P0 T60 H1

And once I did that, the PLA cooling fan (F1) stopped turning on, on boot. Weird, but true.
However, I can't get the PLA cooling fan to respect PMW settings (did in Repetier). It will only turn on full blast with :

M106 P1 I1

And off with

M106 P1 I0

The S parameter seems to have no effect For example, this does nothing:

M106 P1 S255

And this still turns it on full blast:

M106 P1 S32 I1

Since it's a 24cfm fan for a volcano nozzle, I really need some control over that air-blast.

Again, refer to the wiring info in my Repo. I know that the cooling fan works fine with the config.g file I provided when wired as per the instructions for RRF on RADDS. I use it all the time and it works fine for me.

Quote
AK_Eric
Issue #2 PLA Cooling fan always on: Fixed, but new issue:
Interestingly enough, I after reading what a 'theromstatic fan' was, I set this so my extruder cooler (F0) will auto kick on when the toolhead hist 60c (which it successfully does):

M106 P0 T60 H1

The thermostatic fan is P1, not P0.

Quote

And once I did that, the PLA cooling fan (F1) stopped turning on, on boot. Weird, but true.
However, I can't get the PLA cooling fan to respect PMW settings (did in Repetier). It will only turn on full blast with :

M106 P1 I1

And off with

M106 P1 I0

The S parameter seems to have no effect For example, this does nothing:

M106 P1 S255

And this still turns it on full blast:

M106 P1 S32 I1

Since it's a 24cfm fan for a volcano nozzle, I really need some control over that air-blast.

Print cooling fan is P0. Your commands for P1 were likely ignored since that is the thermostatic fan and it was configured to not turn on unless the extruder reached a temp of 45C.