Slightly obscure question on serial ports
Author
I'm using a single pin on the serial port as an input with a contraption I have made. The device has a photo-eyeball thing and it can switch the pin high or low. This works fine.
My question is: how quickly can I 'read' this pin state? Does it only get updated every X microseconds or will its value always be refreshed every time I request it? I'm assuming the first one.
The code I am using is available here, if that matters: http://www.logix4u.net/inpout_theory.htm
Basically I am using this to read the RPM of a motor into the PC (by counting time between when the sensor sees a propellor blade, or tab on a disc, etc). The RPM could potentially get rather high (30,000+) so the time between states could get rather small. If it starts missing blades because the port doesnt update fast enough that would be a problem.
Thanks.
Im not really sure about the source code you are using, but with the serial port code I have written in the past...data will be available about as fast as you can read. Usually I would use blocking serial i/o so it would read any data on the buffer and keep polling until more data was availabe and then read so more.
Yeah almost forgot, in your case with the application you are talking about. A spinning propellor blade or encoder like disc may be difficult to get that fine of granularity using windows and serial port reading...can anyone confirm this?
It might be that if you want that kind of accuracy, would have to implement in firmware like on a PIC.
It might be that if you want that kind of accuracy, would have to implement in firmware like on a PIC.
Author
The blocking code is probably a good idea, yes.
As for as fast as you can read it...well that may well be very fast. I'm just using a very simple console app.
some quick fuzzy math tells me a two-blade propeller spinning at 30,000RPM will have a blade go past the sensor every 1/1000th of a second. The refresh rate of the input would thus have to be a few magnitudes finer than that to get any meaningful data out of it. So I guess I'm looking at 10/100's of microseconds. Doesnt seem too feasible?
As for as fast as you can read it...well that may well be very fast. I'm just using a very simple console app.
some quick fuzzy math tells me a two-blade propeller spinning at 30,000RPM will have a blade go past the sensor every 1/1000th of a second. The refresh rate of the input would thus have to be a few magnitudes finer than that to get any meaningful data out of it. So I guess I'm looking at 10/100's of microseconds. Doesnt seem too feasible?
If all you're doing is polling for data and then storing it, until you have a set of results, then I don't think 10/100ms per 'round' is unfeasible. Then again, I'm no electronics guru, I have no idea how fast the interaction with your device is, etc. Lots of unknown factors, to me at least, make it hard to give an educated answer to that.
I'd suggest, if it fits in with your program, that for a set amount of time eg. 2 minutes you just sit counting the number of highs you get so that all you do other than read is increment a variable. Then after use the count and known time to claculate the rpm etc. Do this as a test first and see if you get the right result
Another possibility would be to run a reducing gear off the motor and run your counter off that. Average the speed over a second or so and you should get reasonably accurate results.
You could even set up a few sensors at different points (1/4 turns or something) if you wanted more accuarate results over smaller time frames.
Just remember that you will be reducing the output power of the motor this way though.
You could even set up a few sensors at different points (1/4 turns or something) if you wanted more accuarate results over smaller time frames.
Just remember that you will be reducing the output power of the motor this way though.
Author
Quote:Original post by SirLuthor
If all you're doing is polling for data and then storing it, until you have a set of results, then I don't think 10/100ms per 'round' is unfeasible. Then again, I'm no electronics guru, I have no idea how fast the interaction with your device is, etc. Lots of unknown factors, to me at least, make it hard to give an educated answer to that.
I am storing it for later use, yes. No data manipulation is done until after the run. The sensor used should be plenty fast enough given the spec sheets I have looked at.
Quote:Original post by Dragoncar
I'd suggest, if it fits in with your program, that for a set amount of time eg. 2 minutes you just sit counting the number of highs you get so that all you do other than read is increment a variable. Then after use the count and known time to claculate the rpm etc. Do this as a test first and see if you get the right result
A good idea to veryify if it is reading the proper rpm, but insufficient for the purpose of the device. I suppose I should have mentioned that. I am trying to create torque and power cuves for the motor based on the rate of acceleration at a given RPM.
Quote:Original post by OldDev
Just remember that you will be reducing the output power of the motor this way though.
I think the power loss due to the drive-train friction may end up corrupting the results.
Appreciate the replies. Suppose I will just have to try things and see what (if anything!) ends up actually working.
You might want to make it run in DOS. That way, you know that program is the only thing running, so it can take all the CPU. Otherwise, I'm not sure Windows will be responsive enough (i.e. you'll be starved of CPU to read the serial port). Just my thoughts anyway :)
Author
Quote:Original post by CloudNine
You might want to make it run in DOS. That way, you know that program is the only thing running, so it can take all the CPU. Otherwise, I'm not sure Windows will be responsive enough (i.e. you'll be starved of CPU to read the serial port). Just my thoughts anyway :)
Well I had a test program setup where I was checking the timer frequency and the update rate of the actual console app and both went above and beyond what I expect I will need. I'm mostly concerned with how often the particular pin on the port is updated. The port has a definite bandwidth maximum, so I would assume it can only blink so fast...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement