RADDS work now stable with RepRap Firmware

Yes you can resume a paused print, see [reprap.org].

---

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

AH, I was under the (false) impression you could only issue an M24 if you'd issued an M25 first. Probably overthinking this.
Thanks

Quote

Quote

o_lampe
It seems my Due has a stuck erase button, so I can test the new .bin file when I get a replacement board.

Can you remove it and either replace it or just short it briefly when you need to upload?

I could unsolder it, but its a brand new board I bought locally and asked the vendor to replace it.

Hey guys,
I just want to lets you know those who are in North America and were looking for raps128 they finally in stock at makerfarm, been 3 month since they are out of stock everywhere!

I order 5 and will finally ( lets hope) get rid of that circle problem on my print cause by the low current zone of the DVR8825 and as a bonus I will finally be able to change my power to 24V (24V give worst circle with 8825, so I was using 12V in the meantime) and move forward and finish enclose my printer!

This news make my day

I tried to switch my octopi to the dev branch to get the RRF modification eric was talking about and its not there... Maybe I did something wrong... here what I did

First I follow the instruction in eric link and it update my octopi image to the recent stable one ( I was still on a old one)

so I figure you need to be in dev branch to have that maybe, so I switch to dev branch doing that :

cd ~/OctoPrint
git pull && git checkout devel
~/oprint/bin/python setup.py clean
~/oprint/bin/python setup.py install
sudo service octoprint restart

Now im in dev branch but there no RRP folder thing in feature...

What I did wrong?

What does Octoprint say when you open the web front end? Should say:
1.3.0.dev784+gf8c67fd (dev/rrpFileOpened branch)
At the bottom.

You left out this part of your code-paste (would normally be the first line):

sudo chown -R pi.pi ~/oprint ~/OctoPrint

Did you do that first?

Also, what you pasted above isn't what I have in my blog, you did 'checkout devel', should be:

git pull && git checkout dev/rrpFileOpened

This is what I used to get it working:

sudo chown -R pi.pi ~/oprint ~/OctoPrint
cd ~/OctoPrint
git pull && git checkout dev/rrpFileOpened
~/oprint/bin/python setup.py clean
~/oprint/bin/python setup.py install
sudo service octoprint restart

OK thanks for the info, Ill try tonite, your link to your google question and the anwser you got do not specified the git pull ... the guy just presume everyone know how to use the right git... and I dont, but now I know

The stuff I pasted above is directly from my blog, which is the exact syntax needed.
[www.akeric.com]

In the google group question (the 2nd comment) he explicitly states you need to replace devel with dev/rrpFileOpened:
< snip >
Use the instructions here: [github.com]
Except "git checkout dev/rrpFileOpened" instead of "git checkout devel"
< \snip >

Don't get me wrong though, I know it's all confusing. I actually know nothing about git. I'm surprised I got that part right on the first try myself

Edited 2 time(s). Last edit at 06/15/2016 05:46PM by AK_Eric.

I did not saw that comment where he said that ... maybe that a hidden comment only for you ...clicking on the google question reveal only those 2 answer :

OK, I added a new setting to that same branch (Use relative paths for SD select). It's under "Settings"->"Features", look for the RepRap Firmware tag.

To pick up that new change do this (assumes octopi image):

ssh into the pi user on the the octopi instance in question, then

cd ~/OctoPrint
git pull
~/oprint/bin/python setup.py clean
~/oprint/bin/python setup.py install
sudo service octoprint restart

Wait a bit, then refresh the browser, the go to settings->features and check the relative path checkbox.

then he said later :

I'd have to PR this into the mainline. I'll check in with foosel and ask her to review my changes. If she decides to take this change it'd likely be for the devel branch so not until 1.3 or later. Another way to go would be to wait until the comm refactor and put this in a reprapfirmware plugin instead.

Weird! : I logged out of Google, and sure enough, like half of that conversation is missing: 9 comments, instead of the 15 I see when I'm logged in. Google group fail
That would explain why you're having a hard time and probably think I'm crazy
I updated my blog to just remove that link since it's just making things confusing...

Edited 1 time(s). Last edit at 06/16/2016 12:31AM by AK_Eric.

FWIW, earlier today I uploaded a RepRapFirmware 1.13-dc42 build for RADDS. (Prior build was a 1.13beta.)

https://github.com/dcnewman/RepRapFirmware/blob/dev/Release/RepRapFirmware-1.13-dc42-radds.bin

This build also presents the USB as a non-combo device; it's only a USB CDC device. Windows users can use the .inf driver files in,

https://github.com/dcnewman/RepRapFirmware/tree/dev/Driver

which are identical to the ones in the dc42 parent repo.

(edited to reflect missing S0 parameter to M997 command.)

And in other news, the In Application Programming (IAP) support is now also available for the RADDS port of RRF. It was introduced circa 1.12. I myself have only tested it with 1.13 of the RADDS port. As such, my recommendation is to upgrade first to 1.13 using bossac and then use the IAP support for later upgrades.

It works by your placing in the SD card's sys/ folder the binary file iapradds.bin,

https://github.com/dcnewman/DuetIAP/blob/master/Release/iapradds.bin

At such time that there's a new firmware release, follow the steps below. (The same steps can be used for Duet hardware, but since Duet hardware has a webserver, Duet owners should use the simpler approach of working through the Duet webserver).

1. Power down the RADDS board and remove the SD card.
2. From a desktop computer, copy the desired RADDS firmware file to the file "RepRapFirmware.bin" in the "sys/" folder on the SD card.
3. Eject the SD card and place it back into the RADDS.
4. Connect to the RADDS over USB (or from a Panel Due) and send the command M997 S0.
5. Wait about a minute and then reconnect to the RADDS board. The new firmware should be installed. The RepRapFirmware.bin file is removed from the SD card automatically.

When you do this with a RADDS board connected to peripherals (e.g., stepper motors), it is recommended to do this with the bot's power on. Particularly if you have RAPS128 drivers which may, owing to their inverted enable, turn on during the upgrade and when the processor is running under the iapradds.bin firmware. Peripherals may draw more power than a computer's USB port will provide (typically a max of 500mA).

Edited 1 time(s). Last edit at 06/17/2016 07:28PM by dnewman.

Dan, thermostatic fan control is not completely working in version 1.13 of my parent repo, so probably not in your RADDS build either. I plan to correct this tomorrow in release 1.13a.

---

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
dc42
Dan, thermostatic fan control is not completely working in version 1.13 of my parent repo, so probably not in your RADDS build either. I plan to correct this tomorrow in release 1.13a.

Just checking: Does that mean this would not work (in my config.g) if I upgraded:

M106 P0 T60 H1

I'd recently been reading about this feature (updating the firmware off the SD direclty), so I'd love to upgrade to take advantage of it (for future updates, I hate having to unwire my entire board just to get access to the Due's reset button), but I want to make sure my thermostatic fan keeps working...

Thanks guys!

Quote
AK_Eric
I'd recently been reading about this feature (updating the firmware off the SD direclty), so I'd love to upgrade to take advantage of it (for future updates, I hate having to unwire my entire board just to get access to the Due's reset button), but I want to make sure my thermostatic fan keeps working...

Sound like you only need to wait a day or so (or less). Once I see that dc42 has posted 1.13a, I'll merge the changes in, do a build for RADDS, check the fan control, and then upload the new 1.13-dc42-radds.bin.

Awesome, thanks Dan. The idea of not having to unwire my board to access the Due's reset (edit: erase) button every time I' want to update the firmware is... appealing

Edited 2 time(s). Last edit at 06/18/2016 02:35PM by AK_Eric.

Quote
AK_Eric

Quote
dc42
Dan, thermostatic fan control is not completely working in version 1.13 of my parent repo, so probably not in your RADDS build either. I plan to correct this tomorrow in release 1.13a.

Just checking: Does that mean this would not work (in my config.g) if I upgraded:

M106 P0 T60 H1

I'd recently been reading about this feature (updating the firmware off the SD direclty), so I'd love to upgrade to take advantage of it (for future updates, I hate having to unwire my entire board just to get access to the Due's reset button), but I want to make sure my thermostatic fan keeps working...

Thanks guys!

I never remove my radds to flash my due and I flash maybe a dozen time and like you I have to hit the erase button ( probably what you mean by reset button, since the due reset is on the edge of the board ).I use a popsicle stick to reach it, its super easy.


I will have my raps128 next week probably so I will be able to upgrade from my special 8825 firmware and try the new one I have a question about the next feature of the firmware for the radds, is there in the future plan to have the servo output working with RRF ? or any detection pin like if that switch is close then do something if its open then do nothing?

I try to figure a way to open a trap after the print is done, then ventilate the enclose, then close the trap and trigger a led to tell you its ventilate.

Edited 1 time(s). Last edit at 06/18/2016 11:20AM by GroupB.

Quote
GroupB
I have a question about the next feature of the firmware for the radds, is there in the future plan to have the servo output working with RRF ?

I don't know of any plans offhand. There was this thread in the issue tracker for the dc42 repo (parent of our RADDS repo),

https://github.com/dc42/RepRapFirmware/issues/49

Quote
GroupB
or any detection pin like if that switch is close then do something if its open then do nothing?

I try to figure a way to open a trap after the print is done, then ventilate the enclose, then close the trap and trigger a led to tell you its ventilate.

See M581 and M583.

"I never remove my radds to flash my due and I flash maybe a dozen time and like you I have to hit the erase button ( probably what you mean by reset button, since the due reset is on the edge of the board ).I use a popsicle stick to reach it, its super easy."

I meant erase... sigh. Stoopid terminology.
I hear what you're saying, I'm trying to figure out how to get that stick in there and know where to actually press, I feel pretty blind and that button is small. Maybe persistence will pay off

Edited 1 time(s). Last edit at 06/18/2016 02:43PM by AK_Eric.

Quote
AK_Eric
"I never remove my radds to flash my due and I flash maybe a dozen time and like you I have to hit the erase button ( probably what you mean by reset button, since the due reset is on the edge of the board ).I use a popsicle stick to reach it, its super easy."

I meant erase... sigh. Stoopid terminology.
I hear what you're saying, I'm trying to figure out how to get that stick in there and know where to actually press, I feel pretty blind and that button is small. Maybe persistence will pay off

Time to construct and print a remote_erase button mechanic ( A popsicle stick is not reprap-style )

Quote
o_lampe

Quote

Quote

o_lampe
It seems my Due has a stuck erase button, so I can test the new .bin file when I get a replacement board.

Can you remove it and either replace it or just short it briefly when you need to upload?

I could unsolder it, but its a brand new board I bought locally and asked the vendor to replace it.

Remember my erase button problem?

Now that I got a replacement board send ( still in the mail ) I unsoldered the erase button but the native USB is still seen as Bossac program port.
I studied the schematics and saw the R99 and T3 circuit which run parallel to the erase button.
I found T3 near the ICSP connector, but R99 is nowhere on the board. According to the eagle files of Due_R3 it should be close to T3, but maybe the cloners had a different idea?

Should I unsolder T3 to see if it works then? Would I have to pull down the erase pin of the processor then? It would be "floating" otherwise, or does it have an internal pull_down?

Edited 1 time(s). Last edit at 06/19/2016 05:07AM by o_lampe.

Success!
My due with erase_button problems now is talking through the native port.
I had to unsolder the erase button and pull_down the erase input pin to GND.
Windows 8.1 shows an exclamation mark for the newly shown "arduino Due" device.

I installed the latest RADDS1.13 firmware together with dc42's USB-CDC drivers and Bingo.
Now the Board registers as Duet and communicates with pronterface etc.

Big thanks to dc42 and dnewman for their support and never ending patience
-Olaf

Quote
o_lampe
Success!
My due with erase_button problems now is talking through the native port.
I had to unsolder the erase button and pull_down the erase input pin to GND.
Windows 8.1 shows an exclamation mark for the newly shown "arduino Due" device.

I installed the latest RADDS1.13 firmware together with dc42's USB-CDC drivers and Bingo.
Now the Board registers as Duet and communicates with pronterface etc.

Big thanks to dc42 and dnewman for their support and never ending patience
-Olaf

welcome into the RRF family, my suggestion of checking your erase button was not wrong after all

I think dan and dc said the 1.13 was not working right and dan should release a patch for that soon, something about the firmware update via SD card or the thermo fan for the hotend , read the last page, in the meantime maybe you should use the 1.12.

Edited 1 time(s). Last edit at 06/19/2016 09:25AM by GroupB.

Quote
o_lampe
Big thanks to dc42 and dnewman for their support and never ending patience
-Olaf

Congrats! Keep an eye on the temp sensor readings for the first few minutes: a number of people with clone Dues had issues with A/D reads. Apparently, there's some known issues in that area with some of the clone Dues.

Quote
GroupB
I think dan and dc said the 1.13 was not working right and dan should release a patch for that soon

as per dc42, a bug was introduced into the thermostatic fan control code -- the code which can be enabled to automatically enable a fan when a temp sensor attains or exceeds a defined temperature. (Used, for example, for a heatsink cooling fan on an extruder heatsink).

FWIW, I've picked up the changes for RRF 1.13a-dc42 and CoreNG ("arduino" libraries). However, there's a change somewhere in RRF 1.13a-dc42 which breaks the first extruder heater output on RADDS. I've confirmed it's not the CoreNG changes. But it may be something used by them? Likely something tripping over Arduino Due D13 == PWM13 == SAM B.27.

Net, net, no 1.13a-dc42-radds until this is resolved.

[edited to add other possible problem call]

I've uploaded a 1.13a-dc42-radds.bin file. I've temporarily disabled the core part of the new MCU temp monitoring code. Namely the lines

temperatureAdcChannel = GetTemperatureAdcChannel();
AnalogInEnableChannel(temperatureAdcChannel, true);

and

currentMcuTemperature = AnalogInReadChannel(temperatureAdcChannel);

It's that second line (I assume) which is clobbering use of Arduino Due D13 as a heater output with RADDS. (I didn't check the other heater outputs.)

Edited 1 time(s). Last edit at 06/19/2016 09:32PM by dnewman.

Hey all,

What are folks here using in terms of voltage/current set in the drivers in their RADDS?
I have the RAPS128 drivers and Nema 17 stepper motors.

I ask as the Z seems to be quite weak, I have the driver set to 1.16v. And barely touching rods when it's moving make them stop
I'd expect a bit more of torque, so I wonder if the current is low.

Thanks!

For RAPS128, I believe the vref to current limit relationship is

current = VREF * 0.9125 Amps / Volt 

Quote
Nandox7
Hey all,

What are folks here using in terms of voltage/current set in the drivers in their RADDS?
I have the RAPS128 drivers and Nema 17 stepper motors.

I ask as the Z seems to be quite weak, I have the driver set to 1.16v. And barely touching rods when it's moving make them stop
I'd expect a bit more of torque, so I wonder if the current is low.

Thanks!

If you have two Z motors connected in parallel, try connecting them in series instead. Connecting them in parallel is only a good idea if they are low-current high- (relatively) voltage motors.

---

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