RADDS work now stable with RepRap Firmware
Posted by angelo
|
Re: RADDS work now stable with RepRap Firmware July 02, 2016 10:32AM |
Registered: 9 years ago Posts: 185 |
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 |
Registered: 9 years ago Posts: 185 |
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.
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 |
Registered: 8 years ago Posts: 68 |
|
Re: RADDS work now stable with RepRap Firmware July 02, 2016 11:44AM |
Registered: 9 years ago Posts: 185 |
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 |
Registered: 8 years ago Posts: 68 |
|
Re: RADDS work now stable with RepRap Firmware July 02, 2016 12:18PM |
Registered: 9 years ago Posts: 185 |
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 |
Registered: 8 years ago Posts: 68 |
|
Re: RADDS work now stable with RepRap Firmware July 02, 2016 03:22PM |
Registered: 10 years ago Posts: 14,685 |
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], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
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].
|
Re: RADDS work now stable with RepRap Firmware July 02, 2016 06:28PM |
Registered: 9 years ago Posts: 185 |
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 |
Registered: 10 years ago Posts: 14,685 |
Yes, the PIO_OWER bits are set only for the step pins.
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].
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].
|
Re: RADDS work now stable with RepRap Firmware July 02, 2016 06:52PM |
Registered: 9 years ago Posts: 185 |
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 |
Registered: 8 years ago Posts: 356 |
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!
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 |
Registered: 8 years ago Posts: 68 |
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 ?
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 |
Registered: 9 years ago Posts: 5,232 |
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.
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 |
Registered: 8 years ago Posts: 68 |
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.
[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 |
Registered: 9 years ago Posts: 5,232 |
|
Re: RADDS work now stable with RepRap Firmware July 03, 2016 03:06PM |
Registered: 9 years ago Posts: 185 |
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 |
Registered: 8 years ago Posts: 68 |
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.
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 |
Registered: 10 years ago Posts: 14,685 |
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], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
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], E3D tool changer, 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 |
Registered: 8 years ago Posts: 68 |
|
Re: RADDS work now stable with RepRap Firmware July 03, 2016 08:26PM |
Registered: 8 years ago Posts: 83 |
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 |
Registered: 9 years ago Posts: 185 |
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
- Microprocessor pin assignments -- vastly different between the two. The higher level RRF code is not impacted, just the underlying pin assignments differ.
- 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.
- 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 |
Registered: 8 years ago Posts: 68 |
|
Re: RADDS work now stable with RepRap Firmware July 04, 2016 01:29PM |
Registered: 9 years ago Posts: 185 |
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 |
Registered: 8 years ago Posts: 68 |
|
Re: RADDS work now stable with RepRap Firmware July 04, 2016 03:27PM |
Registered: 11 years ago Posts: 12 |
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.
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 |
Registered: 9 years ago Posts: 185 |
|
Re: RADDS work now stable with RepRap Firmware July 04, 2016 04:03PM |
Registered: 11 years ago Posts: 12 |
|
Re: RADDS work now stable with RepRap Firmware July 04, 2016 06:57PM |
Registered: 11 years ago Posts: 12 |
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.
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 |
Registered: 9 years ago Posts: 185 |
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.