You are not logged in.

#1 2018-11-25 01:36:57

myk68
Member
Registered: 2017-09-15
Posts: 25

endstop woe's once more

Hi

So I made the mistake of 'improving' my build.  never never never again.

I have it up and running again but not the endstops.  they will not recognise either way.

I'm using red mechanical endstops. like these
https://www.amazon.co.uk/dp/B071J2RSY7/ … 4442658923

I have had them working before and think I had the same issue.

I have 5v going in to them from the Pi

OH yes this is all direct no ramp board

the green signal wire is linking currently to pin 11 and 31. been trying different pins.
this wire is live with 5v when open and zero when pressed.
if the state is low then Z moves but doesn't stop when the endstop is pressed
if High then nothing moves, pressed or not.  If I only have the top one active then down is fine, up -- nothing.

any ideas  please

can I reverse the wires gnd to 5v to have 0 open and 5v presssed.  could that be it??

Help anyone!!!

Mike

Offline

#2 2018-11-25 04:31:49

bigfilsing
Member
Registered: 2016-11-20
Posts: 306

Re: endstop woe's once more

Hi Mike
These mech endstops can be confusing as there are a couple of different types ( that look very similar)
In my experience, the 5VDC supply to the endstop switches is purely for the indicator LEDs So initially I would recommend disconnecting the 5VDC, in order to focus on the issue better. The endstops are passive devices so don't need power to function
So I'm posting without any direct experience of the problem you have but hope to set you on the path to a solution

Please bear in mind i have never used a Pi directly but I have a feeling your suffering from similar issues that I have had with other control boards.
From the switches,  ( only 3 pins of the 4 pin plugs populated) you should have the black wire pin and the green wire pin as your signal pins and these are NO ( normally open) and they close when the switch is pressed. You can test this with a multimeter set to continuity

Based on that the black wire should be attached to Pi GND and the green signal wire to an input pin on the pi.
The essence of the issue is that the Pi will look for the pin being pulled to GND  or going low as it often referred to.

So the first thing to check is what is the Pi expecting as a signal. Are pins 11 & 31 "high-5VDC" and expecting to be pulled "low 0VDC" or is it "low" and expecting to be pulled "high"
Good luck

Last edited by bigfilsing (2018-11-25 07:25:28)

Offline

#3 2018-11-25 18:03:26

myk68
Member
Registered: 2017-09-15
Posts: 25

Re: endstop woe's once more

Hi bigfilsing

cheers for the help. So I've removed the 5vdc

top endstop only set to  pin 7
endstop state  high

if tripped on start up then will go down but not up
if not tripped on start up then will not move up or down

does this make any sense

Offline

#4 2018-11-26 01:35:22

bigfilsing
Member
Registered: 2016-11-20
Posts: 306

Re: endstop woe's once more

Hi Mike
Like I said, I don't have any experience running a printer directly from a Pi.
It sounds to me like the symptoms you'd get with an FDM printer running Marlin firmware, where at startup it first needs to home the axis before any movement is allowed. At start up the firmware/OS has no idea where the axis is position-wise, so it needs to home first (Z0) to have a reference.
I think its safe to say that the top end stop will function in the same way as the lower ( high and gets pulled low or the other way round) added to which a lot of printers don't have a max endstop ( DLP& FDM) Max Z travel can be configured in NanoDLP which kind of negates needing a MAX endstop. Nothing wrong in having one thou, just to be safe.
For now, id disconnect the max endstop completely and focus on the min ( Z0) endstop.

If, as i suspect the "home before any movement" is valid then, after disconnecting the Z max endstop, try switching on you printer and pressing "home". 
Id expect 1 of 3 results
a It moves in the correct direction and stops when the Z min is triggered
b It moves in the wrong direction and so will never trigger the endstop. in which case, you'll need to reverse the direction of the stepper
c It doesn't move at all, which would suggest the Z min is already triggered. It should allow positive movement in the Z positive direction
Let me know how you get on.
Cheers
Phil

Last edited by bigfilsing (2018-11-26 01:38:53)

Offline

#5 2018-11-26 02:07:45

bigfilsing
Member
Registered: 2016-11-20
Posts: 306

Re: endstop woe's once more

Mike
I've just taken a look at the direct connection hardware schematic ( https://www.nanodlp.com/download/schematic.png) and that indicates only a Z0 endstop .
Its held high by a 100K resistor to 5VDC/pin 8(LIMIT) then gets pulled low to GND by the endstop switch.

If not this then what is your wiring set up ?? Do you have an add-on board for the stepper driver?

Offline

#6 2018-11-30 09:53:21

myk68
Member
Registered: 2017-09-15
Posts: 25

Re: endstop woe's once more

Hi

no I dont have a board. its all been direct wiring to the pi.  worked before I 'improved' it lol

Ive tried it now with a 10K resistor and still the same.    nothing. 

Is there a way to test the Pi pins, could I have shorted some and their not working??



Thinking to get the bits and make the board that tinkering on steroids made, looks the same as the schematic on the nano site.  Or I could give in and buy the many off banggood and the like.

Offline

#7 2018-11-30 15:05:33

bigfilsing
Member
Registered: 2016-11-20
Posts: 306

Re: endstop woe's once more

myk68 wrote:

Hi

Is there a way to test the Pi pins, could I have shorted some and their not working??

you should be able to hook up an LED with a suitably sized current limit resistor then figure out how to drive / read the pins

This YT tutorial looks like it does exactly that .....https://www.youtube.com/watch?v=BWYy3qZ315U

Things to check
are you absolutely sure you are using the correct pins ?
have you confirmed whether the input pins are low and need to be pulled hi by the endstop switch or they are high and need to be pulled low

Offline

Board footer

Powered by FluxBB