error 200294 in Daqmxstart task

[DianeS]

Which FOR loop, the one I posted in my example?

No, it doesn't...it uses "Replace Array Subset" to replace an element of an 8-element array.  So what exits the loop via the shift register is still an 8-element array, with 2 of the all-zeroes waveforms replaced with waveforms containing sine waves.  That's the whole idea behind preallocating the array and then replacing elements of it.  The array stays the same size.

Here's a further scaled-down version of the FOR loop I originally posted.  Play with it.  Note that you start with an 8-element array, and you finish with an 8-element array.  If you're starting with an 8-element array and ending with a 10-element array, you're doing something incorrectly.

Keep at it!

[ritch_by_nature]

My mistake. I fixed it. During the replication I used an insert into array instead of replace array. Thanks a lot Diane. You're the best.
When I tried to clean up the code and synchronize the daqmx read with daqmx write by feeding the error of the write start task to the read start task then feed the daqmx read error to the daqmx write error and feed the daqmx write error to the write clear task then feed it That to the read clear task. I get error 200621 again.
With the original code it having them unsynchronize it works fine.

[DianeS]

I'm pretty sure you have an example that showed you how to synchronize your AI and AO, correct?  Look at that example again.

See how the error output from DAQmx Start (after DAQmx Write, outside the loop) is input to the DAQmx Start (again, outside the loop) for the DAQmx Read task?

See how, inside the loop itself, they are separate error wires again?

Think dataflow!  You need those tasks to run IN PARALLEL inside the loop.  So don't wire them up in series, as you described in your post.  The only functions you want wired up in series are the DAQmx Start functions.

Go look at your synchronization example again, and you will see what I mean and what I was trying to tell you in my earlier post on the subject.  I only said the Start functions should be wired in series.  Not the Read and Write functions inside the loop.

You're getting there, though!

[DianeS]

Ah, wait, I see why you thought you should only have 1 error wire in that loop -- I put it in an earlier post.  My apologies.  I was looking at your bottom loop when I wrote that.

I can't remember if there's anything in your TCP loop which needs to run in parallel...I will leave it up to your judgement.

DAQmx Read and DAQmx Write do need to run in parallel, so you will need separate error wires for those functions.  You can either bring in a single error wire and branch it, or bring in two error wires.  Your choice.

Apologies again!

[ritch_by_nature]

No apologies needed! i bring in one error wire from the read start task and feed it to both write and read daqmx and have them running in parallel after that. My TCP read and write are in the state machine. not running in parralel. my queues are of course. 

My problem is few occasions, I fire up the server, it gives me that error 200621, then I run the client regardless. then shut them both down and rerun the server and it works fine the second time around. cant figure out whats causing that.

I seem to experience delay issues. and also the axis selection is not acting how I would want it.

Take a look at my client if you may.

Admin Note - Attachments removed per user's request

[DianeS]

Hard to say what's going on without the complete picture, but again I will make a guess.

As I understand your code, the clients generate the data items which are used by DAQmx Write.  Your TCP loop receives a data item and enqueues it up to the DAQ loop.  Am I correct?

Your TCP loop will wait until it receives something before enqueueing it, of course, and you've handled the possibility of TCP timeouts.  So that's fine.

Now, the Dequeue function in your DAQ loop is set to time out after 10msec.  I'm guessing that sometimes it requires more than 10msec for you to fire up your clients and start generating data items.  Therefore, when it takes more than 10msec for your clients to start sending data items for DAQmx Write to generate, that Dequeue function is timing out.  This probably happens on the first iteration of the DAQ loop.

So let's have a look at your DAQ loop.  That shift register to which you are passing your data item when you receive a valid one is uninitialized.  So the first time you run your server, it contains...what?  Nothing.  So what are you trying to do?  Write an empty array to DAQmx Write.  We know that doesn't work.

Then you run the client, and you start transferring data items through that queue.  Now that shift register has data in it.

So then you terminate both programs, and start them again.  I am guessing that you haven't closed the VIs, just terminated them.  Therefore, next time your server VI runs, it has not actually left memory yet.  So the uninitialized shift register holds its value, and all appears to be well.

Try initializing that shift register with a valid data item and see what happens.  Your DAQ loop is reliant on that shift register containing valid data (so that you won't be messed up if your Dequeue function times out), so you need to guarantee that it contains valid data all the time, including upon startup.

Give it a whirl and we'll see how it goes.

You'll need to be more specific about the axis selection not acting how you want it...I have no idea how you want it to act, nor do I know how it's actually behaving, so I can't help with that one.  🙂

[ritch_by_nature]

Thanks for your rundown and the first issue.
What I mean by the axis selection is that. When I select an axis that's has a waveform it works fine. But if I select multiple axes some affected by the waveform others are just noise. I either get a display of noise or a display of the same waveform on all axes. The vi that's is in charge of doing that is sensoraxischopped.vi. If you remember from previous comments my goal was to select a sensor and display the 3 axes of that sensor then give me the option to select which axis to display on the screen. But when I select more than one sensor then select 3 or 4 axes. The axes selected are not displaying what they're supposed to display.

[DianeS]

Have you tried using execution highlighting on that VI to try to figure out what's going wrong and why you're not selecting data the way you expect?

Also, your tendency to not show terminal labels in your block diagrams is giving me anxiety.  A terminal with no label makes your code very difficult to read.  You're getting better about wire bends, so that's good, but I still see unnecessary bends in there.  Straighten 'em out!  🙂

[ritch_by_nature]

My problem is since i need valid data for that shift register and valid data only come from the client. how do i even feed that shift register valid data when the server is not on.  or do I just feed it a defalut valid data.

[DianeS]

Initialize the shift register with a default valid data.  If you don't want to write any waveforms until the clients start executing, then create your default valid data such that you write waveforms containing all zeroes.