Welcome! Log In Create A New Profile

Advanced

RADDS work now stable with RepRap Firmware

Posted by angelo 
Re: RADDS work now stable with RepRap Firmware
July 02, 2016 10:32AM
Quote
o_lampe
The RADDS version of the config.g has a non defined parameter:

For the record, there is no difference between the config.g files in the dc42 RRF repo and those in the RADDS fork of dc42 RRF.

Quote

M574 X2 Y2 Z2 P1
I guess it should be S1 or S0?

But either way, I can't make my endstops talk to RRF. Defined as S1 they always show " at max endstop"; defined as S0 they always show "not triggered " when I send M119 command.

First note that the endstops are ignore by motion commands unless you include "S1" in the motion command. E.g., "G1 X100 Y100 F3600 S1". Second, you also must ensure that the firmware understands the directions of motion for each axes. That is, when you command a motion in the +X direction, that it actually moves towards the X-max endstop and not away from it. Likewise for a X-min endstop.
Re: RADDS work now stable with RepRap Firmware
July 02, 2016 10:34AM
Quote
o_lampe
Where would I put my z-probe connectors? On a duet it'd be the E0 endstop, but I've found no dokumentation about it on doku.radds.....
Searching the forum for [radds z-probe (all words)] showed each comment where radds was included. eye rolling smiley
WTF does all words mean then?

Also, see https://github.com/dcnewman/RepRapFirmware/blob/dev/doc/RADDS-v1.5.md#inductive-z-probe
Re: RADDS work now stable with RepRap Firmware
July 02, 2016 11:26AM
Dnewman, can i use your 1.13a firmware with DVR8825 steppers ?
Should I replace them by raps128 ?

Thanks
Re: RADDS work now stable with RepRap Firmware
July 02, 2016 11:44AM
Quote
shofman
Dnewman, can i use your 1.13a firmware with DVR8825 steppers ?
Should I replace them by raps128 ?

Thanks

No. If you use DVR8825 steppers, you need that special 1.09something build I did some time back for GroupB. (You can PM him for a copy.) Otherwise, you just have to print at lower step rates.
Re: RADDS work now stable with RepRap Firmware
July 02, 2016 11:59AM
What is the maximum step rate that I can use ?
Re: RADDS work now stable with RepRap Firmware
July 02, 2016 12:18PM
Quote
shofman
What is the maximum step rate that I can use ?

You may be able to work it out from the past posting by GroupB on the subject. There was a feedrate below which things work and a feedrate above which things did not. Multiply that by his steps/mm for the impacted axis and you will then have the step rates. You can then use your own steps/mm to translate that into maximum feedrates for your printer.
Re: RADDS work now stable with RepRap Firmware
July 02, 2016 12:25PM
Ok thanks.
Re: RADDS work now stable with RepRap Firmware
July 02, 2016 03:22PM
I have just released version 1.14 of RepRapFirmware for the Duet and Duet WiFi, with a new T parameter to the M569 command to extend the step pulse timings. Some of the changes are very hardware-dependent, so somebody will need to do a little work on the code before it can be built for RADDS.



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

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: RADDS work now stable with RepRap Firmware
July 02, 2016 06:28PM
Quote
dc42
I have just released version 1.14 of RepRapFirmware for the Duet and Duet WiFi, with a new T parameter to the M569 command to extend the step pulse timings. Some of the changes are very hardware-dependent, so somebody will need to do a little work on the code before it can be built for RADDS.

Looked at it. Should be straightforward given that PIO_OWER is only set for the step pins (as far as I've spotted). The RADDS has the step pins on ports A, B, C, and D with only one conflict.
Re: RADDS work now stable with RepRap Firmware
July 02, 2016 06:41PM
Yes, the PIO_OWER bits are set only for the step pins.



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

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: RADDS work now stable with RepRap Firmware
July 02, 2016 06:52PM
I've uploaded a 1.14-radds.bin build which appears to work. I write "appears" because I was just starting to pull the RADDS board to install a new field test board for testing. So, I put the RADDS back in, started a simple print, worked fine, and then got back to installing the new board.
Re: RADDS work now stable with RepRap Firmware
July 03, 2016 02:41AM
Its nice to have a extend pulse now. One more step into the multiple hardware adaptation of RRF, I hope one day we will just need to add something in config to select Radds/Due or Duet or whatever board instead of going to multiple branch of the RRF and you two can work together pushing RRF further instead of redoing the code for a different board each version.

Im still with dvr8825 right now but im gonna wire my raps128 and 24V very soon so maybe Ill test it out with extend pulse before do the switch and report and lets you guys know, since im the only one using longer pulse ( not counting shofman cause I dont know if he got a functional printer yet and he probably dont know what to look for as limitation of shorter pulse)

Keep the good work guys!
Re: RADDS work now stable with RepRap Firmware
July 03, 2016 03:01AM
GroupB, you're right ! My printer is not funcitonal yet... But I have some noise problem with the motors if I do many moves (absolute for now) in a short time.
And I will switch my steppers to raps128 too...

Dnewman and DC42, is there any chance to have in the future only one RRF version, and only have to modify some specific parameters in a file to use the selected hardware ?
Re: RADDS work now stable with RepRap Firmware
July 03, 2016 01:21PM
OK, thanks to you helpful people, I got my endstops and z-probe running.
TBH, I read the part about "inductive z-probe" before, but didn't think it was for simple switches too...

Now the next step is to install octopi on a RasPi zero and get it talking to a 7" win8.1 tablet.
Anything I should know beforehand? Neither the doku.radds page nor dcnemans github page mention anything, so I'm hoping it'll work.
Re: RADDS work now stable with RepRap Firmware
July 03, 2016 01:26PM
Look at the AK_Eric blog :
[www.akeric.com]

Many good informations...

Edited 1 time(s). Last edit at 07/03/2016 04:56PM by shofman.
Re: RADDS work now stable with RepRap Firmware
July 03, 2016 02:27PM
Thanks shofman,
did a quick read into it and it seems, the only issue he had was to access the radds-sd card via OP.
I wish we could see the sd-card from a windows explorer too. Making changes to the config file would be a lot like duet's web UI then.
Re: RADDS work now stable with RepRap Firmware
July 03, 2016 03:06PM
Quote
shofman

Dnewman and DC42, is there any chance to have in the future only one RRF version, and only have to modify some specific parameters in a file to use the selected hardware ?

Not practical. There's too many cart-before-the-horse problems. For example, how on startup do you ensure that all heaters are turned off UNLESS you first know the type of electronics and thus the microprocessor pin to heater assignments? Okay, you read the config.g file? But how do you do that as you do not know the electronics yet and thus do not know the pin assignments for the SD card I/O lines, the SD card chip select line, etc., etc.. Fumbling around probing pins could, in general, cause problems -- safety problems. So no, in general this is not practical.
Re: RADDS work now stable with RepRap Firmware
July 03, 2016 04:44PM
Ok forget the config file for the board.
It's not possible to make a test that can determine the board under the firmware before startup and load the config files on SD card ?
Like searching the SD card I/O ? If you know the pins on RADDS and Duet and they are not the same, it make sense ?
The goal of that is only to support selected boards.

Edited 3 time(s). Last edit at 07/03/2016 04:48PM by shofman.
Re: RADDS work now stable with RepRap Firmware
July 03, 2016 05:01PM
As Dan says, there are just too many differences. We have a separate build of RepRapFirmware for the Duet WiFi too.

I'm not saying it is impossible, it's just not very practical.

Edited 1 time(s). Last edit at 07/03/2016 05:03PM by dc42.



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

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: RADDS work now stable with RepRap Firmware
July 03, 2016 05:11PM
Ok thanks men for your informations.
Re: RADDS work now stable with RepRap Firmware
July 03, 2016 08:26PM
Does RRF have any sort of hotend 'auto PID' tuning a-la Marlin's M303? I'm finding on my larger volcano nozzles that when the cooling fan kicks in, the heater is having a hard time recovering. If I manually bump the temp during this time it'll heat up no prob and then settle, so I don't think it's a lack of power. I've never invested enough brainpower into manually tuning the PID, so any help down this avenue would be appreciated.
Re: RADDS work now stable with RepRap Firmware
July 03, 2016 09:36PM
Quote
dc42
As Dan says, there are just too many differences. We have a separate build of RepRapFirmware for the Duet WiFi too.

I'm not saying it is impossible, it's just not very practical.

I want to qualify dc42's answer a little. The functional 3D printing code is 99.99% identical. The differences are all in

  1. Microprocessor pin assignments -- vastly different between the two. The higher level RRF code is not impacted, just the underlying pin assignments differ.
  2. Low level code for the SD card is different owing to the fact that the Arduino Due does not expose the high-speed SD card interface built into the Atmel SAM3X8E chip. As a result the significantly slower, serial SPI interface must be used on RADDS. This requires different code at that layer of the code supporting the SD card file system.
  3. No Ethernet / TCP/IP / Web interface on the RADDS and hence that RRF code is inert. It's compiled in, just not enabled.
Re: RADDS work now stable with RepRap Firmware
July 04, 2016 01:19PM
Hi Dnewman,

What's new on your 1.14 firmware ?
Re: RADDS work now stable with RepRap Firmware
July 04, 2016 01:29PM
Quote
shofman
Hi Dnewman,

What's new on your 1.14 firmware ?

I did the port, the rest of the credit goes to others. dc42 posts brief releases notes with each new firmware in the duet forum here,

http://forums.reprap.org/read.php?416,683592,683592#msg-683592
Re: RADDS work now stable with RepRap Firmware
July 04, 2016 01:32PM
Ok thanks !
Re: RADDS work now stable with RepRap Firmware
July 04, 2016 03:27PM
Hi all,

started this weekend to work with my Arduino Due / RADDS combo (used to control my Eustathios 3D printer). Although first step went OK, since today RRF cannot read the SD anymore which is quite essential. Tried all suggestions of first power on, then reset, unfortunately to no avail.

RRF-RADDS has been updated up to 1.1.14 (thnx, great work).

Any suggestions how this can be resolved as it makes the system practically unusable.

What I can offer is to connect my scope to the SD port and check what happens and to install temporarily one of the example programs that belong to the SdFat library and verify for similar behaviour (or observe that this does work).

Edited 1 time(s). Last edit at 07/04/2016 03:28PM by turboproc.
Re: RADDS work now stable with RepRap Firmware
July 04, 2016 03:54PM
All I can say is that SD works fine on my two RADDS + Arduino Due boards with RRF 1.14. Do NOT use the SD card slot on the RADDS LCD module. You need to disconnect the RADDS LCD module and use the microSD slot on the RADDS board itself.
Re: RADDS work now stable with RepRap Firmware
July 04, 2016 04:03PM
Hi,

these are the nasty problems: occur on some systems and don't on others. The LCD module is an easy part: I don't have one. Will do some further deep dives.
Re: RADDS work now stable with RepRap Firmware
July 04, 2016 06:57PM
This is weird: loading the DUE board with one of the SdFat example programs immediately shows all the details of the SD card. Took more time to upload the program than to run it.

Is it possible to activate a debugging log in the SPI or Storage part of the code? Haven't crawled yet through the CoreNG source yet. Presume it is somewhere there.
Re: RADDS work now stable with RepRap Firmware
July 04, 2016 09:54PM
Quote
turboproc
This is weird: loading the DUE board with one of the SdFat example programs immediately shows all the details of the SD card. Took more time to upload the program than to run it.

Is it possible to activate a debugging log in the SPI or Storage part of the code? Haven't crawled yet through the CoreNG source yet. Presume it is somewhere there.

And you've actually have the card with the folder

sys

and in that folder have placed the file

config.g

Being able to read the card is one thing. Having the correct directory layout with the necessary files in the correct directories is another matter.

As to enabling debugging, you'll have to go through the code, provide the necessary debug printing function, and wire it up to output to somewhere useful. It's the Atmel ASF code for an SD card on SPI. But the debugging isn't tied into the RepRapFirmware's debugging system.
Sorry, only registered users may post in this forum.

Click here to login