Optical endstops
-
Greetings from the Deep South, USA.
New to the forum and recent owner of a brand new Duet Wifi controller.
I am currently connecting all of the printer components to a DIY CoreXY. It is the Hypercube Evolution design posted on Thingiverse.
Up till now I have limited experience with Marlin Firmware. So Reprap is completely new to me.
I have most things sorted out, such as I had a problem with the X and Y direction and axis being reversed. But the wiki help me fix that.
But I am stumped on the endstops.I know it clearly states in the wiki that optical endstops are not recommended because the required operating voltage is in question on most optical style endstops.
I bought the components to build this machine long before I decided on a controller, so optical endstops are what I had on hand when the Duet arrived, and I decided to give it a go.
So far it appears as if the stops are working properly. The LED is lit with no contact, and then goes off when the sensor is tripped.
Performing an M119 command while the sensors are tripped by the installed flags, shows the axes to be at min position, as well as the 'endstop states' in the Duet Web Interface.
And when they are not tripped they show 'not stopped'.Dumb redneck logic states that if the board is seeing those correct statuses, as well as the tell-tale LED lights on the sensors working as they should, then they should send the proper information to the steppers when the axes are homed, But, they are not. I have had to keep a quick finger on the power button when it's realized that the steppers keep turning long after the sensors are tripped. But I am thinking that there must be something more sinister going on, such as maybe the controller looks for something more than what I have mentioned to control the homing, than what the optical sensors are able to produce. Hence the warning in the Wiki.
Am I on to something, or do I not have the configuration configured to configure properly?
I used the reprapconfiguration tool to create a starting point, and since that didn't work I have pretty much butchered up the config.g and Home*.g files with my guesses so much that the printer will probably start vacuuming my floor rather than what it was designed to do, if I were to hit the Print button right now. So I am sure a do-over is in order.
So with that, can any of you fine gentleman suggest something I could do to sort this out? Maybe someone familiar with the Hypercube design that could lead me in the right direction, or a suggestion to just ditch the optical stops and go with switches? Maybe give up 3d Printing altogether and take up Basket Weaving?
I would like to use the optical stops if I can. I have read that they can be used as reliably as switches, plus….they just look cool.
I hope I described everything properly, as I am new to this stuff and haven't learned all the proper jargon yet. Maybe if you read it back to yourself aloud, in a deep southern drawl, while holding a beer it might make more sense.Thanks in advance for any responses.
-
It sounds that your optical endstops are working correctly.
Endstops are only checked during homing moves, which is also what most other firmware do by default.Homing moves are G1 moves with the S1 parameter added. Were you testing regular or homing moves?
After homing, software movement limits are enforced.
-
My 2 pence worth. I have optical endstops on duet at 3.3v. Use tall, wide, black opto flags. I can't remember whether the leds go from on open to off triggered or the other way around, but when they change state it should be quite positive from brightly lit to completely off. If it's a little half hearted the flags aren't optically up to the job.
-
I am also using optical endstops wihout issues on my Duet WiFi with 3.3V, I have printed black flags and so far the switch from on to off (when triggered) was pretty instantaneous
-
Firstly, thanks for the responses.
I have tinkered with it more and I have narrowed down the problem.
Mr. C, you got me thinking with your response.
I have been trying Homeall and it failing. I had yet to try an individual homing of each axis.
Doing each individually equals success.But choosing home all, whichever axis, X or Y that is closest to minimum will arrive, but after closer watch it doesn't seem to be stopping because it sees home, it stops because it has hit its dead end. Then the other axis comes slamming into it and I get the dreaded CLACK CLACK CLACK of the belt slipping.
After reading your wiki on how CoreXY has to home (and if I have understood it correctly), they cannot home simultaneously because of both being driven by both belts. Makes sense. I have trouble walking and chewing gum at the same time,
So again, if I am understanding, and if I am reading the homeall.g config correctly X finds home first then Y follows once it's successful.As an experiment I positioned both X and Y at max and hit homeall. They both head in equally and at the same speed and then crash into each other at the home position. This is when I drive my finger through the power button. That binding noise is like fingernails on a chalkboard to me.
I'm still perusing the wiki for an answer but I wanted to at least give a status update.
-
More info:
The config files match the suggested files in the wiki.
The commands in the homeall.g for each axis match the code in homex and homey.I homed X and Y individually. While they were still parked I hit homeall. Z did it's thing but X and Y didn't budge.
According to the code each axis should have backed up 5mm then went in again. I expected both to do just that and then crash into each other, but again they did not move a bit. So I guess they are seeing home, so to speak. Something is amiss with the code telling Y axis to wait until X has found home. And even stranger, when they are both at home, they don't make a peep.I can find nothing addressing this one….
-
And….I fixed it. It was dumb luck.
I mentioned earlier that the code in the wiki matched the code in the config file.
That wasn't exactly accurate.For instance, here is a line from the configuration file that the reprap tool created:
G1 X-240 Y-240 F3000 S1But the wiki had it as this:
G1 S1 X-240 Y-240 F3000I am assuming the the "S1" and "S0" are TRUE and FALSE respectively.
The original line had that at the end of the line, and the wiki had it at the beginning.
I swapped them and now it works perfectly.I don't know what I did as I am still learning this stuff, but even a blind squirrel bumps into a nut every now and then.
Thank you all for the help.
-
Strange, it doesn't matter where in the line the S parameter occurs, as long as it is not in a comment. Are you sure you didn't change anything else?
-
After posting this, I was perusing other pages of the wiki and saw that the S parameter was the way I originally had it.
SO I kind of figured that it was as I said, dumb luck and not a mistake of the configuration tool.I don't know why it started working, but it did.
All I did was backspace to delete the S Parameter at the beginning, and then retyped it at the end.I hate guessing. I'm not a plug and play guy. I like knowing the how and why. I am sure, as most new guys, I will slowly learn the language and be more knowledgeable as time passes. Everything that I know about electronics to date, has been fixing something that was broken. So this is indeed a learning experience.
I am almost done setting the printer up as we speak. I am currently stumped again with a temperature reading problem but I won't speak of it here, so as to keep the thread on topic.
Thank you for your help.
-
Odd behavior, something else was a miss because I have had the S1 postion mixed throughout and just recently went through and made their position all the same to clean up readability.
-
Came into this thread looking for answers, got one of them and am looking for another. First off, is the "front" on the opposite side of the stepper motors? If I hit Y+10 the carriage moves to that side.. opposite of the motors.. so I think the motors are defined correctly. The issue is when I hit home Y for instance, from either direction, it will only move to about the middle of my 400x400x400 build. I defined it as 400 in the reprap configuration tool. I have a very basic config file right now too. The X doesn't seem to trigger at all after testing M119 on it along with my z axis. appears the only working one is Y at the moment. If I try to home x, it says it failed to home can't home z without doing the others before it. I could use a tiny bit of help with this.. Thanks all
here is the home all code I've got
; Course home X and Y
G1 X-405 Y405 F1800 S1
; Move away from the endstops
G1 X5 Y-5 F6000
; Fine home X and Y
G1 X-405 Y405 F360 S1
Here is endstop from config
; Endstops
M574 X0 Z0 S0 ; Set active low endstops
M574 Y2 S1 ; Set active high endstops
M558 P1 X1 Y0 Z1 H5 F120 T6000 ; Set Z probe type to unmodulated, the axes for which it is used and the dive height + speeds
G31 P600 X0 Y0 Z2.5 ; Set Z probe trigger value, offset and trigger height
M557 X15:385 Y15:385 S20 ; Define mesh grid -
Well I got my other endstops figured out.
-
Well I got my other endstops figured out.
Is it all working now, or do you still need help?
-
One thing with my optical sensors, they were behaving the same way. They do not work for 1.19.2, 1.19.1, but work fine on the 1.18 and 1.18.2.
-
If its any use I didnt notice any change in optical endstop behaviour with any new release.
-
I am going to try upgrading again, but they don't seem to work for me on the higher builds.
-
What type of optical endstops are they? There was a change made around 1.19 to increase the noise margin of the endstop inputs in the low state. Depending on the type of endstop you use (in particular, whether it has an internal pullup resistor) they could affect whether you get a trigger or not, if the triggering was already marginal. The fix would be either:
1. Make sure that the beam is broken completely when the carriage reaches the endstop. If there is still some light getting from one side of the opto switch to the other, that could prevent triggering.
2. Add a pullup resistor between the endstop output and +3.3V. Try 10K.
-
Is it all working now, or do you still need help?
still need help, I forgot about this post with the holidays near and over with, I've got more time to configure my printer. I have changed my config to this. I'm not sure if it's right or wrong.
M574 X0 Z0 S0 ; Set active low endstops
M574 X2 Y2 S1 ; Set active high endstopsand home x
G1 S1 X-400 F6000 ; move quickly to X axis endstop and stop there (first pass)
and lastly home y
G1 S1 Y-400 F6000 ; move quickly to Y axis endstop and stop there (first pass)reason why I have a negative value is that when I do a home as positive value, the carriage moves away from me. x moves to the right and why moves "forward" With a negative value it now hits the flag but after it's home at "400" it wont move… which is obvious as to why. I just couldn't figure out how to make it work otherwise.
-
Try M574 X1 Y1 S1 instead of those 2 lines.
-
Try M574 X1 Y1 S1 instead of those 2 lines.
Fantastic, that worked! I probably would have gotten it eventually just trying other configurations of the M574 command. Thanks again for your help I'm so excited to be one step closer to printing with this build. Next step is to order the zesty.
