LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VI only runs with probe

Hello,

 

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.Sondenstelle.png

0 Kudos
Message 1 of 12
(1,975 Views)

Hi Rhazal,

 


the SubVI crashes and returns a constant 0.


 

Does the subVI crash or does it run and returns a zero? That's quite a difference...

Does it return an error with the zero output?

Best regards,
GerdW


using LV2016/2019/2020 on Win8.1/10+cRIO
0 Kudos
Message 2 of 12
(1,945 Views)

This also sounds like a possible race condition. The presence of the probe may slow the execution enough for things to work.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 3 of 12
(1,919 Views)

@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.

0 Kudos
Message 4 of 12
(1,887 Views)
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).
Message 5 of 12
(1,880 Views)

@Dennis_Knutson wrote:
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.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 6 of 12
(1,838 Views)

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.

 

Kelly Bersch
Certified LabVIEW Developer
Kudos are always welcome
0 Kudos
Message 7 of 12
(1,827 Views)

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.

Init001.png

Force001.png

Force002.png

0 Kudos
Message 8 of 12
(1,792 Views)

@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".

0 Kudos
Message 9 of 12
(1,756 Views)

Hi Rhazal,

 

the subVI is either currently called from the mainVI or it is waiting for the next call...

Best regards,
GerdW


using LV2016/2019/2020 on Win8.1/10+cRIO
0 Kudos
Message 10 of 12
(1,751 Views)