jca34f, because the encoder is spring loaded to the rack in a rack & pinion system it would
also be a good long lasting fit to neketege88's project. but, both the encoder wheel and the
rack & pinion system share the same limitations, if anything gets between the encoder and the
rack it changes the linear displacement value.
about the same time as the basic stamp hit the consumer market(@1989) Sony's industrial unit
started selling the magnetic tape linear scale, because it was non-contact(no long term wear),
and if saw dust collected on the scale surface it did not change the displacement values because
wood is non-ferrous. the wood industries fell in love with them.
@TommySr:
Yes i've worked with those before, accurate and rugged in an indoor environment, outdoors, I would worry about rain, condensing humidity, etc. Rack and pinion can be covered with a slot with rubber lips for the encoder shaft to pass thru.
Didn’t get a chance to play with the mill this weekend like I’d hoped. Kids baseball and a 400’ of water line for garden took up all my time. I will be getting back to it soon though.
JCA34F:
Something like reply #176?
I didn’t really understand what you meant in this post, but I think I have a better idea now. However, I don’t see an easy way to fasten it to the setup I have.
Looks to me like there would need to be a solid (stationary) piece to run from top to bottom of the mill outside the existing frame for the pinion to ride on when the head travels up and down.
Maybe I’m looking at it wrong. Do you have something in mind ?
Edit: the glass scale DRO seems like it would have to be attached the same way to me. I just don’t see a good way to attach it to the mill.
the glass scale DRO seems like it would have to be attached the same way to me.
while this image is not your application, it does have the same installation setup
, and is the same for both linear scale, and rack & pinion DRO installation
neketege88, the wheel encoder is by far the simplest to install on your setup(and the cost is sweet)
Looking at this wheeled encoder, It is hard for me to understand what i'm getting. options are 8-24pnp, 5v-voltage, 8-24 NPN. I would assume I want the NPN?? but it needs to be 5v correct?
Also, they contain 5- 8 wires .... Not sure what they are all for. They are listed as:
red = VCC Black = 0V Green = A White =B Yellow = Z Brown =A, Grey =B Orange = Z
I got vcc and ground lol after that i'm confused. Does it have two output wires for you to be able to ultimately tell whether movement of the wheel is clockwise or counterclockwise? If thats true what are all the other wires for? Do I need them?
Encoders usually provide at least three signals: A, B and Z. Some, such as this one also give you -A, -B and -Z which are just the inverse of the first three - you don't need them.
A and B tell you when the encoder is turning and which way. Z indicates a zero point or index position. For your purposes, I would expect A and B to be all you need.
wildbill:
Encoders usually provide at least three signals: A, B and Z. Some, such as this one also give you -A, -B and -Z which are just the inverse of the first three - you don't need them.
A and B tell you when the encoder is turning and which way. Z indicates a zero point or index position. For your purposes, I would expect A and B to be all you need.
And I would need the 5v one? And does it matter NPN or PNP?
neketege88:
Looking at this wheeled encoder, It is hard for me to understand what i'm getting. options are 8-24pnp, 5v-voltage, 8-24 NPN. I would assume I want the NPN?? but it needs to be 5v correct?
Also, they contain 5- 8 wires .... Not sure what they are all for. They are listed as:
red = VCC Black = 0V Green = A White =B Yellow = Z Brown =A, Grey =B Orange = Z
I got vcc and ground lol after that i'm confused. Does it have two output wires for you to be able to ultimately tell whether movement of the wheel is clockwise or counterclockwise? If thats true what are all the other wires for? Do I need them?
The NPN open collector output is like the gear tooth sensor you are using, so I would choose that because you already have some experience with noise reduction in that configuration.
You mentioned previously that the lift platform rocks, or jitters on the rails and does not rise smoothly. In that case, the measuring wheel encoder will be subject to that error.
Have you decided that you can not achieve the accuracy you require with the gear tooth sensor? Have you implemented the motor driver and the pwm control over the motor speed?
If you have a 6v motor cycle battery available you might try running the winch motor with it instead of the 12v.
cattledog:
The NPN open collector output is like the gear tooth sensor you are using, so I would choose that because you already have some experience with noise reduction in that configuration.
You mentioned previously that the lift platform rocks, or jitters on the rails and does not rise smoothly. In that case, the measuring wheel encoder will be subject to that error.
Have you decided that you can not achieve the accuracy you require with the gear tooth sensor? Have you implemented the motor driver and the pwm control over the motor speed?
If you have a 6v motor cycle battery available you might try running the winch motor with it instead of the 12v.
I think with the gear tooth sensor my cable system is my weakest link. I think (as someone described) as the cable winds around the spool the distance changes and therefore makes the amount of head movement different even if the tooth count is the same... Someone suggested that may could be eliminated with limit switches and coding, but that seems extremely complicated to me; as each button press would require its own set of pulse counts.... (I'm just guessing this is how it would work).
I think with the wheeled encoder, it would give me a more true measurement of how far the head has traveled as long as the issues you mentioned don't cause missed pulses... As for those issues, The head does move from side to side slightly, but I have lubricated the system and removed cable from the spool. This helped tremendously. It does still "wobble" slightly, but I don't think it will be too much to cause the wheel to miss many if any pulses.
Plus, I am really interested in how all of this stuff works anyway. The gear tooth sensor would/will probably be good enough for my application, but if I can get something that will work better in this situation for 30-40$ and I get to learn about a device. I am sure now that I have a little better understating of how it works I will find a use for the gear tooth sensor. This is a little far fetched, but I have thought about this idea maybe one day way down the road:
Put the gear tooth sensor on the sprocket of the scooter motor that drives the carriage down the track..... This would allow me to have a way of controling how far the carriage needed to go before it stopped (finished cutting through the log). I think I could (eventually) set the mill to: press button - pull the carriage down the track cutting the log the length of the log (based on the tooth sensor on the sccoter motor) raise up and come back -- drop down to the next cut and cut the length of the log again.... repeat this over and over until the log is cut up with one press of a button HAHA maybe a little out there, but a thought for someday....
I know I am a long way from any of that being possible, lol bc I can't even figure out how to modify my existing code for the gear tooth sensor to work with the wheeled encoder. I know the wheeled encoder has two outputs. and the zero or index output.
With the two outputs, would I use them on two separate interrupt pins? Or, would they be on the same interrupt pin?
Could the index line output be used to "know" where the position of the head is after the Arduino is started up?
Thanks!
You're getting hardware advice from a software guy here - so not good
I see no reason to favor PNP or NPN, but I like Cattledog's suggestion to keep things similar.
Regarding voltage, intuitively, I'd pick 5V as it's easily connected to the Arduino, but I am concerned about the earlier interference issues and that makes me wonder about using 12V instead since you have it right there. It might get you a better signal.
I've worked on projects with rather more fancy encoders than that and even they were producing slightly bouncy signals to the extent that Schmitt triggers were needed to clean the pulses enough to be usable. So if you have to add external components, maybe a trigger and voltage divider for two lines is no big deal.
However, I'd try to keep it simple to start and just get a 5V encoder, safe in the knowledge that it inevitably won't be the final design.
wildbill:
You're getting hardware advice from a software guy here - so not good
I see no reason to favor PNP or NPN, but I like Cattledog's suggestion to keep things similar.
Regarding voltage, intuitively, I'd pick 5V as it's easily connected to the Arduino, but I am concerned about the earlier interference issues and that makes me wonder about using 12V instead since you have it right there. It might get you a better signal.
I've worked on projects with rather more fancy encoders than that and even they were producing slightly bouncy signals to the extent that Schmitt triggers were needed to clean the pulses enough to be usable. So if you have to add external components, maybe a trigger and voltage divider for two lines is no big deal.
However, I'd try to keep it simple to start and just get a 5V encoder, safe in the knowledge that it inevitably won't be the final design.
I went ahead and got the 5v. Its not going to break the bank and will interesting to learn about.... Now, I am going to need help with the coding of it... As you can see from my previous post...
neketege88:
I know I am a long way from any of that being possible, lol bc I can't even figure out how to modify my existing code for the gear tooth sensor to work with the wheeled encoder. I know the wheeled encoder has two outputs. and the zero or index output.
With the two outputs, would I use them on two separate interrupt pins? Or, would they be on the same interrupt pin?
Each of them takes an interrupt.
Could the index line output be used to "know" where the position of the head is after the Arduino is started up?
No. The Z pulse occurs once per full turn of the encoder, but it tells you nothing about where the head is because it looks like that wheel would rotate more than once during full travel of the head assembly.
Actually, it occurs to me that you can just use the A wire on the encoder instead of the one from the tooth sensor. You would need A & B if you need to know which way it's turning, but you already know. The code you have will take care of it already. Depending on the pulses per inch, there may be a little tweaking, but pretty minor stuff.
Actually, it occurs to me that you can just use the A wire on the encoder instead of the one from the tooth sensor. You would need A & B if you need to know which way it's turning, but you already know. The code you have will take care of it already. Depending on the pulses per inch, there may be a little tweaking, but pretty minor stuff.
+1 . Yes, brilliant.
Quadrature encoder specs often vary on the meaning of pulses per revolution. Sometimes it is the full resolution reading all 4 transitions, and sometimes it is just the simple pulse count on a channel. I have not been able to figure out what the ppr spec on the encoder you want, but get the 1000 ppr and you can't go wrong.
If you need to use more than a single pulse for the resolution you need for the moves, there are very good encoder libraries available. I would recommend Paul Stoffregen's library Encoder.h which is available from the library manager.
You have selected a 50mm diameter roller which is a circumference of 6.18". Depending on the manufacturers definition of PPR and you get the 1000 ppr model each pulse from the encoder will be 6.18 thousandths(.00618") at worst, and 1.55 thousandths (.00155") at best.
cattledog:
You have selected a 50mm diameter roller which is a circumference of 6.18". Depending on the manufacturers definition of PPR and you get the 1000 ppr model each pulse from the encoder will be 6.18 thousandths(.00618") at worst, and 1.55 thousandths (.00155") at best.
So if I am understanding correctly, a quarter inch move should be about 40 pulses (assuming worst case scenario) about 161 pulses (best case scenario) ?
If this is right and, as wildbill said, I can just use one wire to see one pulse from the encoder. I would just need to change the amounts in the code for the upQuarter Downqyarter variables?
As you can see from my previous post...