Measuring Hall Sensor Speed with Incremental Counter via TTL Serial Communication

[neunited]

Hello,

I require to measure the rotational speed and acceleration of a rotor that has 3 hall sensors on it.

I have uniquely identified the 6 Hall Sensor states with an iteration count from 0 - 10921 which is being read in LabVIEW during runtime.

There are 24 pulses which occur for every 360° mechanical rotation.

I wasn't sure if there would be any issues with maintaining speed measurements due to reiteration which is occurring during runtime.

I am currently attempting to keep the count value using shift registers, however I haven't succeeded to implement that yet, maybe a fundamental mistake on my part? 

Is it possible to measure speed with only the reiterative values - if so could someone point me in the right direction with an example of how this can be achieved?

Many Thanks.

[Albert.Geven]

Never use number of bytes at serial port if there is an alternative.

If your data has cr or LF or both as separators or another end character use that to be sure you have all data.

I saw that you did not really use the number of bytes at serial port, so you know the number.

If that is constant it is also possible.

But I don't believe you can read quickly enough in this way to see all steps, or am I mistaken?

I don't see a problem in the shift register yet, except if you are not reading anything.

[Minions]

How quickly will these states be changing?  Is there something externally to track these changes or will they need to be handled within LabVIEW?  What is the Serial Communication Baud rate and settings?  All of these will play a factor in determining the capability of your code.

[neunited]

Hi Minions, 

19200 baud @ x8 PLL 
1 stop bit 
8 data bits, no parity

If I've missed anything else please let me know.

Many Thanks,

[neunited]

---

@Minions wrote:

How quickly will these states be changing?  Is there something externally to track these changes or will they need to be handled within LabVIEW?  What is the Serial Communication Baud rate and settings?  All of these will play a factor in determining the capability of your code.

---

Hi Minions,

How quickly will these states be changing?

These states are changing depending on how fast the motor runs. Rated speed is 3000 revs/m = 1200 iterations per second.

Is there something externally to track these changes or will they need to be handled within LabVIEW?

I will need to track these changes in LabVIEW - LabVIEW needs to continue reading the values rather than reiterating to 0. I recall there was a function available in NXG with Quanser that resolved this issue but have been unable to hunt it down for LabVIEW yet.

What is the Serial Communication Baud rate and settings? 

@19200 baud @ x8 PLL 
1 stop bit 
8 data bits, no parity

Many Thanks

[Minions]

---

@neunited 

How quickly will these states be changing?

These states are changing depending on how fast the motor runs. Rated speed is 3000 revs/m = 1200 iterations per second.

... 

19200 baud @ x8 PLL 
1 stop bit 
8 data bits, no parity

---

19,200 baud / [ (8+1) + Start +Stop] = 19,200/11 = 1,745 updates per second max with one way communication (listen Only). 

Are the 8 counters shared across this port or are each of them using an independent port? 

Remember also that Windows will control the resource slicing (unless running on a real-time system).  This can mean that you may lose up to a few hundred milliseconds every so often from Windows prioritized functions (This means lost counter pulses).  It may even trick your program into reading a reverse in direction from the missed pulses.

[Henrik_Volkers]

Do you really need to read these 6 sensors via serial port?

How are they coded: I assume gray code?

(2^6=64 bit resolution per revolution?)

Spoiler

a simple USB 8bit DI card would ease your task a lot;)

(or something like a arduino incl. on board position decoding?)

3000rpm is 50rps (with 64 position) -> up 3200 changes per second.

if you read at least 101 positions per second  you can reconstruct all revolutions incl. direction .. if direction is fixed 51 SPS 😄

Decoding per lockup table to phase.. phase unwrap .. ..

More important is the timing! 

If you need to request every datapoint (software timing) .... I wouldn't give it a big chance...,

if your device send data with a known constant samplerate....  doable.