Hi Olin,

>> I am a hobbyist who is trying to help a friend with a project. He
>> wants to monitor the speed of about a dozen shafts on his potato
>> digger. The shafts normally run around 200 rpm, but each shaft may
>> run at a different rpm. One or more shafts may even stop if the
>> digger is overloaded. I am wondering which approach you might
>> consider most feasible to monitor so many shafts. On each shaft is a
>> 16 tooth sprocket and a hall effect sensor. I already have a 5.7"
>> LCD display from Amulet Technologies to display the speeds.

OL> What response time to you need to shaft speed changes?  How often do you
OL> need to send out updated shaft speeds?

I would like to update the display twice a second. I do want to add
an alarm feature if any shaft goes above or below the user-specified
range for that shaft. Because the user will be manually adjusting
the speed of the various shafts on a daily basis, we figure the
easiest way to handle this is to specify overspeed and underspeed
percentages and during operation, push a button to indicate that the
shafts are running at the desired rate. For this harvest, I would be
satisfied with just displaying the RPMs, even omitting the alarms,
because I want it done by the end of the month. Next year, we are
much more ambitious and want to add the ability to match the shaft
speeds to the ground speed of the digger.

OL> 200RPM with 16 counts/revolution is only one pulse about every 19mS.  This
OL> is so slow a PIC should be able to handle 12 of these inputs at once.  A
OL> 20MHz PIC with enough input pins could easily read all the inputs once
OL> every 200uS, which is once every 1000 instructions.  This allows you to
OL> measure the period between teeth to 200uS resolution.

I've never tried to measure periods by monitoring the inputs. In the
few projects where I have counted pulses, for example, where I
monitored a flow meter, I used the Capture or Compare module. I want
to be sure I understand what you mean here, so I want to think about
this for a while longer. I have a hunch that this type of monitoring
would be easier in assembly than in CCS C because of the timing
loops.

OL> A little low pass filtering and you get a sortof average of the
OL> recent few pulses. I would keep these 12 filtered shaft period
OL> values live with a background process. The foreground code just
OL> considers these the official shaft periods whenever it needs
OL> them. At regular intervals, it grabs the appropriate value,
OL> inverts it to make speed, then passes it on. You could
OL> automatically send the latest shaft speeds every 250mS or so to
OL> keep a display live. Depending on where these values are going,
OL> it may be acceptable to send period instead of speed.

OL> What are these values going to get used for that the existing display
OL> isn't sufficient for?

The existing set up is a rotary switch and a three digit
seven-segment display. I don't think there are any alarms.

Thanks for your help!

--
Best regards,
Patrick Murphy
James Valley Colony

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body