From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 200077

Solved!
Go to solution

Yes, I have tried this thing, it's happening but suppose my programming will run for 15 sec and I need somewhere a 1 ms pulse then what should I do? I have to set the sample rate at 1000 (for timing precision 1 ms) and give the data in 15*1000 format ?? That will be horrible. Is there any other thing that can be done to avoid this problem?

0 Kudos
Message 21 of 44
(992 Views)

Basically, no, there's no "other way".  That's just how it is when you work with buffered, hw-clocked tasks -- you have to define an output value for every sample throughout the acquisition.  15 sec at 1000 samples/sec *would* be horrible if you define your data by manually typing each sample value into a front panel control.  But you don't have to (and shouldn't) do that!

 

Following the process I described up in msg #20, you could use a few instances of "Initialize Array" with the appropriate # samples and the correct boolean state.  Another method I've used when the pulse widths don't matter, only the rising edge times, is to pre-initialize a boolean array as all False then selectively place Trues at the indices where you want a rising edge.

 

There are then some functions in the waveform palette that help you transform boolean arrays into digital waveforms for use with 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 22 of 44
(985 Views)

Thank you for your suggestion. I have tried this code now synchronization is a problem. I am attaching two Vi s. One of them is named "digi with sample clock not synchronized.vi" that is the normal program if you run it you can see the outputs are not synchronized. But in the 2nd Vi I tried to synchronize this two-channel but somehow it is not happening no error is showing but there is no output in the oscilloscope. I will be grateful if you help me out. 

0 Kudos
Message 23 of 44
(973 Views)

Back in msg #18 I linked to a illustrative example that shows a way to share a sample clock between tasks.  Check it out and try to follow the pattern shown there.  Neither of the vi's you posted showed any attempt to do so.

 

Further, it's almost certain that you should be configuring DAQmx Timing for finite sampling (as I suggested at the end of msg #20).  What you're doing now is a crude attempt to limit a "continuous" hardware task using a far-less-precise software timing operation.

 

Also, spend a little more time with some of the simple shipping examples.  Several things you're doing look kinda haphazard, like you've only had minimal exposure to the functions and methods available to you to do things more cleanly.  That's pretty normal when just getting started, but understand that there's a fair bit of work for you to do to get through the learning curve.  I can answer some questions and give some nudges but won't be travelling along with you every step of the way.

 

I'd need quite a bit more info before I could say much about your specific sync questions, starting with an understanding of what sync'ed signals would look like and what you saw instead.  But unless you use hardware timing signals (such as a shared sample clock) to accomplish that sync, it's no surprise to me that it didn't happen.

   The other thing of note was that in both vi's, you wrote to your DO task first and then started it (correct order).  But your AO task started first and then you wrote to it (incorrect order).

 

Finally, for both your sake and anyone who helps, please put some effort into neating up your wiring.  For example, keep each task's task refnum and error wires lined up with no vertical wire bends.  Minimize other wire bends where possible.  Just a little bit of effort at these things makes it quite a bit easier to follow and understand the code.

 

 

-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 24 of 44
(963 Views)

Actually, I was going through this community forum for this synchronization part there one of the solutions was the same as what I tried in the previous Vi. And yes this bending and all point what you pointed out that I will rectify and I was trying as you have suggested in #18 but maybe there is also something I messed up. And what you said the incorrect way for the AO task, if I write first and then start it was not working so I tried this thing and it was giving output maybe it is the wrong way I will try again. And also I will go through the example you have shown and try this thing a little more then come back to you. Anyway, thank you for the suggestion.

0 Kudos
Message 25 of 44
(954 Views)

Sorry to bother you again, I was going through the example you mentioned and tried this time there is a warning showing "Warning 200010 occurred at DAQmx Stop Task.vi". This is because I gave the sample rate of the sample clock very low(maybe) but if I have to increase this sample rate (which is also the time resolution) I have to give many data according to this. I also searched this error and got some link which has been solved by you. There was some Analog input and you fixed it by "DAQmx Control task" in a different way. But here I could not find a way to do it. As there is no one else to help me out can you please have a look and suggest something.

0 Kudos
Message 26 of 44
(943 Views)

A finite sampling task "expects" to acquire or generate all the samples you configure it for.  Stopping the task before the task runs long enough to accomplish all those samples is not typical, leading to the warning.

 

You didn't wire a # samples value into DAQmx Timing so the default value of 1000 was assumed.  At 100 Hz, that would take 10 seconds to finish.  But your software timer only let the task run for about 1 second before stopping it.

 

The solution is to wire the right value into DAQmx Timing.  I slightly modified your code to generate for 1 second by making the # of samples = the sample rate.  I also removed your software timers and instead used DAQmx Wait Until Done, which is the more typical way to wait for a finite sampling task to finish.

 

(Note: under continuous sampling, the # samples input to DAQmx Timing has a different meaning and is often ignored.  Similarly, the default value of -1 for # samples in the DAQmx Read function have *very* different meanings that depend on whether you're in finite or continuous sampling mode.

   Confusing.  You bet!  Kudo my partial suggestion on the Idea Exchange if you agree.  The more kudos on those ideas, the more likely NI is to do something about it.)

 

 

-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 27 of 44
(933 Views)

Thank you sir for the help. As I have written earlier I need 6-8 such channels and they will run for let's say 20 sec. First 15 sec the time resolution should be of the order of 1 sec. But for the last 5 sec or so I need time resolution of the order of 1 ms. As you suggested we should not use two sample clocks of different sample rates rather I should use a single sample clock and the sample rate should be decided at the first. For that I have to give 20*1000 points for my 20-sec program. Manually putting all this value for 8 channels will be a mess. So I was trying to read the input file and feed this as my input to the channels. I have tried to do so but the program is not giving any output after reading for the digital channel and also it is not showing any error.  I need to give this data for both the channel analog and the digital. I am attaching the vi here. Please help.

Download All
0 Kudos
Message 28 of 44
(903 Views)

The following slight mods should help the DO to function:

 

Kevin_Price_3-1629147807153.png                         Kevin_Price_2-1629147553999.png

 

 

1. Explicitly declare that your DO task uses one channel for all lines in the task.  it'll affect what you're allowed to wire to DAQmx Write.  (This might be the default behavior, I'm not sure.)

2. Use the correct delimiter character for your file.  (I changed from Tab to Space).

3. Set the datatype to be read to U8 instead of DBL (because port 0 of a 6361 has 8 lines).

4. Don't bother with the digital waveforms.  Just use your array of u8 values as your samples, timing was already set up in the call to DAQmx Timing.

 

These changes and your file "example1.txt" will produce output on 1 DO line.  To produce output on all 8 lines of port 0, you'll need to encode your desired output as u8 values in your data file.  Each individual bit of the u8 represents one of the 8 DO lines.

 

 

-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 29 of 44
(872 Views)

Thank you for your reply. I have made the corrections but it is showing some errors "Error- 200479 occurred at DAQmx Start Task.vi", so I also tried removing the start task of the analog output and put DAQmx Write channel of the analog output on Autostart True mode. Then It is showing "Error-200010 occurred at DAQmx Stop Task. vi". But in neither case, the output is showing. I also check with the analog channel by making this modification but nothing happens. The modified vi is attached below. In both cases, no error is showing until the last start task, but no output is there. Help me. Thank you.

Download All
0 Kudos
Message 30 of 44
(866 Views)