From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Sample Clock problems

Ever since I put a sample clock, my counter is going haywire...any suggestions?

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

Could you provide more detail?  Which counter?  Where's the "sample clock"?  What do you mean by "haywire"?

0 Kudos
Message 2 of 10
(2,818 Views)

the cycle "count" in my program is counting sporadically ever since I added a sample clock to my horizontal displacement channel.

0 Kudos
Message 3 of 10
(2,816 Views)

I can read code but not minds; could you try a bit harder?  You have a graph labeled "Horizontal Displacement."  When I follow back the wire going to that graph, it comes from an analog input task.  That task does not have a sample clock associated with it, that I see.  The only sample clock I see is on the Horizontal Load channel.  As for the cycle count, do you mean the Cycle indicator?  Can you be more specific than "counting sporadically"?  Do you mean there are conditions under which you expect it to count an additional cycle, but it does not do so?

 

It looks to me like you're try to count transitions where your input goes from less than to greater than some value.  You're reading multiple data points (don't know how many) on each cycle of the while loop.  However, you only process one point per loop cycle, discarding the rest (but still graphing them), so you could easily miss a transition.

0 Kudos
Message 4 of 10
(2,813 Views)

I'm sorry, I meant horizontal load. The counter indicator counts really fast up to 50, then it starts doing what it is supposed to do..which is count each cycle of my TTL.

0 Kudos
Message 5 of 10
(2,808 Views)

I think you need to look carefully at the data you're receiving.  I don't see any obvious problem with the code, but I also don't have the DAQ library you're using (the Measurement Computing Universal Library, if I'm not mistaken), and your wires are running all over the place so it's a bit hard to follow.

 

Have you run your VI with execution highlighting?  Have you put any probes to see whether the logic is doing what you expect?  Have you tried writing a typical series of inputs to a file, then reading that in instead of acquiring from the DAQ so you can look at it more easily?

0 Kudos
Message 6 of 10
(2,806 Views)
Typical series of inputs?
0 Kudos
Message 7 of 10
(2,800 Views)

A typical series of data readings - whatever data it is that you expect to produce a normal cycle count sequence.  For example, run your current code and each time through the loop, write the value that it reads to a file.  Then, rework your code so that instead of reading from the analog input channel, it reads from that file.  Or, it might be enough just to look at the file and see if the transitions are where you expect them to be.

0 Kudos
Message 8 of 10
(2,795 Views)

ok, so, instead of using the sample clock, I'm using a time delay inside my case structure where I'm taking measurements to a file. It seems to give me the right range of points...but it's not exact. You think I should do it this way?

0 Kudos
Message 9 of 10
(2,766 Views)

I think you need to spend some time understanding where the problem comes from when you add the sample clock.  Also, clean up the wiring so you don't have overlapping wires and so many conversions between data types.  I'd start by creating a new VI that uses only the analog channel that you're using for the cycle counting (although, if it's TTL and you're just looking for transitions, why use an analog instead of digital input?).  See if you can duplicate the behavior with just that one channel.  Look at whether there's a difference in what data points are read, and which data points are used for the transition analysis.

0 Kudos
Message 10 of 10
(2,751 Views)