LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using One Counter for Two Sensors

Solved!
Go to solution

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.

0 Kudos
Message 1 of 10
(1,104 Views)

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

0 Kudos
Message 2 of 10
(1,099 Views)

Short answer... No.

 

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

 

 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 3 of 10
(1,095 Views)

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.

0 Kudos
Message 4 of 10
(1,089 Views)

@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.

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 5 of 10
(1,065 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 6 of 10
(1,040 Views)

@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...

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 7 of 10
(1,034 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 8 of 10
(1,025 Views)

@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

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 9 of 10
(1,015 Views)
Solution
Accepted by MalOrin

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!

0 Kudos
Message 10 of 10
(938 Views)