RADDS work now stable with RepRap Firmware
Posted by angelo
|
Re: RADDS work now stable with RepRap Firmware March 11, 2017 02:39AM |
There is a setup in the folder section to specify which devices are shown.
I tried to send files to RADDS-SD-Card but that is painfully slow, so I only use Octopi's SD-card now.
Edited 1 time(s). Last edit at 03/11/2017 03:01AM by o_lampe.
I tried to send files to RADDS-SD-Card but that is painfully slow, so I only use Octopi's SD-card now.
Edited 1 time(s). Last edit at 03/11/2017 03:01AM by o_lampe.
|
Re: RADDS work now stable with RepRap Firmware March 13, 2017 04:11AM |
Thanks to both of you,
it seems, I have to compile RRF myself for the first time. Wish me luck
it seems, I have to compile RRF myself for the first time. Wish me luck
|
Re: RADDS work now stable with RepRap Firmware March 13, 2017 07:34AM |
edit2: Stupid me:
During the initial probe-tests; I had set the T parameter for travel speed to 500.
Of course the probe doesn't change then
...and the journey continues:
I've flashed a virgin Due board with RRF1.17d and it does the same: ignoring the probe input.
I beeped the traces of RADDS and the signal passes through to the Due board.
I can read 3V on the PWM3 pin, which means the cpu-pin is in " input_pullup" mode.
I went through my config file and undid all the changes I made according grid size.
I even checked the config_override file and commented out the three G31 lines. But the probe doesn't do anything.
I played around with the I and R parameters expecting to see any change, but nothing.
I don't get it, why did bed probing work 3 times, but not anymore ( with no obvious hardware fault )
Did I mess up the RADDS Eeprom? How can I reset that? Is it the classic "M502 & M500 " way?
Edited 3 time(s). Last edit at 03/13/2017 07:53AM by o_lampe.
During the initial probe-tests; I had set the T parameter for travel speed to 500.
M558 P4 X0 Y0 Z1 I1 R1 H8 F300 T500Later, when I got more confident, I wanted to change it back to 5000, but instead changed the P parameter of this line: G31 X0 Y80 Z0 P5000
Of course the probe doesn't change then
Quote
o_lampe
Has anyone found another pin that works as z-probe input than PWM3? I grilled mine yesterday and it seems both other pins RRF can use with Duet boards are occupied on RADDS.
Can I use Z-min endstop as probe input? How do I tell RRF to use this pin? ( M558 P? )
...and the journey continues:
I've flashed a virgin Due board with RRF1.17d and it does the same: ignoring the probe input.
I beeped the traces of RADDS and the signal passes through to the Due board.
I can read 3V on the PWM3 pin, which means the cpu-pin is in " input_pullup" mode.
I went through my config file and undid all the changes I made according grid size.
I even checked the config_override file and commented out the three G31 lines. But the probe doesn't do anything.
; Z probe parameters ;G31 T1 P400 X0.0 Y0.0 Z0.70 ;G31 T3 P400 X0.0 Y0.0 Z0.70 ;G31 T4 P400 X0.0 Y0.0 Z0.00
I played around with the I and R parameters expecting to see any change, but nothing.
; Z probe
I don't get it, why did bed probing work 3 times, but not anymore ( with no obvious hardware fault )
Did I mess up the RADDS Eeprom? How can I reset that? Is it the classic "M502 & M500 " way?
Edited 3 time(s). Last edit at 03/13/2017 07:53AM by o_lampe.
|
Re: RADDS work now stable with RepRap Firmware March 16, 2017 06:26AM |
I'd used Ramps/Marlin to engrave and laser cut before and wanted to try this on RADDS/RRF1.17d too.
But the fan output ( with a resistor voltage divider to TTL level ) doesn't seem to offer a clean on/off signal.
So I searched for unused I/O pins I could control with M42 Pnn S0..1 to trigger the laser-driver.
The Wiki offers a list of pins, but I could only manage to use two of them ( with wrong pin assignments according to the RADDS doku )
Then there are a few pins, I tried to trigger, but got a warning message on Octoprints terminal, like" pin can't be used for writing"
Also there were a few pins, I could write to, but couldn't find a pin on RADDS, that showed any change.
Here's a list with the results so far:
I'm not complaining, just want to publish my findings for others.
But the fan output ( with a resistor voltage divider to TTL level ) doesn't seem to offer a clean on/off signal.
So I searched for unused I/O pins I could control with M42 Pnn S0..1 to trigger the laser-driver.
The Wiki offers a list of pins, but I could only manage to use two of them ( with wrong pin assignments according to the RADDS doku )
Then there are a few pins, I tried to trigger, but got a warning message on Octoprints terminal, like" pin can't be used for writing"
Also there were a few pins, I could write to, but couldn't find a pin on RADDS, that showed any change.
Here's a list with the results so far:
I'm not complaining, just want to publish my findings for others.
|
Re: RADDS work now stable with RepRap Firmware March 16, 2017 06:47AM |
... for a discussion in another forum I've made an image, comparing a basic RADDS+RAPS128 board (in the bottom-left corner) with our "RADDS-compatible" industry-grade controller:
It does essentially the same (can even run with RAPS128 instead of the big stepper-drivers) ... only with the difference of 24 Volt level I/O's with optocouplers and 44 Volts for the stepper drivers
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]
It does essentially the same (can even run with RAPS128 instead of the big stepper-drivers) ... only with the difference of 24 Volt level I/O's with optocouplers and 44 Volts for the stepper drivers
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]
|
Re: RADDS work now stable with RepRap Firmware March 16, 2017 07:55AM |
My engraving results with M42 are the same as with M106. The laser doesn't seem to switch off reliably...
With lots of fantasy you can see where the dots should be ( compare with CNC-view below ), but there are several lines where the pin should be off.
...and a sample of the Gcode:
With lots of fantasy you can see where the dots should be ( compare with CNC-view below ), but there are several lines where the pin should be off.
...and a sample of the Gcode:
; Generated with: ; "Raster 2 Laser Gcode generator" ; by 305 Engineering G21; Set units to millimeters G90; Use absolute coordinates G92 ; Coordinate Offset M42 P66 S0 ;init D66 as output G00 X134.3 Y13.7 F2000 M42 P66 S1 G01 X134.0 Y13.7 F2000 M42 P66 S0 G00 X128.0 Y13.7 F2000 M42 P66 S1 G01 X127.0 Y13.7 F2000 M42 P66 S0
|
Re: RADDS work now stable with RepRap Firmware March 17, 2017 05:22AM |
Great, I knew I forgot something. 
Sorry, only registered users may post in this forum.