Retrigmode in LabVIEW

[gmag]

Hi, 

I am using USB-CTR08 board where I am able to configure CTR0 for counting pulses with an external start edge (Basic Digital Edge) however I would like to have it retriggerable. I see an option RETRIGMODE in other nonLabVIEW exapmples but I am not able to find any such property of Trigger in LabVIEW.

Please advise on how to achieve RETRIGMODE in LabVIEW. Please note I am already using a CTR0Gate beyond which I want RETRIGMODE on TRIG-IN. 

Thank you

gmag

[JRys]

ULx for LabVIEW does not support the RETRIGMODE mode even though your device does. Instead, take a look at the example ULx Acq&Graph Voltage-Int Clk HW Trig Restarts.vi for an idea on how to make something similar. It is in the AnalogIn folder inside the Measure Voltage.llb library.  

Best regards,

John

[gmag]

I see. Thanks for your pointer. So, you configure it to have a hardware digital edge (TRIG IN) and in the loop you start and stop the task so every time it starts the task, it waits for the TRIG IN. I may lose some data in between but it may work. Thank you.

On another note, I am interested in CounterOutput Pulse Generation/Ticks to generate an envelope (every 10 ticks) from the time base ticks that I plan to connect to TRIGIN. If I use Co0, what is the source of the timebase ticks. How can I specify the timebase? For the time being if I try ULx Gen Dig Pulse Train-Continuous.vi, I dont see any output from Co0 (pin 4) on the oscilloscope. It doesnt work either for CO pulse Frequency or even when I try CO Pulse Ticks with 10 low and high ticks. Am I missing something basic? 

Thank you

[JRys]

CounterOutput is directed at the  TMR0 - TMR3 pins 44,45 & 47,48. The ULx for LabVIEW support does not enable the actual counter output line. Many of the USB-CTR08 features are left out. For instance, the TMR outputs can output a number of a pulses and stop in addition to the frequency and duty cycle settings. There's even an initial voltage level setting and a delay, but not in LabVIEW.  The best way to control your device is with a C/C++, C# or Python program because Universal Library exposes all the features. The LabVIEW support is built on a subset of the features. 

Best regards,

John

[gmag]

I understand. Thank you for your response. I see now that ctr0Out is TMRO Out and so on. For now I have to live with LabVIEW as all other programming (bigger application) is in LabVIEW. I guess the one thing that would help me move forward is if it is possible to specify the source of the ticks for CO Pulse Ticks task. Looks like it is taking a ~48MHz clock from somewhere. I want to send in a TTL at some frequency based on which I would like to create a CO Pulse Ticks task. Can we specify the source of timebase or connect to some pin that it takes in as default? I would later connect the output of this task (TMR) into TRIG IN based on which CIn counting will take place. 

Thank you

[JRys]

It's confusing. The timebase itself is 96 Mhz and a tick is half that or 20.83nS. 

I was mistaken about the counter output line. Example, ULx Count Digital Events-Gate Enabled-Output Enabled.vi demonstrates such a thing. Below in this example, I added a 10 kHz square wave output (tmr0) and physically wired it to the c0in (counter 0 input) pin. The example is configured for range counting with the output toggling at 500. In other words, the counter will count to 1000 repeatedly effectively dividing 10 kHz by 1000 to produce a 10 Hz square wave on c0o (counter 0 output). However, this example is silly because if you want a 10 hz square wave output the timer along could provide it. At this time, I don't see a way to make it output a finite number of pulses. 

Best regards,

John

[gmag]

Thank you John. Sorry I guess I confused you. I am already using the GateEnabled example to do something similar to above. The question is to generate CO Pulse Ticks task with a source. I have a 22 kHz coming from some other part of the instrument that needs to come into the DAQ (as external clock in or something like that) based on which I want to be able to generate a Counter output (e.g. every 500 ticks high and 500 low) should give a 22Hz Counter Output but this has to be in sync with the input 22 kHz. Hope I am clear. When I try the external clock example with CO Pulse Ticks (instead of CO pulse freq) it says the device cannot do external clock. Is there any other way to specify the input source.

Thank you

[JRys]

You can use pin 51 CLKI to drive data collection. For this you need to include the ULx Timing vi. If you also want it to be the source for a counter, physically wire it to both the CLKI and the counter input. What you cannot do is use a counter to divide a signal and then use that signal to external clock everything. It's a catch 22 situation.

Best regards,
John

 

[gmag]

Hi John, 

Thanks for the response. When I try CO Pulse Ticks with external clock I get the following message. Does USB-CTR08 support external clock? When you say CLKI, I guess you meant to say Pin 53 (51 is TRIG IN). 

Thank you

[JRys]

The Counter Output (aka timer) isn't part of the input scanning circuitry, so it cannot be used with ULx Timing VI. 

[gmag]

Ok. Thank you John. It is more clear to me now. 

The example you provided on 12/28 was the key in resolving my issue.

Instead of Dev0/Co0 generated signal in that example you provided, I used my extrenal trigger source. MaxLimit and OutputRegister1 helped me play with the duty cycle of the freq. divided signal output on COOutput pin.

I could connect the frequency divided signal to the TRIG IN (Pin 51). With that as a start edge (51), I was able to create a gated Ctr0In example (ULx Count Digital Events-Gate Enabled-Output Enabled.vi ) to perform counter input reading. 

Good for now. I understand now that Ci task with EnableOuput TRUE gives the output on COOut pin where as CO uses the onboard clock and gives output only on the TMR pins. That was confusing before. Thanks for clearing that.

 

Thank you

gmag

[gmag]

Hi, 

I have hit another snag with this design.

Attached please find vi and the connections

 

 

Qeustion 1: The counting is based on rate specifed in vi rather than the external trigger rate that might slightly change. I was hoping if I specify the rate > 22 kHz it should take trigger rate that is coming in externally but what is happening is it is decided by the rate specifed instead. So if I specify 40kHz, it is counting at that rate instead of the incomign 22 kHz, vice vesa if I specify 100 Hz, it counts at 100 Hz. I need it to be a slave of external trigger not the value specified for Sample Clock.

Question 2: The second question is regarding the frame trigger generated. I specified a locaiton in the attached vi where you can put a break point. At that location, the frame trigger monitored on the scope is rock solid (decided by max limit 1000 and 500 (output register) with 50% duty cycle and taking in 22 kHz coming externally. However the moment I run through with the loop after for counting, the frame trigger is changing every where which is not right.  The connections are the following

Appreciate any help

Thank you

Gmag

 

ULx Design_8115_v1.vi

[JRys]

Hello,

1. There is no need to declare the active channel in the IOtask because you have already created it in the ULx Create Channel VI. 

2. Regarding the second channel, the ULx Create Channel VI declares channels 1 & 2. You are trying to redefine the channel in the IOtask to be only channel 2. According to your design, there is nothing connected to channel 2.

3. The trigger is a single pulse that starts the acquisition. It will not automatically retrigger if another pulse is sent. 

4. Channel 0 uses gating and the min & max registers, but you have not enabled range counting, so they are not doing anything.

5. Assuming you enable range counting for channel 0 and use channel one as the gate, channel 0 will stop every 45uS (1 / 22000). Channel 0 input frequency is 30M Hz. At this rate, it counts to 1000 in 33uS.  What is confusing is that channel 0 is set to clear on read, which happens every 25uS (1/ 40000).  I am confused about what you need each counter to do.

Best regards,

John

 

 

[gmag]

Thank you John for the reply. 

I will try those suggestions.  The requirement is as follows for your understanding.

If you can suggest the modifications neded from the one I submitted, appreciate it

Thank you

 

Edited March 29, 2023 by gmag

[gmag]

1. There is no need to declare the active channel in the IOtask because you have already created it in the ULx Create Channel VI. 

Deleted it in the attachment

2. Regarding the second channel, the ULx Create Channel VI declares channels 1 & 2. You are trying to redefine the channel in the IOtask to be only channel 2. According to your design, there is nothing connected to channel 2.

Just using Channel 1 for now

3. The trigger is a single pulse that starts the acquisition. It will not automatically retrigger if another pulse is sent. 

That is why I am trying to do start stop in the loop so it will detect the next rising edge (red) for getting the next data set

4. Channel 0 uses gating and the min & max registers, but you have not enabled range counting, so they are not doing anything.

Range Counting? Is that Range Limit ON flag, sorry i dont understand this.

5. Assuming you enable range counting for channel 0 and use channel one as the gate, channel 0 will stop every 45uS (1 / 22000). Channel 0 input frequency is 30M Hz. At this rate, it counts to 1000 in 33uS.  What is confusing is that channel 0 is set to clear on read, which happens every 25uS (1/ 40000).  I am confused about what you need each counter to do.

Hope you understood from the diagram above. 

ULx Design_v2.vi

[JRys]

Hello @gmag

I'm unable to make the USB-CTR count per your requirements. I can make one counter output the 33.33 Hz gate signal (20k Hz / 600) to the other counter, but I cannot clear the 40M Hz counter so that it begins again. This is because the ULx for LabVIEW support is missing the clear-on-gate feature. Clear-on-gate sets the counter to zero when the gate is high. We could use an external inverter chip to invert the gate if the feature was available. This would hold the counter at zero when the gate is low and allow it to count when high. 

Best regards,

John

[gmag]

Hi John, 

Clearing is not a big deal. When I usually get incemental numbers of the count, I can subtract to get actual count.

If you can address the main issues I am good which are

1. C0 task; gating is not working right now. It is counting based on the rate specified rather than the gate. How can I correct it? What is range counting you were talking about and how can I implement it

2. C1 task output should not change with stop and start task of C0 but it is shifting (when you look at the C1Out on scope it is not rock solid). Why? why these counters are affecting each other?

Thank you

gmag

 

[gmag]

Hi John, 

The most critical for me to pursue this board (USB-CTR) is gating and the reason we want to pusue this board is its form factor.

In the example ULxDesign_v2, if you connect two funciton generators 20kHz and 40 MHz (or scaled ones) and feed to C0GT and C0IN respectively and run it, when the rate parameter (specified in vi that goes into SampleClock) is 20kHz, the values are ok it gives me reasonbale output. The moment I change it (e.g. 10KHz or 40kHz), the values are different. What I observed in the experiment is when the actual rate fluctuates between 19.8 to 20.2 kHz (which is possible), the sequenced data output is wrong as it is not taking that into account rather it seems to simply rely on input parameter.

I dont want the task to depend on the rate parameter, it should count everytime it sees a rising edge of the gate signal and it cannot miss even one trigger otherwise the data sequence will be wrong for post processing as it is pattern dependent. If I am doing something wrong and if there is a better way to achieve that, please let me know.

If that doesnt work, I dont think it is reasonable for me to invest more time on this. Appreciate if you could confirm this asap based on which we can make the next decisions as it is getting time critical now.

Other things I can manage (by designing a frequency divider circuit to generate a 33.33Hz trigger and feed into TMR0), not to worry.

Thank you

gmag

[JRys]

I've attached my test worksheet. I used two of the output timers for frequency sources. Wire TMR0 to C0IN, wire TMR1 to C1IN, wire C1O to C0GT, and wire C1O to CLKI. Counter 1 generates the 33 Hz gate signal, and besides controlling the counter 0 gates, it is used as an external clock signal. A sample is recorded on each rising edge of the 33 Hz signal. Unfortunately, ULx uses a lot of buffering, so data isn't returned until about 125 sample (gate pulses) have occurred. Assuming the counter 0 gate works, the data should be the last value recorded for each gate pulse. When the gate is low, counter 0 should be holding its previous value. When the gate goes high, that value is recorded. This is the best scenario you can get using our ULx LabVIEW support. I believe that better device control can be had using the C programming language with the Universal Library.

Best regards,
John

ULx Design_Test_Program.vi

[gmag]

Hi John, 

Thank you. I will give that a shot. I do have LV versions 15 and possibly 20 but not 21. Would it be possible to convert to LV15 (better) and send over if you dont mind.

Thank you

Gopi

[JRys]

I have attached an LV2015 version for you to have a look at.

I hope you have a great weekend.

ULx Design_Test_Program.vi

[gmag]

Thank you. Same to you. Well, if you look at the diagram, the 20KHz is actually my gate (for C0) and 33Hz is my start edge (for C0) that is always correlated to the first of 600 patterns for the task. I think I can still try your example changing it. I will try finite samples with start edge (coming from C1Out) and retrigger C0 (by starting and stopping task of C0 in the loop so it finds the next available start edge to acquire the next set of finite samples).

I will update you on that effort.

Thank you

Gopi

 

[gmag]

Hi John, 

We would like to have the feature of retriggering on the board (RETRIG mode) as 'stop and start' is time consuming and is also losing data in the mean time. It would also be benefiical to have a reference point (start trig) to start acquiring data periodically.

Is it possible to add that feature in LabVIEW?

If not, can you point to the dll (C based) that I could use to make a vi that can work with LabVIEW. I could also wrap a few funcitons in C and make a custom DLL that I could call from LabVIEW if you could provide an idea on how that could be achieved. Appreciate any input on this.

Thank you

Gopi

[JRys]

Hi Gopi,

The RETRIGMODE works in conjunction with EXTTRIGGER. The external trigger is a TTL pulse applied to pin 49 to start the acquisition. Re-trigger is a series of acquisitions with gaps in between. To use this mode, you must use our programming library. The only problem is that you can not mix using our ULx LabVIEW VI library and your custom DLL. 

Instead, reading the 8-bit digital port at the same rate as reading the counters may be possible. It is called composite scanning and should work with USB-CTR08. If you have a TTL reference signal, it could be applied to the digital port as a marker. The composite examples are in a separate folder called \ULx\Composite In. 

Best regards,

John

[gmag]

Hi John, 

I have another question.

So far everything works fine for a single counter but when I duplicate-- meaning need to count two simulatanously, I dont get synchronous data.

Single counter connections 

Signal1 (~1MHz) to C0IN (Pin1); Trigger at which to count (~20kHz) connected to C0GT (Pin2) and also to CLKIn (Pin51);  data collected (continous acq.) works fine.

If I extend to two connections

Signal1 same as above and in addition

Signal2  to C1IN (Pin5); Same trigger at which to count (~20kHz) is connected to C1GT (Pin6)as well with existing connection CLKIn (Pin51),

Data collected from both signals are not in parallel whether I try external clock or internal clock, looks more like sequential, it collects in counter 0 first and then counter 1 later

The question is if the CLKIN (51) works for both counters at the same instance and if both clk and gates can work simultaneously for both counters.

 

Thank you

Gopi

[JRys]

There may be a bug in the ULx LabVIEW support. When I try to configure two counter channels with different range counting parameters, they both take on the settings of the second device. I will continue to investigate and update this post when I have more information.