10-07-2020 08:41 AM
Why do you think you need an AI channel for a *digital* signal? I assumed when you said the frequency was a digital signal that it'd be the 0-5V logic-level digital that's compatible with your DAQ device.
If indeed it *is* such a digital signal, the code I posted will divide the frequency right in hardware using a counter. You don't actually *acquire* the signal or display it, you just let the hardware do its thing.
If you really want to display the signal with LabVIEW, you *can* acquire it with AI. I'd recommend you start with one of the shipping examples for continuous voltage acquisition.
(In most cases it'd be more appropriate to acquire the signal with a DI task rather than AI, but AI will be simpler for you. Your device is an M-series with some limitations and complications for DIO. You can read more about it by searching for terms like "correlated DIO" or "correlated digital.")
-Kevin P
10-07-2020 08:53 AM
Thanks for the explanation, you are right my device does not have DIO , I am using AI0 for for signal acquisition. But I am not sure how to take samples at each rising edge and store it till 04 pulses so that the generated frequency is 1/4th to the input. Yes I need to plot the output too so that to compare it with the incoming signal.
I am checking the example you mentioned, Lets see to have some solution.
10-07-2020 09:19 AM
To make use of AI, you won't just try to sample on rising edges, you'll be sampling *continuously*. I'd recommend a sample rate at least 10x the frequency of the signal coming in that you need to divide by 4.
Then you'll take that analog data and convert it to booleans. A very simple method would be to compare for whether your array of analog data is > 2.5. The result of this comparison will be an array of boolens representing low (F) and high (T) samples. Once you have this array of booleans, you can use the algorithms others have helped you with earlier in the thread.
Are you also supposed to create this divided-down signal in hardware? Again, that's what my counter task will already do, and it does it in hardware, in real-time, with no latency. Any thing you do with AI acquisition, followed by software algorithms, followed by signal generation will have latency. Maybe that's not a concern, but then again maybe it is. We seem to keep learning "just a little more" about your requirements as the thread continues along.
-Kevin P
10-07-2020 09:35 AM
That is an awesome post from your side. Yes, I am doing the same as you have mentioned, but I was confused about whether I am doing it in the right way or not. For now, I have to do it in the software. Kindly find the file in the attachment, I am using case structure with 1 increment of pulses after comparison but I am doing some mistake there.
Maybe after this I am asked to do it in hardware too then I will follow the method you have mentioned.
10-08-2020 09:07 AM
Dear Kevin or anyone else who can guide me.
Need your help, as I have designed a 2 bit binary counter using a digital signal. how can I get that divided signal from the NI Daq device (6212) to see it on oscilloscope whether it is divided or not?
The related device configuration and VI are attached.
10-08-2020 01:15 PM
I've given you a pure hardware solution, others have given you software algorithm solutions. But your latest code shows no awareness of any of it.
As one who's here volunteering help & time, that can be frustrating. I tend to drop out of threads when I sense that a poster's expecting more from me than they're doing for themselves.
-Kevin P
10-08-2020 05:14 PM - edited 10-08-2020 05:30 PM
Dear Kevin,
Applying a real-world signal is not working for that simulated code. I have tried with many changes but I did not get any solution.
Also the hardware you have provided, in the last reply I sent you the screenshot with error. Apart from input and output ports, there is a counter-selection and external freq input terminal option too? Also, what if freq needs to be 1/4th? I did not know what's happening in that code. That's why I switched to a simple counter code.
Never mind, I am not an expert I am learning everything from scratch. Thanks for the help, highly appreciated! I am trying that hardware code again.
10-09-2020 03:43 AM - edited 10-09-2020 04:05 AM
Hardware Clock example!!!! but it resolved. I need to change the ticks values both equal to two.
Thanks again Kevin and Altanbech for the help. But still curious why worked on such ticks values and not on previous values😁
10-09-2020 08:19 AM
That's my fault. Sorry. I meant to (and thought I *had*) saved that vi with default values of 2 for both high and low ticks. Apparently not. But there is a little text on the front panel about it, meaning to alert you that that 2 is the min value allowed.
"Ticks" here means the same as "active edges" which are often designated with a "polarity" setting -- sorry, I'm afraid counter terminology isn't always the most intuitive or consistent. Anyway, counter operations are primarily based on circuitry that reacts to a particular polarity of active edge. Often the default is a rising edge.
Pulses or clocks have both 1 active and 1 "inactive" edge per full cycle. I think the reason NI's counters demand a minimum of 2 active edges (again, a.k.a. "ticks") has something to do with the fact that it takes 2 consecutive active edges to define a full interval.
Glad you got the hardware solution working, sorry for my initial oversight. You can also use pretty much any value >2 for either or both. Equal numbers yield a square wave with equal high and low times. Unequal numbers lead to asymmetric pulses, I like to call "rectangular waves". I don't think this term is in any kind of common use though.
-Kevin P
10-09-2020 03:47 PM
Dear Kevin,
Thank you so much for the explanation. Because of such restriction on ticks, it starts dividing from1/4th, I hope there should be a way to divide it by 2 as well.