Error -200685 DAQmx Write Counter Frequency

[OriginalP]

I have to generate 4 finite pulse trains with Counter Output and a X-series board (NI PCIe-6321). I know that with X-series boards only one counter is used to generate finite pulse train. I use LabVIEW 2010 sp1 and DAQmx 9.3.5.

One task for each counter is created.

When only one task runs, everything is ok, but, when more than one task runs, i receive "error -200685: Pulse frequency specified is not supported for this device given the Counter Timebase Rate." from DAQmx Write Counter Frequency. Error reports invalid data: 0,000000

I have checked data supplied and no zero frequency is passed to the VI. In fact, counter frequencies lower than 100 are forced to be 100 through a previous VI.

Thanks for the help

[FatBoyMonchi]

Ho Original,

what is displayed in the probe 8 of the Probe Watch Window in the error screenshot?

Thank you so much,

bye.

[FatBoyMonchi]

Hi Original,

maybe I've found something that can explain your issue: finite counter generation needs two counters to be executed, since one counter acts as a gate and the second as a producer of the signal:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P7eESAS&l=en-US

Bye

[OriginalP]

Hi FatBoyMonchi, thanks for the answer!

Probe 18 displays pulse train frequency data which contains the pulse frequency and duty cycle pairs to write. Duty cycle is constant (0.5) and pulse frequency is variable. I payed attention to write non null frequencies and this is why this error sounds so strange to me.

Normally finite pulse generation requires two counters, but can be performed with only one counter on X series boards (see the note at the bottom of the table).

I asked the support team to investigate my error and they answered to try to update my DAQmx driver.

I downloaded DAQmx 9.7 (https://www.ni.com/en/support/downloads/drivers/download.ni-daq-mx.html#288366) and now... finger crossed.

[OriginalP]

---

OriginalP ha scritto:
 I payed attention to write non null frequencies and this is why this error sounds so strange to me.

---

My last words... i found that two null frequencies (1018 and 1019 array indexes) were passed to Counter Output (see attached images "Counter Output Front Panel Data.PNG" and "Counter Output Block Diagram Data.PNG").

It's quite strange, because VIs generating pulse train frequency data don't output these two null frequencies (see attached image "Array Output Data.png").

This pair of null frequencies is random, but definetively the error is not in Counter Output DAQmx Write VI.

[FatBoyMonchi]

Hi Original,

how many elements are you passing with the Counter Output Data control to this subVI?

Maybe there's some issue in the for loop inside this subVI, that may slow the code and some samples are missing for that?

Bye

[OriginalP]

I measured time required for generating the pulse train and it's very small (about 2 ms).

I did a first attempt by using global variables to pass data instead of DVR and this solved my problem. Now i am using flow data by wire which normally is much better.

 Btw, thank you very much for support

Now i'm having another issue, so i'm going to open another forum thread

[Kevin_Price]

Your screenshot of "Counter Output Block Diagram Data.PNG" shows that you're getting bitten by "floating point equality" issues.

See this article as a starting point to explain.  For what you're doing, a good workaround should be pretty straightforward.  For example, instead of checking for "== 0", you could check for "> 12e-3"  (threshold chosen based on error message which stated a min allowed output freq just slightly less than that).

-Kevin P

[OriginalP]

Thank you for your advice Kevin.

Null frequencies were actually passed to the counter task and therefore the error. I have no idea why there were zero frequencies, since I am careful not to generate them (I generated only frequencies > 100), maybe something like a memory buffer overflow.

However, the problem was solved by avoiding DVR for the data of the counter. Now I'm facing a much bigger problem since labview crashes without any possibility to perform debugging.