Probes (and some other aspects) not working

I’m experiencing an intermittent and annoying issue.

For some reason, in some (not all) of my VIs, the debugging probes list “Not Executed.” I am certain that the VI itself is running, since in particular my drive code is having this problem and the robot is still mobile.

In addition, some of these VI’s have the task of updating some global variables. If the VI goes from a working state into this “Not Executed” state, it appears to stop updating the global variable, and code that reads from that variable finds stale (unchanging) values.

In some cases, this problem only applies to some of the code in a VI. In my drive code, I have two main loops. One loop reads from globals and sets motor outputs, and the other loop reads from gyros/encoders and publishes that to a local variable. Everything in the drive loop shows “Not Executed”, but in my sensor loop one of my encoders has a reliable probe, even though all the other encoders/gyros show “Not Executed.”

The best reference I found online was a list of things that were fixed in LV 2011:
ID, Legacy ID, Fixed Issue
255014, —, Probes are listed as Not Executed intermittently on Real-Time target

This is especially painful, since one of the things I like about LabVIEW is the debugging =

Any idea what this is?

Debugging can be turned off in a VI, and marking a VI as reentrant also impacts which debugging features are available and how they work.

From your description, I can’t be sure if these are involved.

Try putting another indication, such as a display on the panel, and update it from the same wire as the probe. If neither one updates, work your way back to see if logic is truly preventing the code from running. If the indicator updates and probe does not, then it truly sounds like a bug in the way the probe is implemented.

Greg McKaskle

Can you post a picture of your diagram code? I’m going to guess something is keeping that code from running.

Hello Everyone,
This year we are getting our Kit late because of some issues with customs. Because of that, we are spending some much time with thinking and will practice on last year’s robot. In order to practice, we do need Labview but our labview has been expired. What else can we do to find labview. Is there any link that you can give us to download ?

greetings,
Labview is in your kit,hopefully. It is a package that looks like it should hold a CD. When you open it, you will find a credit card size device that is a USB drive. That contains Labview.

They do not have their Kit, so they are looking for a temporary stop-gap solution.

Failed at reading comprehension there, sorry.

You can get the updates online and you can get a regular version of Labview as well, but you cannot get the FRC version of it online as far as I can find. I’ve been looking because i MIGHT have misplaced my copy. Those cards thingies are cool but way to easy to put then in a pocket and forget where it went…

Has anyone tried applying the downloaded FRC update onto a standard 2011 Labview?

If this worked it could be a stop-gap.
There’s probably an eval version of 2011 available.

Just wondering…

My experience is that "Not Executed… means “Not Excecuted since you created the Watch Window.”

eg: If you run the program and then put a watch window inside the BEGIN Vi, it will say Not Executed. However, if you then stop the program, and re-run it again, you will see the existing watch window update.

If you have a watch window in the Teleop VI, and you are driving the robot, I’d certainly expect it to display data. Do you have any Case Structures (for optional driving code). Perhaps these are not running as you expect.

We encountered this bug during Beta Testing and still notice it from time to time. See the thread here: http://firstforge.wpi.edu/sf/discussion/do/listPosts/projects.frc2012beta/discussion.programming_labview.topc2468?_pagenum=1

We mainly use Global Variables that are written in the Teleop/Autonomous.vi’s and used in Periodic Tasks, so instead of using the Probes we just open the corresponding Global instead and it works fine.

I get “The page you requested cannot be found.” Can you copy over any relevant information from that page?

Also, I don’t have access to the code now, but I can try and find the smallest diagram where this issue is occurring so you all can try some visual debugging =]

Ah, sorry I thought they published it to the public after the Beta Testing was over. Here is the transcribed text:

Posted By Post
David Gitz Mentor for Team 1208
11/08/2011 8:28 PM
post6302
LV Probe Issue
Ok, this is kind of a weird one. We are noticing that the LV 2011 Probe doesn’t always display data when it should.
Unfortunately I do not have a screenshot of this happening but I’ve attached a screenshot of the code that causes this.

What happens is that we have some code that builds an array in a while loop in Periodic Tasks. We have an indicator
that tells the size of the array. No matter what mode the robot is in (Autonomous/Telelp/Disabled) the array increments
in size, as it should and does this fine. However, when you probe the line going to the indicator the probe will say "
Not Executed" and will show a value of 0 (greyed out). However, it has worked once. The only verification of this
problem we’ve done is confirm that it happens to every wire in a loop in Periodic Tasks in this Project. We have not
checked this against any other vi’s or Projects, or with LV 8.6

This is definitely not an issue of selecting the wrong indicator or something along those lines. The indicator clearly
increases and a probe on the wire going to the indicator indicates “Not Executed”.

Any thoughts?
Attachment: Probe.png 248.52 KB
Associate QuoteReply
Greg McKaskle (NI Software)
11/10/2011 7:33 AM
post6321
Re: LV Probe Issue
Looks like a bug to me, most likely associated with the new parts of the optimizer. I’ll show it to the lead on 2011 and
see if it has already been reported. Otherwise, he may ask for the code. Thanks for reporting.

Greg Mckaskle
Associate QuoteReply
Greg McKaskle (NI Software)
11/10/2011 2:23 PM
post6328
Re: LV Probe Issue
Would it be possible to email the code to me so that I can attach it to the bug report. My email is [email protected].

Greg McKaskle
Associate QuoteReply
David Gitz Mentor for Team 1208
11/16/2011 10:26 AM
post6483
Re: LV Probe Issue
More evidence on this bug (attached)
The Probe Display had worked at one point (since it’s not grayed out) but since then has not updated. The Drive Global
Variable (which includes the Gyro Angle) is on the right and indicates an angle of -24 degrees, which is continuously
updating. The probe hooked to the wire going into that Global Variable does not update.
Attachment: 1.png 209.08 KB
Associate QuoteReply
Doug Norman (NI Developer)
11/16/2011 12:11 PM
post6492
Re: LV Probe Issue
Did you ever send greg your code? Also, if you can distill this down to a very simple VI, it would be easier to debug.
Associate QuoteReply
David Gitz Mentor for Team 1208
11/16/2011 2:07 PM
post6495
Re: LV Probe Issue
I did, on Nov 12. Attached is what I emailed him. Also, I am unsure what you mean by "distill down to a very simple vi
", as all of the Periodic Tasks.vi is affected. Do you mean something along the lines of creating a new project, and
insert code in until we notice this issue again?

The problem with this approach is that so far this bug is intermittent and occurs throughout the Periodic Tasks, so as
we insert more and more code in the task of actually verifying if the issue occurs or not gets much more time consuming.
From my experience with LV, it doesn’t matter how good/bad your code is, as long as it is running the probe should be
updated. And it is apparent that the code is at least running, so I don’t see the issue as being our code. And
everything in our code works fine, and there are no significant error messages on the Diagnostics. But we will try.
Attachment: Mecanum Practice bot.zip 1.64 MB







Sorry, I did not read your post carefully enough. If your Globals themselves are not updating, I doubt it is a problem with the Probe but instead is in your code. Probe/open up the Drive (and any other applicable WPI Library) functions and see if you are getting Errors in the Error Cluster. Also, make sure to check the Diagnostics Panel on the Driver Station for errors and post back here what you find please.

Ah, there is one more thing I failed to mention.

If you turn on “Retain Wire Values” before running the VI, then everything appears to work perfectly (all probes work). However, if you start with “Retain Wire Values” off and then turn it on during execution, you still see “Not Executed.”

I think that’s another hint that the problem isn’t that the probes aren’t working, but that your code really is only executing once.

I’ll double-check tonight, but I’m fairly certain the code is executing. It’s responsible for moving the robot around, and the robot actually does move around. I tried putting probes just before the “Motor -> Set Output” and got “Not Executed.”

One way or another, I’ll have more information in a few hours.

One other note -

After noticing this behavior, I tried to change my debugging strategy. I placed breakpoints on various blocks (some .vi’s, some just basic blocks) in the code. When the breakpoints were hit, I probed the wires, and saw “Not Executed.”

If you break on a block, shouldn’t the wires that are attached to the inputs of that block be available for probe?

Thanks in advance.

All right, the project is attached. Here is the (in)consistent repro:

  1. Download the code to the robot
  2. Without enabling the robot (you can enable it, this just saves you a step), just go to Robot Main –> Periodic Tasks –> Mobility System.vi
  3. Put some probes around. Nearly all of them say “Not Executed.”

One curious example is the Gyro1, which is updating the front panel, but shows “Not Excuted” on the wire going into it on the Block Diagram.

Any red flags in our code that would explain this strange failure?

2012MainProject.zip (788 KB)


2012MainProject.zip (788 KB)

Is there any sort of logging that LabVIEW does that I can package up (or would something like a memory dump be helpful?)