LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 200077

Solved!
Go to solution

Respected Sir,

                             I am using PXIe 6361 and PXI-6704 in my system. I want to generate analog output which can be controlled over time. So at first I try to run the "voltage-continuous ouput.vi" program which are available in the Labview example finder . The program is also attached below. Now the problem is when I run this program with PXIe-6361 it is giving result. But when I am trying with PXI-6704 then the error code 200077 is showing. So I cannot understand what is the problem. Its the same code and I select the time source as "Onboard clock" for both the time and also select the output lines correctly. The error code come after the "DAQmx Timing(Sample Clock).vi" subVI.

Please help me to fix this.

Thanking You 

0 Kudos
Message 1 of 44
(1,553 Views)
Solution
Accepted by SUJITniser

The 6704 doesn't support hardware-timed output.  You can only do "static", software-timed output with it.  You can get rid of the error by removing the call to DAQmx Timing, writing 1 sample at a time, and being sure to start the task *before* writing to it (this is the opposite of hardware-timed & buffered tasks where you must write before starting).

 

However, you're then stuck with doing your AO updates with software timing.   This will be fine for some apps, unacceptable for others.  Don't know which kind yours is.

 

 

-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 2 of 44
(1,523 Views)

Yes sir , I have tried this and the above problem is resolved but now the new problem is I cannot go beyond 18ms time resolution. Is that the normal labview software which restricts the timeline resolution? What are the possible solution to get like 1ms time resolution. I was using "wait(ms)" for the timing part. 

0 Kudos
Message 3 of 44
(1,418 Views)

LabVIEW is certainly capable of even sub-millisecond timing, depending on the environment, so I'm going to say that the environment, your coding, or both, is the issue.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 4 of 44
(1,412 Views)

Thank you sir for your prompt reply. I am using PXI 1071 and PXI 6361 for this digital signal generation and using windows 8 platform. So can you please tell more about it so that I can detect the mistake and rectify it.

0 Kudos
Message 5 of 44
(1,404 Views)

Remove all the task stops and starts you have between the time queries, leaving you with just one start at the beginning and one stop at the end.

 

Once you start the task, it stays active and you can change your outputs just by making a series of calls to DAQmx Write.

 

 

-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 6 of 44
(1,400 Views)

Thank you for your reply. But I have tried this also here I am attaching the vi for your reference but there also the time resolution is not improving. Please help me.

0 Kudos
Message 7 of 44
(1,382 Views)

 

Right now all the controls have meaningless or empty contents.  Try running your program again with reasonable values in all the front panel controls.  Then go the menu and choose "Edit->Make Current Values Default".  Then save and re-post the vi.

 

Note that it isn't necessary (and may not be sensible) to write digital waveforms to a software timed task.  

 

I also just remembered a previous discussion here where we seemed to discover that calls to DAQmx Is Task Done? were surprisingly slow.  There's mention of being limited to "60-ish" calls per second to that function, which corresponds to about 17 msec.  Try removing all those functions from your loops.

 

 

-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 8 of 44
(1,362 Views)

Thank you sir for your reply. I have done what you have said to make the default values and I am attaching the VI here please have a look and suggest some solution.  And if the Task Done is slowing down the program then what should be used to avoid this problem?

0 Kudos
Message 9 of 44
(1,351 Views)

I have tried by omitting this Task Done and just put the DaqMx Write in the while loop where I adjust the time. So now it is working and the time resolution is of the order of 1ms. So is this code efficient or I should try other things to improve my program. The Vi is attached here.

0 Kudos
Message 10 of 44
(1,347 Views)