Using One Counter for Two Sensors

[MalOrin]

Hello,

I have a project I'm working and my current code calls for 5 counters and I only have 4, and I was wondering if there was any way to have two speed sensors use just one counter? Like where the first sensor acts as the rising edge and the second acts as the falling edge.

Any help or input given would be greatly appreciated.

[altenbach]

Each sensor outputs rising and falling edges, so how are you planning to connect both and sort it out?

[RTSLVU]

Short answer... No.

But, in theory you could use or build a multiplexer and measure all five with just one counter. 

[MalOrin]

The sensors are set up where one is about 6 inches from the other, and when the object gets shot through, as it passes the first sensor it could act as the rising edge, and as it left the second sensor it could act as the falling edge, which made sense to me in theory but I wasn't certain if LabVIEW had the capabilities for this. I hadn't really been able to think of a way that I would be able to realize this though.

[RTSLVU]

---

@MalOrin wrote:

The sensors are set up where one is about 6 inches from the other, and when the object gets shot through, as it passes the first sensor it could act as the rising edge, and as it left the second sensor it could act as the falling edge, which made sense to me in theory but I wasn't certain if LabVIEW had the capabilities for this. I hadn't really been able to think of a way that I would be able to realize this though.

---

This isn't really a LabVIEW issue, what you are thinking just won't work the way you think it will regardless of the programming language you are using.

But you gave us a little more information here that got me thinking...

It sounds like you are passing an object through a bunch of speed sensors along the length of its travel.

How about instead of using actual speed sensors. Use optical sensors and light sources as a series of light beams along the length of travel.

When the object breaks the first beam start a timer. Note each time the object breaks each beam in sequence.

Using the time between beam breaks and the distance between beams you can calculate the speed of the object.

[Kevin_Price]

What DAQ device are you using?   With 4 counters, I'm guessing either an X-series board or a cDAQ chassis.   Here are some quick thoughts:

Either of those should support a measurement mode called "Two Edge Separation".  You specify which signal & edge start the measurement and which signal & edge end it.

You might be better off measuring from rising edge of sensor 1 to *rising* edge of sensor 2 so that your speed calculation depends only on sensor distance and not also on object size.

There's another possible option where you wire up all 5 sensors in a Digital "change detection" task while also measuring periods of the internal signal known as the "change detection event".   This method would probably limit your time resolution to 1 microsec.  (Whereas the counter method would give more like 0.01 microsec resolution.)   But you could derive more info by having time data for all edges of all sensor signals.

-Kevin P

[RTSLVU]

---

@Kevin_Price wrote:

What DAQ device are you using?   With 4 counters, I'm guessing either an X-series board or a cDAQ chassis.   Here are some quick thoughts:

Either of those should support a measurement mode called "Two Edge Separation".  You specify which signal & edge start the measurement and which signal & edge end it.

You might be better off measuring from rising edge of sensor 1 to *rising* edge of sensor 2 so that your speed calculation depends only on sensor distance and not also on object size.

There's another possible option where you wire up all 5 sensors in a Digital "change detection" task while also measuring periods of the internal signal known as the "change detection event".   This method would probably limit your time resolution to 1 microsec.  (Whereas the counter method would give more like 0.01 microsec resolution.)   But you could derive more info by having time data for all edges of all sensor signals.

-Kevin P

---

I don't understand why you would need to use counters for this. 

Couldn't you do the same thing with a DIO set to input?

What DAQ device are you using? Would help a lot here...

[Kevin_Price]

Why counters instead of DI?  In a nutshell...

Counters can directly measure time intervals to the nearest 1 cycle of the device's master timebase.  Nowadays, that's often 100 MHz or 10 nanosec.

Not all devices support hw-clocked DIO, and many that do are limited to <= 1 MHz sample rate.  And then there's potentially big data sets and post-processing to do to find the indices of the transitions and their corresponding sample times.

-Kevin P

[RTSLVU]

---

@Kevin_Price wrote:

Why counters instead of DI?  In a nutshell...

Counters can directly measure time intervals to the nearest 1 cycle of the device's master timebase.  Nowadays, that's often 100 MHz or 10 nanosec.

Not all devices support hw-clocked DIO, and many that do are limited to <= 1 MHz sample rate.  And then there's potentially big data sets and post-processing to do to find the indices of the transitions and their corresponding sample times.

-Kevin P

---

I see... Thanks

[MalOrin · Accepted solution]

I was able to find a solution that worked for me as I'm not able to use a different type of sensor, in my code I was using a sequence structure and I moved the speed sensor 1 code to a frame before everything else and then was able to re-use it that way, thank you all for the help and advice though!