proximity switch encoder help

More
20 Aug 2017 19:30 #97793 by blazini36
blazini36 created the topic: proximity switch encoder help
I've been trying out some different encoder setups which need to be accurate but not necessarily high resolution. This is a non-typical build so encoders are wither very expensive or hard to come by. I've broken several inexpensive rotary encoders because of difficulty mounting, though they did report spindle speed reasonably accurately in axis. I''d like to use proximity switches because there's nothing to break.

I'm using a Mesa 7i76e and I have 2 NPN prox switches reading off a 12 hole disk I made. They do read and I know it's Ideal to have them read 90 degrees out of phase. The outputs are hooked up to enca- and encb- of the mesa card. There is some runout in the disk but they do read every pulse, speed is just all over the place and I want to make sure I'm not wasting my time before I try to true it up. I have only changed the .ini file's encoder scale to 24. I'm wondering if that's correct since it's not a quadrature encoder and the enc+ are not connected. Is there something I have to change in Hal as well?
More
20 Aug 2017 22:51 #97799 by andypugh
andypugh replied the topic: proximity switch encoder help
I think what you have ought to work. Does it matter to your application that the measured speeds vary wildly?
More
20 Aug 2017 23:31 #97801 by blazini36
blazini36 replied the topic: proximity switch encoder help
Well it will, as you know I'm still working through some custom software things. My GUI will display speed in FPM, I haven't gotten that far but I'll assume I'll be using the same mechanism as the widget in axis. The other function is for pulse counts after an index is received.

I think the speed thing is because of the on-time overlap. The way the switches are arranged one goes on and off before the other goes on. So basically I think I need to drill bigger holes to increase the off time so they overlap . I will true the disk and hook up the scope and try to phase the pulses. I just want to make sure whatever filter is on there and my encoder scale is set right before I go crazy. It's throwing me off a bit that if it were a quad encoder it would be encoder ppr x 4, But I'm not sure if this is the case here.

btw, these are 5khz switches so switching speed should not be an issue.
More
21 Aug 2017 02:07 #97804 by PCW
PCW replied the topic: proximity switch encoder help
A 12 hole disk should generate 48 edges with 2 detectors
(and therefore 48 counts/turn in the normal 4X quadrature mode of the hostmot2 counter in quadrature mode)
More
21 Aug 2017 05:50 #97807 by blazini36
blazini36 replied the topic: proximity switch encoder help
The documentation for hostmot2 says the encoder counter mode is set false for quad, or true for single channel. My Hal file generated by pconf has mode as "0", which I assume s the same as false. Setting mode to 1 and it reads off enca but not encb. This is much more stable it bounces about 20rpm rather than jumping up and down from 0 but I lose the extra resolution from the second switch. I'm guessing it bounces 20rpm because of the change in pulse width caused by runout. Is there any way to sort of dumb it down to where is just counts the pulses from A and B? I can get the pulse width a little better but I don't know how close I can get the 2 channels to be 90* out because moving the switches in and out changes the pulse width and that seems to matter
More
21 Aug 2017 14:24 - 21 Aug 2017 14:25 #97816 by PCW
PCW replied the topic: proximity switch encoder help
Unfortunately if you just count pulses on low resolution encoders you get a much worse velocity estimation result.
Imagine your 48 count encoder running at 600 RPM, This gives you 480 counts per second, or about a count every 2 ms so if a velocity estimate is done at the servo thread every 1 ms, (using delta-counts/delta-time) you will get alternate
double speed (1200 RPM) and zero speed readings.

What is the velocity needed for? If its only for a readout and not high speed feedback, you can low pass filter
the velocity estimate to remove the variations

Also as you may have figured out, slots are better than holes for encoders since they are insensitive to
radial sensor alignment
Last Edit: 21 Aug 2017 14:25 by PCW.
More
21 Aug 2017 18:22 #97831 by blazini36
blazini36 replied the topic: proximity switch encoder help
OK that makes since. The speed readout is for display and at some point certain values may rely on it, but not in a way that it has to be measured with high accuracy. Like the index for the encoder is a separate sensor, then a number of counts off the encoder will trigger an event. So say at 300fpm, on every 3rd index pulse you count 10 encoder counts and trigger the event. Well at 400fpm it's running much faster so we may want to take the 10 counts after the 4th index pulse to trigger. I may add some delays or something that are speed related as well but nothing that requires any real measure of accuracy.

The filter thing is kind of what I was looking for can you point me in the right direction on that? that's in the hal file correct?

Slots are a bit harder to machine with just a lathe and a drill press. If I had a mill and a rotary table (or CNC Mill) I'd do it. I work with printing equipment, and alot of the newer digital stuff maintains pretty good positional accuracy with just a drilled disk. Looking at one example today I've noticed that the holes are drilled much closer together which I'm sure makes the on-time closer to 50%. Maybe I should pass it around on here, see if anyone wants to CNC one up for me.
More
21 Aug 2017 20:09 #97836 by rodw
rodw replied the topic: proximity switch encoder help

blazini36 wrote: Slots are a bit harder to machine with just a lathe and a drill press. If I had a mill and a rotary table (or CNC Mill) I'd do it. I work with printing equipment, and alot of the newer digital stuff maintains pretty good positional accuracy with just a drilled disk. Looking at one example today I've noticed that the holes are drilled much closer together which I'm sure makes the on-time closer to 50%. Maybe I should pass it around on here, see if anyone wants to CNC one up for me.


Hmm, I think you need to make yourself a plasma machine and cut the slots. Its only taken me a bit over 12 months.... :)
Australia might be a bit too far away for you to bring it round.

Most printing machines I've seen use a light emitting sensor that wraps around a toothed plate.
More
22 Aug 2017 01:02 - 22 Aug 2017 01:08 #97846 by blazini36
blazini36 replied the topic: proximity switch encoder help
The optical sensor on a toothed disk is li ght duty stuff. 90's Era litho Presses do fine with a driveshaft brake disk with like 24 holes drilled in it and a prox or inductor pointed at it for speed. I'm seeing faster mono inkjet web printers using 20 hole disks on like 2.5" circles with a single prox switch with good positional accuracy at 500fpm. This relates well to my project because then it's a similar control scheme.

A plasma cut disk wouldn't be the best choice here this is a 2.5" hole circle that should probably go from the 12 I have now to about 20 holes. Ill have to draw it up and see what it looks like. Pics of the current setup (hole spacing is likely too wide)
Attachments:
Last Edit: 22 Aug 2017 01:08 by blazini36.
More
22 Aug 2017 01:31 - 22 Aug 2017 01:31 #97847 by PCW
PCW replied the topic: proximity switch encoder help

The filter thing is kind of what I was looking for can you point me in the right direction on that? that's in the hal file correct?


Yes, theres' a lowpass filter component that can be added to your hal file, something like

loadrt lowpass count=1
addf lowpass servo-thread

net filtered_velocity lowpass.0.out
net raw_velocity hm2_5i25.0.encoder.00.velocity lowpass.0.in

# set gain for 1 Hz Bandwidth @ 1 KHz sample
setp lowpass.0.gain 0.0063

man lowpass

for more info
Last Edit: 22 Aug 2017 01:31 by PCW.
Moderators: Rick G
Time to create page: 0.197 seconds
Powered by Kunena Forum