I've run into a, for me, rather weird problem: a part of my VI should get data from a force sensor for further use. But this works for most of the time only if I put a probe in the error canal of this part (I've attached a picture of the exact location), without the probe, the SubVI crashes and returns a constant 0. Slowing the execution down with a timer didn't change anything.
This only happens if I run the VI with LabView 2012 under Windows 7, but works fine (without the probe) with LabView 2011 under Windows XP on an other (slower) PC.
Is this any kind of known problem?
Thanks for your help.
This also sounds like a possible race condition. The presence of the probe may slow the execution enough for things to work.
@Gerd: It's returns a constant 0 (contrary to what it should do, that is, fluctuating around 0), I'll get the exact error message on Monday.
@Mark: We thought of something like that and tried to fix it by placing timers on different places to slow the execution down, but that didn't help. What would the standard routine be to fix a race condition? Also, we can't slow it down by too much, as we need the force value in about real-time because the experiment is force-controlled.
You fix race conditions by eliminating local/global variables and property nodes. You have to pay attention to dataflow and operations executing in parallel. All that you have done is post an image that is hard to read. Post the actual VI or the correct type of image - a snippet (look it up in the help).
Besides the advice above it should be noted that placing arbitrary delays in your code is not a very good way to address race conditions.
What's happening in the VI immediatley before the probe? It looks like your problem is coming from there. This would be easier if we could see your code and not just a picture.
Here are the snippets (which turned out a little weird, I think) of the way from the initialization to the SubVI in question and the SubVI itself. If necessary, I can also provide snippets for the other existing SubVIs.
@Gerd: Concerning one of your initial suggestions, I've reproduced the problem now and it turns out it isn't a real crash, but the SubVI changes its status rapidly between "running" and "waiting to run".