07-23-2019 05:33 AM
@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
07-23-2019 10:40 AM
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
07-23-2019 04:11 PM
Phil,
Thanks for clarifying. So why isn't it working properly?
BS
07-24-2019 02:39 AM - edited 07-24-2019 02:55 AM
@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.