From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

1-D Boolean array to be used as a Pause Trigger input of a counter

Solved!
Go to solution

Hello everyone,

  

The issue that I have is I couldn't find an efficient way of creating a custom digital signal to feed the counter's gate input. I'll elaborate the problem later but first here are the details of the system that I am using: 

 

*DAQ device: PCIe-6363 (Port 0/line0-7 can be used for buffered operations, Port 1 and Port 2 can be used for unbuffered operations or as PFI lines) 

*SW: LabVIEW 17.0

*External 10 MHz clock is connected to PFI4. A 10 KHz continuous pulse is generated using a Counter Output Pulse Tick Task (ctr0) based on the 10 MHz external clock. The 10 KHz pulse will be used as the main clock (MAIN CLK) in the system. 

 

Now let's go back to the description of the issue. Assume one (ctr1 in the VI) of the counters (in total there are four counters) in the DAQ device  is being used to count the raising edges of some digital signal available at the input port of the counter. For this task, the "Sample Clock Task.vi" is configured such that the source of sampling (source input of the task) is connected to MAIN CLK (output of the associated counter). Furthermore, a Pause Trigger Property  Node is used to pause/resume edge counting task. Attached VI shows the system configuration so far. 

 

Here my question is: If the information of shape and time (with respect to MAIN CLK) of the pause trigger signal are known prior to start of all the tasks in the system, how am I going to generate and implement the pause trigger signal at Pause.DigLvl.Src input?

 

To clear things up:

Assume, I have a 1-D Boolean array (not necessarily be periodic), whose elements and size are known and going to be used to generate the pause trigger waveform. AT EACH rising edge of the MAIN CLK,  if the current element of the Boolean array is TRUE (or FALSE), then the state of the Pause Trigger will be HIGH (or LOW).  That waveform should appear at the GATE input of ctr1. Is it possible to achieve this? If yes, what would be most efficient way in terms of using resources? Two counters (out of four) left, for example, it would be better if less number of counters are utilized at the end. 

 

Attempts:

I, first, tried to use Digital Output Write Task, which is sampled with MAIN CLK to write the elements of the Boolean array to one of the output ports. However, GATE input of the counter cannot be set to hardware-timed Digital I/O lines (in this case port 0/line0-7). I can select one of the PFI lines (Port1 and Port2) but now those lines are not available for buffered operation that I am using during Write Task.

 

Second attempt that I am considering is to use "Change Event Detection" feature to realize the pause trigger waveform from a custom Boolean array. This approach is again based on updating the line Port0/line0  at each clock edge, where any transition from LOW to HIGH can be captured by Change Event Detection. I don't know the details of this feature so any feedback regarding the method and/or other issues would be greatly appreciated.  

 

Thanks for reading.

Best,

CHA 

0 Kudos
Message 1 of 7
(4,044 Views)

Hi again,

 

After reading my original post, I would like to add couple of things:

1) The second attempt did not work as well, since both Digital Input and Digital Output Tasks in the VI shares the same line, Port0/line0. In this configuration, LabVIEW throws an error stating that the resource is already reserved for one task so that  another task cannot use it before the first task is stopped/cleared.

 

2) One trivial answer to my main question might be to abandon utilizing the Pause Trigger completely and postprocessing the data (number of edge counts) at the end of the process since the Boolean array is known. The specific counts (collected during the time intervals where elements of the array are TRUE) can be removed effectively, after the data collection is done. However, there are also Write Tasks that need to be paused/resumed. Therefore postprocessing would not work for me in this case.   

0 Kudos
Message 2 of 7
(4,013 Views)
Solution
Accepted by topic author cha1903

I'm still at LV 2016 and can't look at the code, but here are a few brief thoughts:

 

1. I am not sure if this is still true for X-series devices like yours, but I'm pretty sure that prior generations of counters didn't support input tasks with both a sample clock *and* a pause trigger.  That included tasks using implicit timing like freq or period measurement. 

 

2. Your attempt using DO that's clocked by MAIN_CLK should have *physically* wired from the DO pin over to a PFI pin that could act as the counter's pause trigger.

 

3. You could similarly generate the variable-timing pulse train with another counter instead of using DO.  Your X-series board supports that capability as well.

 

 

 

-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 3 of 7
(3,995 Views)

Kevin,

 

Thanks for the input, it was extremely helpful. Wiring the DO pin over to a PFI pin on the connection block seems to be the easiest solution then. I thought about generating the variable-timing pulse train inside a timed loop, which is synch with the MAIN_CLK, but in that case I need to stop and restart the task (the counter that you mentioned in 3.)  every time before changing the values of the variables High Ticks and Low Ticks. And I was not sure if that introduces any delay caused by the software. I don't know how much time the software needs to stop, update the values, and restart the counter after a timed-loop iteration begins. 

 

I don't want to mislead anyone, but I am almost positive that the sample clock and pause trigger property nodes for a counter task (for both input and output tasks) can be set separately on the hardware (PCIe-6363) that I am currently using. That is what I've done before actually to generate a clock based on an external signal (using Sample Clock Property) and synchronized to some other source (using Trigger Property). Attached is a screenshot from X-series manual (page 129 of 259). The picture shows that Counter Sample Clock and Counter Gate inputs are distinguished. 

 

Last but not least, thanks a lot again. Not just for your response to this specific question but for the dozens that you helped all over the years. This might be my first posting here, but I learned a lot of things in LabVIEW from your answers in this forum. Just wanted to let you know.

By the way, I saved the same VI for the version 13 if anyone wants to look at it. 

Best,

CHA

Download All
Message 4 of 7
(3,985 Views)

You're right about the ability to combine sample clocking *and* pause triggering.

 

The excerpt from the manual prompted me to take a much closer look at the X-series manual.  It's been a long time since I looked at it.  I've been coasting along on my memory of accumulated "knowledge" -- in quotes because it doesn't count as knowledge if it turns out to be erroneous.

 

First off, wow, that manual is really quite impressive in its coverage of counter functionality!  Much applause!

 

Further along in the section on counters, Pause Triggers are addressed.  There it states that Pause Triggers are supported for edge counting tasks and for continuous pulse generation tasks.  I noted that it didn't *specifically* say it was supported for buffered edge counting tasks though (the kind that use a sample clock).

 

So I did an experiment with a shipping example, and it turns out to function correctly and without errors.  So thanks, you taught me something new today!  (Looking back at the M-series manual, it has the exact same verbage so I guess this capability has been around a long time and I just never noticed.)

 

Physically wiring the DO output signal ought to be able to work.  Just to note: you *can* change the High and Low Ticks values for a counter output on-the-fly without stopping and restarting the task.   More importantly however, with your X-series device you could predefine a variable timing pulse train in a buffered, hardware-timed counter output task.  (*That's* a capability I used to long for so I know NI didn't support it before the X-series boards.)

 

If you're trying to drive everything off the ctr0 MAIN_CLK, you should stick with the DO approach where you can define state changes for *every* clock edge.  With a CO task driven by Ticks of MAIN_CLK, you'd need a minimum of 2 Ticks each for High and Low.  That would limit your ability to fine tune the placement and duration of the pause trigger signal.

 

Thanks again!

 

 

-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 5 of 7
(3,977 Views)

Thank you so much Kevin!

I'll go with the DO approach as you suggested, but also would like to implement the "Continuous Buffered Sample Clocked Pulse Train Generation" to practice. I was not aware of that feature until you mentioned. I looked at the manual and then the example that comes with LabVIEW after reading your reply. Apparently, you started looking for an answer back in 2001!

You are right about the 2 Ticks for the variables. What I can do is, I can choose 10 MHz external clock as the Source of Ticks for the counter task as, while 10 KHz (MAIN_CLK) as the Source of Sample Clock Task, and just ignoring the two ticks at 10 MHz rate. Just to see how that works.

Best,

CHA 

0 Kudos
Message 6 of 7
(3,972 Views)

Part of the kinda sadder truth is that I was looking even earlier than 2001, before I was on the forum (maybe before it existed?) so I could only nag my local Field Rep. 

 

The other part of the sad truth is that the last time I could have really used it was for a job that ended shortly before X-series was introduced.  C'est la vie!

 

 

-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 7 of 7
(3,965 Views)