outputting random boolean values

[Aniket]

Hi

I am working with PCI 6259 and LabView 8. I am interested in developing the following application: control 12 solenoid valves such that
1. For a period of 50 ms, any solenoid is either on or off, the booloean value being chosen randomly with a fixed probability.
2. At the end of this period, reset all the solenoids to off for 50 ms.
3. Repeat 1 and 2 for a long time (several minutes).

I have written a preliminary piece of code that tries to generate boolean random numbers once and writes them to digital output channel and I get the following error:

Error -200609 occurred at DAQmx Write (Digital 1D Bool 1Chan 1Samp).vi:2

Possible reason(s):

Generation cannot be started, because the selected buffer size is too small.

Increase the buffer size.

Selected Buffer Size: 1
Minimum Required Buffer Size: 2

I am attaching this code here.

[RavensFan]

I couldn't run your VI because I didn't have Get Terminal with Device Prefix nor Digital Data Generator.

What I did notice is the Digital Channel DaqMX write is set for 1 channel 1 sample, but your are writing an array of Booleans which would imply multiple channels.  Perhaps you want 1 channel multiple samples?

[Aniket]

Here is another VI that outputs a waveform of the same values: the problem remains. I cannot output anything using # of samples =1.  The device asks me to increase the buffer size.
The fundamental point is to be able to generate random values at each iteration and be able to set them back to zero at the end of the iteration and so on. Suggestions other than this particular piece of code are welcome too.

Aniket

[RavensFan]

It looks like the DWDT signal generator is creating a 2 signal by 1 sample array.  However, the resulting waveform goes into a 1 channel N sample digital write.  Perhaps you want to set the controls to be 1 signal, 2 samples?  Or set the digital write to be N channels N samples?

Put an indicator on the output of the property node that feeds into the #of samples of that signal generator.  I simulated a DAQ card in order to get the VI to run.  Perhaps rather than using the property node, just set the value to 2 with a constant.  Of course that will make the 2nd sample to be random as well and you said you want it to be false.  So instead append an array of false values to the array that comes out signal generator array.

Also, you say that you want to generate random values at each iteration, but in the structure of your code, you generate the random values only once at the vary beginning of your code.  Then those same values are output continuously until the code ends by hitting the stop button.

Message Edited by Ravens Fan on 07-30-2007 11:35 PM

[Aniket]

Hi RavensFan,

Thanks very much for your suggestions. I implemented a version of what you suggested. However, I see the following error.

Error -200462 occurred at DAQmx Start Task.vi:4

Possible reason(s):

Generation cannot be started, because the output buffer is empty. 

Before starting a buffered generation, write data. Unreserving a task empties the buffer. Changing the size of the buffer or setting the Regeneration Mode property will result in the buffer being unreserved and emptied.

I am attaching the code with this. Please take a look and let me know what can be done.

Aniket

[RavensFan]

Before, you had done your Daq MX writes before you had started the tasks in the sequence structure.  Now you are starting the tasks and don't provide it the data to write until you get into the while loop, thus it doesn't know what data to write when the start task first starts.

What exactly are you trying to do?  You had said earlier you wanted to control 12 valves randomly either on or off for 50 ms and then off for 50 ms and that this would happen for 1-2 minutes.  Do you want the 1-2 minutes to be determined by the user or by the code?  Do you want the pattern to be randomized every 100 ms (first scenario, which makes the most sense to me) or randomized once and repeated for those few minutes.  (But in this 2nd scenario, an off for 50 ms and off for 50 ms pattern doesn't seem like much of a test.).

I am going to assume you want the first scenario.  Put a DaqMX write prior to the start task to essentially "prime" the data output buffer, it could be an off-off situation, it would only execute once anyway and is likely the natural situation of having the valves off with them just sitting there before the program starts to execute..  Once the task starts, then your data loop would randomize the behavior from then on to forever or until the user hits the stop button.  If you want the program to determine exactly when to stop, this would be just a matter of adding a little more code with some "Elapsed time" vi's.

[Aniket]

Hi Raven,

Sorry for the confusion. I do want to randomize every 100 ms.
I tried your suggestion to the best of my knowledge. One clarification: I intend to implement this for 12 solenoids, but for testing purposes I have only 2 lines, so that I can see it on the oscilloscope. There is the following warning message, in addition to seeing an all-zeros output only. Changing the all-false to all-true makes it output 1-0 on both lines forever. Thus, the write VI inside the loop has no effect. I am sorry but I do not yet understand how to avoid this.

Warning 200015 occurred at DAQmx Write (Digital 1D Wfm NChan NSamp).vi:1

While writing to the buffer during a regeneration, the actual data generated might have alternated between old data and new data. That is, while the driver was replacing the old pattern in the buffer with the new pattern, the device might have generated a portion of new data, then a portion of old data, and then a portion of new data again.

Reduce the sample rate, use a larger buffer, or refer to documentation about DAQmx Write for information about other ways to avoid this warning.

Your suggestions would be most welcome.

Aniket

[RavensFan]

I would recommend putting in a few temporary error indicators to see where the error is occurring.  I am guessing it is the one inside the loop but perhaps it is the first Daqmx write.

I would look into the All zeroes waveform VI.  There is a lot of extra code in there.  There is the outer for loop that only runs once.  That shouldn't cause a problem.  But there is a lot of array manipulation going on.  I wouldn't build array, insert into array, then build array again.  This creates a 2-D array which you then transpose, the convert into a waveform and convert into an array of waveforms.  I am not familiar with the Build digital waveform VI, but I don't see why you would want a 2-D array for it to create a single wave form.  In the front end just create a 2 element constant array with both elements set to false.

The error code you are getting isn't good, but it may not be a huge problem either.  It sounds more like a warning that data may be overwritten in properly because new data was put in while the old data was sent out.  I don't think this is a practical problem in your application because I would guess it would only happen on the first iteration.  You may just want to clear that specific error and allow the code to move on.

If this is a problem that occurs on every iteration, maybe it would be a good idea to build a longer randomized array of booleans up front, and interleave that array with an array of falses for your off condition.  If you know how long the cycle needs to run, you could create a large enough randomized array.  Then build that into a waveform that you write to the daqMX only once.  And even if it runs longer and the array repeats every few minutes, that should still be an effective enough randomization for your situation. 

I don't know if any of this will solve your problems with the errors, but it might give you different ways of looking at it.  I would also recommend cleaning up the wiring a little bit.  Some of the wires are starting to get overlapped, and in the clear task VI's at the end, the error wires get overlapped and the 2nd one shown actually goes first.  I would rearrange them or rewire those error wires in series.

I had a little bit of a hard time in downloading the files because now it is asking for boolean waveform array 1.vi,  I had boolean waveform array.vi, but it seemed to be slightly different and caused a broken arrow on the top VI.

One other question I have is that your default sample rate is 20 and that goes into the all zeroes waveform and in the dt of the build digital waveform VI.  So I think that would mean 20 ms.  But I thought you wanted the period to be 50 ms on/off then 50 ms on.  So that would be 20/sec rather than 20 msec.  May not be an issue for the "priming" of digital output buffer, but maybe there is an issue with consistency of the rate causing a problem.

Message Edited by Ravens Fan on 07-31-2007 04:57 PM

[Kevin_Price]

I'm not near a LV PC and can't look at code.  You're getting great help from Ravens Fan, I just wanted to add a thought or two.  I'm thinking maybe your app doesn't demand as much complexity as you're approaching it with.

- How critical is the 50 msec timing?  Does it have to be hardware-timed for high precision?  Or could you consider software timing that will usually be within 1-2 msec, but may occasionally be much longer?   The app would be simpler to program with direct software-timed digital output, but the timing precision would suffer.

- Any DAQ output task where you write to the data acq buffer (with DAQmx Write) immediately before that data is due to be generated as hardware signals will be prone to errors such as the one you're seeing.  It's really the same issue as above -- the software timing isn't reliable enough to exactly keep pace with the hardware.  The typical solution is to write to the buffer farther in advance of when the data needs to be generated as hardware signals, like maybe a second or two. 

- You said you need to re-randomize every 100 msec.  If truly random, then it doesn't correlate to anything happening during program run-time.  Thus, all the random patterns could be pre-computed and you can pre-write much or all of it to the data acq buffer before starting the task. 

   Am I understanding you right?  It doesn't matter *when* you calculate the random pattern, only that those different random patterns start every 100 msec with a 50 msec duration?  If so, you could probably make this a simple finite acquisition operating at 20 Hz (probably using one of the counters as the sample clock).  Even for 10 minutes of pattern generation, that's only a buffer of 12000 samples.  That'd be no problem for DAQmx to handle as a finite output task.  You could go hours if needed.

(P.S.  Note also that with 12 valves, only 2**12 == 4096 patterns are possible.  There are fairly easy ways to pre-define a pseudo-random sequence of those 4096 possible patterns that hits them all exactly 1 time.  You could perform a continuous acquisition and only write those 4096 patterns one time then let them be regenerated in hardware for as long as you want.)

-Kevin P.

[Aniket]

Hi Kevin,


You said you need to re-randomize every 100 msec.  If truly random, then it doesn't correlate to anything happening during program run-time.  Thus, all the random patterns could be pre-computed and you can pre-write much or all of it to the data acq buffer before starting the task.

--- Indeed. The first thing I tried out was to write a pattern to a waveform file. I ran into problems with reading the file. May be I should revisit that idea.

Am I understanding you right?  It doesn't matter *when* you calculate the random pattern, only that those different random patterns start every 100 msec with a 50 msec duration?  If so, you could probably make this a simple finite acquisition operating at 20 Hz (probably using one of the counters as the sample clock).  Even for 10 minutes of pattern generation, that's only a buffer of 12000 samples.  That'd be no problem for DAQmx to handle as a finite output task.  You could go hours if needed.

--- Right again. I will give that a shot.

Thanks very much.

Aniket