shut down due to euclid state
i get an error message when trying to home the printer caused by the euclid: the same as @nanserbe on is post from 06/03/2023:
"Shutdown due to expected probe state to be deployed but is stowed (1)
Once the underlying issue is corrected, use the
"FIRMWARE_RESTART" command to reset the firmware, reload the
config, and restart the host software.
Printer is shutdown"
i tried his solution: modifying the pin to correspond to my wirring (5v probe type) but i still get the error.
on the mecanical aspect of things the printer move flawlessly no skipping step or anything.
if someone know the fix id be happy to know too
81 Replies
If it successfully picks up the probe and you still get that error it is either the wrong pin still or a bad wire.
Is the light on the probe on once it picks it up?
yes the light turn on when it get picked up the wiring got checked and it seems fine it as continuity
i checked my printer.cfg and i removed the " ^ " on the pin and got it to pick up the probe move to the center and the bed went up a bit and then stopped with in the wrong order : "19:15
Endstop z still triggered after retract
19:15
Endstop z still triggered after retract
19:14
probe: open
19:14
probe: TRIGGERED
19:14
Deploying probe
19:14
echo: Homing Z
19:14
G28"
the ^ is important
If it doesn't work with that, you need to check your wiring.
use QUERY_PROBE to check the different states. It should be TRIGGERED when not attached. "open" when attached and "TRIGGERED" when attached and the switch is pressed.
i checked for the 5 time the wiring... still look good to me. i deed this status check on detached attached and triggered with the "pin: ^probe_pin" i got the expected result but still got the same error as mentioned at the top, for me it show to that the wiring is good but i dont know where this can come from now
working on it : to my understanding the macro use a query probe command to assess the probe state before pick up, between the pickup and the probe to check if he had attached it ?
as the state is right : when attached it is open as the other endstop may it be that there is an state error and the macro is looking for a triggered state ?
If you got the results i wrote, then it's probably a config thing, upload your printer.cfg
No, i've been running euclid myself for close to a year
The implementation is 100% stable and working
here is the printer.cfg i am runing
Config is correct, my analysis still point towards wiring issues
I do use mine with this uncommented:
pin: ^probe_pin # For NPN NC probes such as the Super Pinda / Vinda / SupCR / Decoprobe probes. but it shouldn't make a difference.i got signal port to pb7 gnd to gnd and vcc to 5v on the "5v probe port"
yeah i tried wih this line it change nothing at it is writed exactly the same in the included macro
Did you wire it like an inductive probe in the wiring diagram?
yeah
PB7 is on 2 different ports
on the bl touch port
OK
hmm
the j43 to be exact
maybe a solder as gone bad but i think not they are in-cased in hot glue to prevent short and the state check should not work if it was the case
It would if it's a loose connection depending on carriage position
Solder is always a bad idea on moving wires
i mean on the euclid probe itself
what have you soldered on the euclid itself?
the jst connector and the endstop itself
Pretty sure mine came preassembled.
yeah you can have it both way
In that case, have you done it right? Its important the switch is soldered as NC
i learned that later but where i get it from it was the kit only and it is like 5 solder point so it did not frighten me
Right. It's all the feedback i can give you though. The code is fully working and extensively tested.
yeah did it following the euclid online instruction and as said i even glued over the solder to prevent short and absord vibration
This could be the issue actually
There's nothing that should be able to short on the solder points if you did it right
And the glue might cause it to not be able to connect right
If you could show me some pics i can check if everything looks okay
i quote euclid instruction :"It is suggested to insulate the exposed terminals of the top PCB by:
painting clear nail polish or model builder’s enamel
placing a piece of Kapton tape (not included) over the exposed pin"
Fair. That's not a blob of hot glue though
This looks okay, plenty of space there
Yeah ....
Wiring colors are weird here. White would be +5v.
Doesn't mean it's wrong, just worth noting.
ho yeah don't look at that i have respected no sort of logic at all just picked a combination of colored wires different from the rest
👍
+5 is yellow and green gnd
No
The white wire is +5v in your screenshot
yep, white is 5v, green is signal, yellow is gnd
Although you PCB seems to indicate otherwise
This is odd.
this is the one i got this pictured is a screen cap from euclid web site
This is what mine looks like, print is on the other side compared to yours
Can't see the top of course because of the mount
Might be on both sides for all i know
yeah it as also less composants
Wait.. Is yours 24V?
Yeah there's your problem
Wiring diagram is for the 5V version
I don't know why they have a 24V version in the first place, it makes everything significantly more complicated
You can't use this with 5V wiring
they are sold as being able to be plugged as both
Hmm..
yeah in the first place on an old post i had it wired as they said on the pb7 on the 24v side
like a regular endstop
Regular endstops aren't 24V
You would need to use the probe port
The optocoupled probe port..
Which means you'd need a
~ modifierit is written in fix _my_printer : end stop and probe shenanigans
it was on the j40 plug
We might be getting side tracked anyway, if you say the tree states i described are reporting correctly 🤔
yeah
1) It should be TRIGGERED when not attached.
2) "open" when attached
3) "TRIGGERED" when attached and the switch is pressed.
yeah just checked again it work fine
I honestly don't know, unless there's significant latency on it when run in 5V mode
... that may be it i could use a comand to slow down the macro?
Depends on when the error is thrown, does it touch the bed, retract and then throw the error?
no it pick the probe from the rack go back then to the side an then trigger the error
Oh thats quite bad. Can you film it?
yeah 1 sec
There's no way the latency could be that high
You can slow it down with
afterwards
It might not be picked up correctly on thus throw the error
wow this time it tried to probe the bed directly without picking the probe .... may it come that i throw a "SET_CENTER_KINEMATIC_POSITION" before to get the bed down (after trying it multiple time it was quite close from bottoming out
wow this time it tried to probe the bed directly without picking the probeThis is impossible if the state checks we just talked about were reporting correctly
may it come that i throw a "SET_CENTER_KINEMATIC_POSITION" before to get the bed down (after trying it multiple time it was quite close from bottoming outYes, thats why there's a HUGE warning in the console
this time he picked it and go in the middle and :" Endstop z still triggered after retract"
Video?
That error means it's triggered as soon as it starts to dive
Ie, the state isn't reporting correctly
You should try QUERY_ENDSTOP right after the error
Okay THAT is really concerning
It triggers in mid air
The bed is going upwards, probe randomly triggers before it touches the switch
Something about the movement on your bed is causing the switch to report as triggered (this would be an electronic problem)
Or you just have a super loose connection that is completely unreliable
I would bust out the multimeter and look if there's continuity between gnd and signal, when there's continuity it would report as "open", no continuity would report as "triggered". If the multimeter is intermittently beeping (ie, no consistently off or on), that's a loose connection.
the more we test the more i think so but the plugs dont move on ether side i will try de pin them and do them again maybe
ok will try it is already on the desk
gnd to signal?
Yes, the signal is pulled to gnd when the circuit is closed.
the
^ is enabling an internal pullup, which means when the circuit is broken the signal is "floating" and pulled HIGH by the pullup.
And since this is a normally closed circuit, the default state ("open") would mean a connection between signal and gnd.so i need to check when manualy triggered
It's enough just having it attached
without triggering it
The multimeter should beep
With no interruptions
When you then press the switch the multimeter should stop beeping
If the multimeter stops beeping without the switch being triggered, there's a problem
Try wiggling wires around while monitoring the "beep".
yeah bad plug it is i think it beep depending on how the plug is turned
that odd the dupon look good
dupont's can be fiddly
yeah not the best clearly but anyway gonna redo the crimp and all should be good thx a lot
re-crimped signal wire and works like a charm hoooo this feel goood
Excellent 🙂
dependent-tan•12mo ago
you can. the 5V/24V difference is only the MAXIMUM voltage you can put through the unit. it works witrh BOTH 5V and 24V subsystems.
https://euclidprobe.github.io/00-voltage.html
Euclid Probe Voltages | Euclid Probe the highly accurate detachable...
What is the difference in voltage versions?
dependent-tan•12mo ago
the biggest issue that we get help requests are for the optocoupler on the controllers. Most are not able to sink ANY current, that is why we recommend to run Euclid to endstop ports.
@miklschmidt you were supposed to have been sent a real Euclid kit. That one in th epics has the wrong silks and LED's.
Yeah i found that out later 😄
Yeah this is the reason RatOS doesn't use those by default. We opt for the bltouch port, but same same 🙂
It's the only one i ever got, i think i got it from RR. I don't remember.