Quote:
Originally Posted by Greg McKaskle
Are you talking about the actual semaphore VIs in the palette? If so, the issue may be more closely related to leaking the refnums. All I/O handles in LV are shadowed so that aborting or completing will do the close/free operations. And if you leak, that is a lot of resources to shadow. If you probe the refnum and see a unique one each time, you definitely need to close it.
If it is the WPILib Get VIs, which is it you are commenting on.
Greg McKaskle
|
Not to derail the original thread, as my comment about the semaphore VIs was not related in any known way to the issue the OP was commenting on, but we were using the 'Obtain Semaphore Reference VI' from the Semaphore VIs palette inside of a 20hz loop. The semaphore seemed to be behaving properly, protecting the shared global that it was in place to guard, and moving the obtain reference VI call outside the 20hz loop and passing the reference in through a tunnel demonstrably corrected the issue we were observing.