RADDS work now stable with RepRap Firmware

Looks like the problem is solved. Listing the files with the example application worked OK. A further deep dive with my DSO learned that the CD signal was weird caused by the switch on the SD slot being bent a bit. Repairing this solved the issue. (the example application does not use the CD signal, hence was able to read the SD card).

What I did notice btw is a missing pull-up. The signal level is somewhere halfway. Looks like the internal pull-up is not activated by RRF. Adding manually a 10K resistor created a nice HIGH/LOW.

With this solved I can continue with RRF configuration.

Edited 1 time(s). Last edit at 07/05/2016 07:02AM by turboproc.

Being able to move forward I'm stuck in de proces of configuring RRF. Particularly, the homing configuration seems a little struggle. Using the standard X-axis homing file (Z-axis up, home X, Z-axis down), the result is Home X, Z-axis down. Debuggging works so a small report is provided below:

serial: G28 X0
serial: M114
macro: G91
macro: G1 Z4 F200
macro: G1 X-300 F3000 S1
DDA: start=[10.000000 0.000000 50.000000] end=[10.000000 0.000000 54.000000] d=4.000000 vec=[0.000000 0.000000 1.000000 0.000000 0.000000]
a=15.000000 reqv=3.333333 topv=3.333333 startv=0.000000 endv=nan
daccel=0.370370 ddecel=nan cks=0
DMx: not moving
DMy: not moving
DMz: not moving

Following the debugging output, it is clear that the Z-axis will not move (but why?). The concluding Z-axis lift provides a better result:

macro: G1 Z-4 F200
macro: G90
DDA: start=[0.000000 0.000000 54.000000] end=[0.000000 0.000000 50.000000] d=4.000000 vec=[0.000000 0.000000 -1.000000 0.000000 0.000000]
a=15.000000 reqv=3.333333 topv=3.333333 startv=0.000000 endv=0.000000
daccel=0.370370 ddecel=0.370370 cks=3733333
DMx: not moving
DMy: not moving
DMz: dir=B steps=5120 next=1 interval=26791 sstcda=0 acmadtcdts=291666 tstcdapdsc=3733332 2dtstc2diva=3674999678553
accelStopStep=475 decelStartStep=4646 revStartStep=5121 nextStep=1 nextStepTime=26791 2CsqtMmPerStepDivA=717773440
 mmPerStepTimesCdivtopSpeed=629999 fmsdmtstdca2=0

Main difference here is that the end speed (endv) does have a value in this case where it didn't in the first case.

Any clues?

Quote
turboproc
What I did notice btw is a missing pull-up. The signal level is somewhere halfway. Looks like the internal pull-up is not activated by RRF. Adding manually a 10K resistor created a nice HIGH/LOW.

That doesn't surprise me. The Duet has an external pullup resistor on the card detect pin, so the firmware doesn't need to turn on the internal pullup resistor in that build.

---

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
turboproc
Being able to move forward I'm stuck in de proces of configuring RRF. Particularly, the homing configuration seems a little struggle. Using the standard X-axis homing file (Z-axis up, home X, Z-axis down), the result is Home X, Z-axis down. Debuggging works so a small report is provided below:

serial: G28 X0
serial: M114
macro: G91
macro: G1 Z4 F200
macro: G1 X-300 F3000 S1
DDA: start=[10.000000 0.000000 50.000000] end=[10.000000 0.000000 54.000000] d=4.000000 vec=[0.000000 0.000000 1.000000 0.000000 0.000000]
a=15.000000 reqv=3.333333 topv=3.333333 startv=0.000000 endv=nan
daccel=0.370370 ddecel=nan cks=0
DMx: not moving
DMy: not moving
DMz: not moving

Following the debugging output, it is clear that the Z-axis will not move (but why?). The concluding Z-axis lift provides a better result:

macro: G1 Z-4 F200
macro: G90
DDA: start=[0.000000 0.000000 54.000000] end=[0.000000 0.000000 50.000000] d=4.000000 vec=[0.000000 0.000000 -1.000000 0.000000 0.000000]
a=15.000000 reqv=3.333333 topv=3.333333 startv=0.000000 endv=0.000000
daccel=0.370370 ddecel=0.370370 cks=3733333
DMx: not moving
DMy: not moving
DMz: dir=B steps=5120 next=1 interval=26791 sstcda=0 acmadtcdts=291666 tstcdapdsc=3733332 2dtstc2diva=3674999678553
accelStopStep=475 decelStartStep=4646 revStartStep=5121 nextStep=1 nextStepTime=26791 2CsqtMmPerStepDivA=717773440
 mmPerStepTimesCdivtopSpeed=629999 fmsdmtstdca2=0

Main difference here is that the end speed (endv) does have a value in this case where it didn't in the first case.

Any clues?

That's not a problem I have ever seen before. I'll take a look at the code and work out how the end speed can get calculated as nan. Do you have any bed compensation configured?

---

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

Quote
turboproc
What I did notice btw is a missing pull-up. The signal level is somewhere halfway. Looks like the internal pull-up is not activated by RRF. Adding manually a 10K resistor created a nice HIGH/LOW.

That doesn't surprise me. The Duet has an external pullup resistor on the card detect pin, so the firmware doesn't need to turn on the internal pullup resistor in that build.

The older, Atmel ASF code used for RADDS SD before CoreDuet/CoreNG used to enable the internal pullup. In the code re-arrangement, it's possible that the #define which made that possible got lost in the shuffle somehow. I'll check when I next get a chance.

I checked, the code is initializing the SD Detect pin's internal pullup.

Elmo_C got a graphic lcd working on a duet with RRF firmware , off course he using some kind of serial adaptor but since we already have the lcd pinout expose is there a easy way to port his software work into the radds using the ldc pin we have ? Replacing his serial connection with the LCD pin directly on the Due? it is only a replacing the pinout in the firmware or its go further then that?

Having an cheap LCD alternative will be great... not all of us want to spend 100$ for a paneldue

May this helps in resolving this. When I insert an M400 command after the Z-lift but before the X-moves, it works as expect. Is it possible that the X-move in the queue affects the Z-move command executed before? Current homex.g is as below:

G91
G1 Z4 F200
M400
G1 X-300 F3000 S1
G1 X4 F600
G1 X-10 S1
G1 Z-4 F200
G90

---

Prusa I3 | E3D hotend | RAMPS 1.4 | Printing PLA directly on glass
Eustathios | E3D Volcano hotend | RADDS 1.5 / Arduino Due | Printing PLA directly on glass

Quote
GroupB
Elmo_C got a graphic lcd working on a duet with RRF firmware , off course he using some kind of serial adaptor but since we already have the lcd pinout expose is there a easy way to port his software work into the radds using the ldc pin we have ? Replacing his serial connection with the LCD pin directly on the Due? it is only a replacing the pinout in the firmware or its go further then that?

Having an cheap LCD alternative will be great... not all of us want to spend 100$ for a paneldue

I think it will be easier for the people to forget Repetier and switch to RRF...

My LCD is ready to test a solution !!!

I'm having the weirdest problems when it comes to homing my bot: This happened occasionally (seemingly randomly) back on 1.09, but has increased in frequency with 1.13, and I finally have a complete repro case:

My machine homes, and it smashes the X-axis into the side of the machine. Info:

When a print starts, it sends
G28
to home everything. That works. No smashing. I can enter this whenever I want successfully, in gcode, or via the serial monitor before a print starts, or after. Solid.

When the print ends, part of the ending script does:
G28 X0 Y0
That will smash it on X every time. Plus, if I just turn on the printer and enter that, it'll smash. So I thought maybe something is wrong with my homex.g:

; homex.g
G91                 ; relative mode
G1 X-330 F3000 S1   ; course home X
G1 X4 F600          ; Move x away from endstop
G1 X-10 S1          ; fine home X
G90                 ; back to absolute mode
G92 X0              ; zero X

It's the same macro I used back on 1.09 though. So I started executing those lines one at a time, and I found the culprint
When I do the 'G1 X-330 F3000 S1', the "S1" isn't being respected. That's what's causing the smash: It just drives it into the side of the bot.

I thought well, if G28 calls homeall.g (right?), and G28 works, why? This is the top of that macro:

G91                        ; relative mode
G1 S1 X-330 Y-330 F3000    ; course home X or Y 
...

So I enter that in line by line, and I get the same smash.

Now for the kicker: I turned my board on\of probably 20 time testing this, restarting S3D as well. Just before I went to send this, I tried one last time and.... now it's behaving correctly. Everything homes, one axis at a time or not, either via buttons in S3D or via the commands themselves. And this is why I've been going bonkers, is that it's random like this. It seems like 1/5 prints it just starts behaving this way.

So any thoughts on the matter are greatly appreciated, thanks!

To follow up, I did another print, and the bug came right back again: I turned off the homing in my 'end script', so when the print finishes the toolhead stops in place (I drop the build plate by 5mm, that's it). Then while still connected to the serial monitor I do the :
G28 X0 Y0
and immediately smash the X-axis.

I tried copying the gcode to the SD and printed it that way (with the G28 X0 Y0 present in my ending code) and it smashed it too. I thought this may be somehow related to S3D, but if it shows up printing off the SD card, I'm starting to rule it out.

I dont know if its important but in s3d are you build volume and offset are right ? also when creating a process make sure its alright there too..

Probably straight forward for cartesian but build volume for delta its weird in simplify you need to use Diameter X 0.707, that give the radius of the number you need to enter

is slic3r is doing the same ?

Quote
AK_Eric
I'm having the weirdest problems when it comes to homing my bot: This happened occasionally (seemingly randomly) back on 1.09, but has increased in frequency with 1.13, and I finally have a complete repro case:

My machine homes, and it smashes the X-axis into the side of the machine. Info:

When a print starts, it sends
G28
to home everything. That works. No smashing. I can enter this whenever I want successfully, in gcode, or via the serial monitor before a print starts, or after. Solid.

When the print ends, part of the ending script does:
G28 X0 Y0
That will smash it on X every time. Plus, if I just turn on the printer and enter that, it'll smash. So I thought maybe something is wrong with my homex.g:

; homex.g
G91                 ; relative mode
G1 X-330 F3000 S1   ; course home X
G1 X4 F600          ; Move x away from endstop
G1 X-10 S1          ; fine home X
G90                 ; back to absolute mode
G92 X0              ; zero X

It's the same macro I used back on 1.09 though. So I started executing those lines one at a time, and I found the culprint
When I do the 'G1 X-330 F3000 S1', the "S1" isn't being respected. That's what's causing the smash: It just drives it into the side of the bot.

I thought well, if G28 calls homeall.g (right?), and G28 works, why? This is the top of that macro:

G91                        ; relative mode
G1 S1 X-330 Y-330 F3000    ; course home X or Y 
...

So I enter that in line by line, and I get the same smash.

Now for the kicker: I turned my board on\of probably 20 time testing this, restarting S3D as well. Just before I went to send this, I tried one last time and.... now it's behaving correctly. Everything homes, one axis at a time or not, either via buttons in S3D or via the commands themselves. And this is why I've been going bonkers, is that it's random like this. It seems like 1/5 prints it just starts behaving this way.

So any thoughts on the matter are greatly appreciated, thanks!

1. Are you using normally-open or normally-closed endstop switches? Or some sort of opto or hall endstop? If you are using normally open endstop switches then the problem could be as simple as a bad X endstop switch connection.

2. Is it definite that the X endstop switch will always be activated before the carriage hits the mechanical stop? I've seen designs in which the carriage only just pushes against the edge of the microswitch lever, and if the carriage alignment changes a little it misses the lever altogether.

---

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
turboproc
May this helps in resolving this. When I insert an M400 command after the Z-lift but before the X-moves, it works as expect. Is it possible that the X-move in the queue affects the Z-move command executed before? Current homex.g is as below:

G91
G1 Z4 F200
M400
G1 X-300 F3000 S1
G1 X4 F600
G1 X-10 S1
G1 Z-4 F200
G90

Thanks. Maybe you missed the question at the end of my previous post, which was: Do you have any bed compensation configured? Or orthogonal axis compensation (I just added that bit)?

Edited 3 time(s). Last edit at 07/07/2016 04:33AM 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].

Hi,

indeed missed your question at the end. Below is a complete copy of config.g. No compensation included (as far as I understand). Shouldn't be necessary in a very rigid and square Eustathios.

; Eutathios config file for dc42 Duet firmware on RADDS

; Prologue and  comms section
M111 S7                             ; Debug off
M550 PEustathios			        ; Machine name (can be anything you like)
M551 Preprap                        ; Machine password
;*** If you have more than one Duet on your network, they must all have different MAC addresses, so change the last digits
M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xED ; MAC Address
;*** Adjust the IP address and gateway in the following 2 lines to suit your network
M552 P0.0.0.0						; IP address (0 = use DHCP)
M554 P192.168.1.1                   ; Gateway
M553 P255.255.255.0                 ; Netmask
M555 P2                             ; Set output to look like Marlin
M575 P1 B57600 S1					; Comms parameters for PanelDue

; Movement section
M569 P0 S0                          ; Drive 0 goes forwards (change to S0 to reverse it)
M569 P1 S0                          ; Drive 1 goes forwards
M569 P2 S0                          ; Drive 2 goes forwards
M569 P3 S1                          ; Drive 3 goes forwards
M569 P4 S1                          ; Drive 4 goes forwards
M574 X1 Y1 Z1 S0					; set endstop configuration (X and Y endstops only, at low end, active high)
;M906 X800 Y800 Z800 E1000           ; Set motor currents (mA)
M201 X800 Y800 Z15 E1000            ; Accelerations (mm/s^2)
M203 X12000 Y12000 Z1200 E3600         ; Maximum speeds (mm/min)
M566 X0 Y0 Z0 E0                    ; Minimum speeds mm/minute
M208 X260 Y260 Z260					; set axis maxima (adjust to suit your machine)
M208 X0 Y0 Z0 S1					; set axis minimum (adjust to make X=0 and Y=0 the edge of the bed)
M92 X160 Y160 Z1280					; Set axis steps/mm
M92 E744                         	; Set extruder steps per mm
G21                                 ; Work in millimetres
G90                                 ; Send absolute coordinates...
M83                                 ; ...but relative extruder moves

; Z probe section
;M558 P1 X0 Y0 Z1 H3 F200 T5000		; Smart IR Z probe, used for homing Z axis, dive height 3mm, probe speed 200mm/min, travel speed 5000mm/min
;G31 X11.0 Y0.5 Z1.20 P500           ; Set the probe height and threshold (put your own values here)

; Heater and thermistor section
;*** If you have a Duet board with 1K thermistor series resistors, change R4700 to R1000 to the following M305 commands
M305 P0 T100000 R4700 B4388 H0 L0		; Put your own H and/or L values here to set the bed thermistor ADC correction
M305 P1 T100000 R4700 B4388 H0 L0		; Put your own H and/or L values here to set the first nozzle thermistor ADC correction
;M305 P2 R4700 H0 L0					; Put your own H and/or L values here to set the second nozzle thermistor ADC correction
M301 H1 P38.01 I5.1 D79.40 T0.50 S1.0 W248 B30	; PID settings for extruder 0
;M301 H2 P10 I0.10 D100 T0.50 S1.0	; PID settings for extruder 1
M570 S120							; Increase to allow extra heating time if needed

; Tool definition section
M563 P0 D0 H1                       ; Define tool 0 to use extruder drive 0 and heater 1
G10 P0 S0 R0                        ; Set tool 0 operating and standby temperatures
;*** If you have a dual-nozzle build, un-comment the following 2 lines
;M563 P1 D1 H2                      ; Define tool 1
;G10 P1 S0 R0                       ; Set tool 1 operating and standby temperatures

; Bed probe section (not needed if you use a bed.g file)
;*** Adjust the XY coordinates in the following M557 commands to suit your build and the position of your Z probe
;M557 P0 X60 Y0                      ; Four... 
;M557 P1 X60 Y165                    ; ...probe points...
;M557 P2 X200 Y165                   ; ...for bed...
;M557 P3 X200 Y0                     ; ...levelling
;M557 P4 X141 Y82.5                 ; 5th probe point for levelling (un-comment this to get a 5th point at the centre of the bed)

; Epilogue
;*** If you are using axis compensation, put the figures in the following command
;M556 S78 X0 Y0 Z0                   ; Axis compensation here
T0									; select first hot end

Just let me know whether you need any further info. Running 1.14-RADDS.

---

Prusa I3 | E3D hotend | RAMPS 1.4 | Printing PLA directly on glass
Eustathios | E3D Volcano hotend | RADDS 1.5 / Arduino Due | Printing PLA directly on glass

@GroupB : My bot is core-xy, and the build volume and offsets are correct in S3D. Same settings I've used in there for Marlin, Repetier, and now RRF.

@DC42 : My endstops are 'normally open' microswitches: If I depress the X-endstop and enter a M119 I get

SENT: M119
READ: Endstops - X: at min stop, Y: not stopped, Z: not stopped, Z probe: not stopped

And the endstop is definitely hit before anything else.

@truboproc : My config.g looks very similar.

M111 S0								; Debug off
M550 Pavey's C-Bot					; Machine name
M555 P2								; Set output to look like Marlin
G21									; Work in millimetres
G90									; Send absolute coordinates...
M83									; ...but relative extruder moves
; Machine configuration
M569 P0 S1 							; X - Drive 0 goes forwards 
M569 P1 S0 							; Y - Drive 1 goes reversed
M569 P2 S1 							; Z - Drive 2 goes forwards
M569 P3 S1 							; E1 - Drive 3 goes forwards
M574 X1 Y1 Z1 S0					; Endstop configuration: XYZ are all min, and send LOW sig when closed.
M667 S1								; Set CoreXY mode
M201 X3000 Y3000 Z100 E4000			; Maximum accelerations (mm/s^2)
M566 X600 Y600 Z30 E420				; Maximum jerk in mm/min
M203 12000 12000 Z300 E9000		    ; Maximum travel speeds in mm/min : 12000=200mm/sec, 9000 = 150mm/sec, 300 = 5mm/sec
M208 X305 Y305 Z520					; set axis maxima (adjust to suit your machine)
;M208 X0 Y0 Z0 S1					; set axis minima (adjust to make X=0 and Y=0 the edges of the bed)
M92 X99.8715 Y100.271 Z402.455		; set axis steps/mm, 1/16 microstepping. 1/32: X199.743 Y200.542 Z804.91
; Tool1 (P0) definition
M563 P0 D0 H1						; D0 = Extruder stepper 1. H1 = First extruder heater. 
M92 E162.5							; Set extruder steps per mm, 1/16 microstepping 
; Thermistors and heaters
M305 P0 T100000 R4700 				; Bed thermistor
M305 P1 T100000 R4700 B4267			; E3D thermistor has beta value 4267
; FANS								; Before setting P0 theromstatic (H1), P1 would auto-turn on during boot.
M106 P0 T60 H1                      ; Enable the auto hotend cooling fan to kick on at 60c.  
M106 P1 H-1							; Must do H-1, or it'll turn on with P0 for some reason.
M106 P1 S0 							; Must do, or P1 will go full blast on start 
M18                                 ; Disable stepper motors
T0  							  	; select first hot end

So, it's the morning: I power my bot on and issue:
G28 X0 Y0
And it works just fine, as expected. But, if I start a print, if I execute that at the end of my print in gcode, or if I execute that over a serial connection at the end of a print, it'll smash.
Below is the header and the footer of the gcode that causes it, if anyone can spot a problem?

G90
M83
M106 P1 S0 
M140 S60
M104 S230 T0
G92 Z0 E0                                    ; Set current z position to zero.
G1 Z5                                           ; Lower Z to be safe 5mm.
G28                                              ; Safe Homing of All Axes.
G1 E50 F600                                ; Purge nozzle 50mm 10mm sec When a print ends it's retracted by 30mm.
G92 E0                                         ; zero extruder
G1 X0 Y10                                    ; Move nozzle to left front corner of build platform.  
G92 X0 Y0                                    ; Zero X & Y here to start the build.
G1 E-1.5000 F5400
G1 Z0.300 F300
; layer 1, Z = 0.3
M105
M105
T0

And the end part:

; layer end
G92 Z0                       ; Set current z position to zero.
G1 E-10 F1800           ; Retract 10mm at 30 mm/sec of filament to clean the nozzle.
G1 Z5                         ; Lower Z to be safe 5mm.
M106 P1 S0                ; turn off filament cooler fan
M104 S0                     ; turn off extruder
M140 S0                     ; turn off bed
G28  X0 Y0                 ; Home XY - SMASH!!!!!!!!!!!!!!!!
M84                            ; disable motors

Hi everyone,

My RAPS128 are now in the printer. I've switched to 1.14 firmware.
Can someone explain how to specify forward /backward and to invert the signal with the new M584 command ?

Thanks.

Edit : M569 command still works on RADDS...

Edited 2 time(s). Last edit at 07/07/2016 02:02PM by shofman.

Quote
shofman
Hi everyone,

My RAPS128 are now in the printer. I've switched to 1.14 firmware.
Can someone explain how to specify forward /backward and to invert the signal with the new M584 command ?

Thanks.

Edit : M569 command still works on RADDS...

I have not myself used M584 yet. FWIW, here's my RADDS RRF config which I use with RAPS128 drivers.

M111 S0                             ; Debug off
M550 PCoreXY				        ; Machine name (can be anything you like)

M555 P2                             ; Set output to look like Marlin
G21                                 ; Work in millimeters
G90                                 ; Send absolute coordinates...
M83                                 ; ...but relative extruder moves

; Machine configuration
M569 P0 S1 R1						; Drive 0 goes forwards; inverted enable
M569 P1 S0 R1						; Drive 1 goes backwards; inverted enable
M569 P2 S0 R1						; Drive 2 goes backwards; inverted enable
M569 P3 S1 R1						; Drive 3 goes forwards; inverted enable
M569 P4 S1 R1						; Drive 4 goes forwards; inverted enable
M569 P5 S1 R1						; Drive 5 goes forwards; inverted enable

M574 X2 Y2 Z1 S0					; set endstop configuration (X and Y and endstops only, at low end, active high)
M667 S1								; set CoreXY mode
M92 X88.88889 Y88.88889 Z400 E96.27520187 ; Set steps/mm
M201 X800 Y800 Z15 E1000            ; Accelerations (mm/s^2)
M203 X15000 Y15000 Z100 E3600       ; Maximum speeds (mm/min)
M566 X600 Y600 Z30 E20              ; Maximum jerk speeds mm/minute
M208 X100 Y100 Z2000				; set axis maxima (adjust to suit your machine)
M208 X-100 Y-100 Z-0.5 S1			; set axis minima (adjust to make X=0 and Y=0 the edges of the bed)

; Tool definition
M563 P0 D0 H1                       ; Define tool 0
G10 P0 S0 R0                        ; Set tool 0 operating and standby temperatures

; Thermistors and heaters
M305 P0 T100000 R4700 B4066 H0 L0
M305 P1 T100000 R4700 B4066 H0 L0

;*** Heaters off
M104 S0 T0
M140 S0

;*** If you are using axis compensation, put the figures in the following command
M556 S78 X0 Y0 Z0                   ; Axis compensation here
M18                                 ; Disable stepper motors
T0									; select first hot end

Thanks Dnewman... I will stay with M569 because it just works.

About the RAPS128 : is there any interest to use 1/64 or 1/128 configuration ?
My motors are : 17HS16-2004S

Quote
shofman
Thanks Dnewman... I will stay with M569 because it just works.

About the RAPS128 : is there any interest to use 1/64 or 1/128 configuration ?
My motors are : 17HS16-2004S

M569 still sets forward/backwards and the polarity of the enable signal. It's just the driver mapping that's moved to M584.

---

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
AK_Eric
@DC42 : My endstops are 'normally open' microswitches

That is a bad idea for repraps in general. I suggest you change the wiring to use the normally closed contacts instead (the outer 2 contacts of the switch), and change S0 to S1 in your M584 command. Also check for a bad connection in the X endstop wiring.

---

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

Quote
AK_Eric
@DC42 : My endstops are 'normally open' microswitches

That is a bad idea for repraps in general. I suggest you change the wiring to use the normally closed contacts instead (the outer 2 contacts of the switch), and change S0 to S1 in your M584 command. Also check for a bad connection in the X endstop wiring.

Just wondering, but why is N/O bad? But I can give rewiring them a shot.

You mention the M584: I'm not using that in any of my config, I'm using M574 to setup my endstops: Were you referring to another post above, or saying I should use that command, or was that a code mistake? I'm looking at the docs for it:
[reprap.org]
And not really understanding why I'd want this for my endstops?

Since everything works before a print starts, but not after, this seems like a config issue, since M119 correctly detects if the switch is depressed or not. I'll keep troubleshooting. And thanks!

N/O means, with a broken wire it won't stop ...

---

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]

Quote
VDX
N/O means, with a broken wire it won't stop ...

HA, once it's spelled out it makes a lot more sense, thanks

Quote
VDX
N/O means, with a broken wire it won't stop ...

N/O also means that capacitive coupling to the switch wires can cause premature triggering. With N/C switches, you need inductive coupling to cause premature triggering - but inductive coupling is easier to control than capacitive coupling in this instance.

---

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

Quote
shofman
Thanks Dnewman... I will stay with M569 because it just works.

About the RAPS128 : is there any interest to use 1/64 or 1/128 configuration ?
My motors are : 17HS16-2004S

M569 still sets forward/backwards and the polarity of the enable signal. It's just the driver mapping that's moved to M584.

DC42, can you send your config file please ?

Quote
shofman

Quote
dc42

Quote
shofman
Thanks Dnewman... I will stay with M569 because it just works.

About the RAPS128 : is there any interest to use 1/64 or 1/128 configuration ?
My motors are : 17HS16-2004S

M569 still sets forward/backwards and the polarity of the enable signal. It's just the driver mapping that's moved to M584.

DC42, can you send your config file please ?

Config file for what? I don't have a printer with RADDS electronics, I have an Ormerod controlled by a Duet and a Kossel controlled by a Duet WiFi.

---

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

Your config.g for the kossel please

Quote
shofman
Your config.g for the kossel please

It's fairly close to the one here [github.com], just a few changes for the Duet WiFi and to enable pressure advance.

---

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

Ok thanks.

About steppers : is there any interest to use 1/64, 1/128 or 1/256 configuration ?
My motors are : 17HS16-2004S