LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Race Condition?

Solved!
Go to solution

@RWPhil wrote:

@Bob_Schor wrote:


Or at least it should work that way (Famous Last Words) ...

 

Bob Schor

By my logic, if the VI is indeed reentrant and blocks in the expected manner, this leaves the wrong input (i.e. the sensor enum) as the source of the wrong data.



Sorry, I wasn't sufficiently clear.  The VI must not be re-entrant -- you only want, at any point in time, one VI to be able to interact with your device.  It says "Hey, I need some data, and I'm going to wait until you give it to me, and noone else can ask you for data, so when you provide data, I'll know it's for me ...".  That's the whole idea of a Semaphore "lock" ...

 

Bob Schor

0 Kudos
Message 11 of 14
(601 Views)

Hi Bob, I think I see where the confusion arose. Let me clarify.

 

What you're describing - a single non-reentrant VI that can be called from anywhere and blocks other callers while it's running - is exactly what I have. This is absolutely essential to avoid having multiple instances of a VI trying to configure and/or read from a single piece of hardware at once. That's just asking for trouble.

 

What I thought was happening was that the VI was blocking other callers but was accepting the wrong enum inputs. A non-reentrant VI occupies a single space in memory that all callers access. I thought if this accepts an input from the wrong part of the software I'd read the output for that wrong sensor in the wrong place, hence my use of a semaphore to wrap the enum also. This isn't what's happening, however, and I can confirm that following more testing your famous last words were correct after all, as expected.

 

Thanks for taking the time to respond,

Phil

0 Kudos
Message 12 of 14
(578 Views)

Phil,

     Thanks for clarifying.  So why isn't it working properly?

 

BS

0 Kudos
Message 13 of 14
(552 Views)

@Bob_Schor wrote:

Phil,

     Thanks for clarifying.  So why isn't it working properly?

 

BS


That's a good question. The simple answer is I don't know.

 

What I can say is that I monitored what was going into the ADC and what was leaving it and the timing of it and, while the inputs were changing every 15 ± 1 ms, the reading output remained constant and from a single channel for much longer, approx 120 ms. Once this time had passed I saw data from the next channel for about 120 ms then the next channel, and so on...

 

I haven't made any special effort to control timings in my modules, it's not critical to the application, and 15 ms should be perfectly adequate for the ADC to handle. I've now added my magic delay fairy (130 ms) and everything seems to be working.

 

Going to have to dig deeper at another time.

0 Kudos
Message 14 of 14
(536 Views)