Race condition?

[walter-donovan]

In the "capture" event, do I have a race condition? Is acts like one, giving values for one task one time, and values for the other task other times.

The start and ref triggers are pulses taken from a rotary encode. Z = 1/rev, A = 360/rev.

I am trying to sample positional data 360 times in a rev, and RPM data once each rev. The encoder is fed into a freq-to-voltage converter which outputs voltage proportional to RPM.

These 2 tasks start simultaneously but un at different speeds. Is that fact causing a race condition? I thought he loop would not complete til all data is taken but it seems to randomly execute one task or the other, never both.

This is just a one cycle capture to check hardware before testing. The actual testing (in another module) will read RPM every rev and position every degree for an 8 sec test so the flow should be the same.

[RavensFan]

Are you getting errors on any of your error wires?  It seems like you could be but the data is getting thrown away.  And shift registers on error wires is often a bad idea.

It looks like you have two different tasks using the same DAQ device.  That will lead to a -50103 error about resource reserved.  Which task runs first will work, the second task to run will throw the error.  And it is a race condition as to which runs first.

Look for errors on the error wire.  And combine the two tasks into one.

[JÞB]

yes you do!

The order these two functions fire  in is indeterminate (no data dependancy)

Create the tasks once.  control the range with a task property node

[walter-donovan]

Thanks guys. Yes I do get error 50103 but I must have missed that I get it all the time. I thought it was only in one, not both situations. OK I can combine the tasks into 2 even though one only needs 1/360 the data points as the other. It will waste memory but I can read every degree using a multichannel read then discard the data that I do not need.

About clearing the task. I thought this was necessary. Take the situation where I am running this program, set the configuration then go back to change a variable. I thought I always had to clear a task before recreating it. Is it feasable to do it the way I am but within a sequence frame to eliminate the race cond? I've never used scope and am less comfortable that way unless of course it is necessary.

[crossrulz]

Something I just noticed.  You need to move all of the terminals for the configuration into the config event case.  This is a race condition.  Basically, the terminals are being read and then the while loop will pause at the event structure, waiting for one of the events to be triggered.  While the wait is happening, you change all of the settings and hit config.  Guess what.  You are going to setup based on the previous settings because the terminals were already read.  So, again, move all of those terminals inside of the event case they are used in.

EDIT:  Nevermind.  I just noticed the 50ms timeout being used.  Note:  You don't need both the event timeout and the wait.  The timeout will work as the wait.