Refnum's going away

[LockheedJoe]

I'm opening a several items in the begin.vi and creating references for each of them. This includes a total of 6 motors. I would then get the refnum's in the periodic tasks.vi to be used in various loops for ball shooting, ball picking up etc.

Sometimes some of the loops wouldn't run. I put probes in them and I eventually found that some references were not getting from the begin.vi to the periodic tasks.vi. I would put a probe on the references in the begin.vi and then put a probe on where it was read in periodic tasks.it was in begin and would "not executed" in periodic tasks. I then put all the motor reference into an array and passed the array out of begin.vi through the robot main.vi and to a control in periodic task (no references involved). In periodic taks I would get the references out of the array. Some would be there, some would not execute. And the loops they go into would not run.

I checked for errors coming out of any of the opens and it always said no error.

Why would it be seen in begin.vi and not all the way to periodic tasks? Is there a limit to the number loops you can have? What can I look at to see what's going on?

BTW, there were a couple of other items this happened on, too. (a Dio and a relay).

Please help!

[nathand]

You are misunderstanding what happened here.  A probe showing "Not Executed" means what it says - that code never ran.  You're not losing references.  If the references were actually lost, you'd see a value in the probe but it would be obviously empty or invalid in some way.  There's some other reason some of your loops aren't executing.  There's no practical limit on the number of loops you can have; that's not the problem.  One possible cause: something on which the loop depends never executes or never terminates.  For example, maybe you tried to pass data between two loops by running a wire from one to the other - the second loop will not run until the first loop terminates.  To pass data between loops you need to use a queue, notifier, "functional global," global variable, or local variable (the latter two are generally discouraged but perhaps acceptable here in the interest of keeping the code straightforward).  Another less likely explanation is that you have a loop running with no wait, or several loops running with such small waits that one of your loops never gets a chance to run.  If these suggestions don't help, can you share the relevant portion of your code (even a screenshot would be useful)?  Running the periodic tasks VI with execution highlighting - the lightbulb in the toolbar - may also help show you what's happening.

[LockheedJoe]

I do understand that when it says "not executed" it's not executed. The probe is on the outside of the loop, between the get refnum and the outside of the loop. The refnum coming in is the item holding up the loop from running. I put a probe on all the get refnums in periodic tasks, outside the loops, as they were going into their various while loops. About 3/4 of the refnums were "executed" and I saw information. about 1/4 of the refnums were not executed before they got to the loops. The loops with the refnums that went through and ran.

The refnums were there (executed with data) in the begin.vi.For some reason the associated get refnum in periodic tasks did not run.

Checking all the loops for waits and checking to make sure the refnum names matched (including capitalization) was the first thing I did. I will try highlighting execution and see if it says anything. Is there anything else I can look for?

[Kevin_F]

Hey Joe,

I also wouldn't put too much stock in the not executed feedback from the probe- with the Robotics Project I get this sometimes even when the code is executing. A more reliable way is to create an indicator on that particular line and run the code in interactive mode and see if the indicator populates with updated values. It is possible you have one loop starving your other ones (you would be able to see this in the CPU usage on the charts page of the driver station) - if you had one loop starving the others I would also expect you to lose connection to the computer since the TCP/IP communication is one of the first things to drop.

If you want you can also post your code up here and I can take a look at it to see if I can tell whats going wrong.

[LockheedJoe]

I have done indicators with the same results, probes are just quicker and easier and you don't have to stop and re-run your code. I may post the code when I get to the computer with the code.

I have waits in all my loops (most at 100ms, one at 20ms for a gyro) what else would starve a loop? The main problem I'm trying to get past is the code not getting to a loop because of no refnum (I did put an error cluster indicator out of the get refnum and it never executed) Unless it's an NI vi doing something behind the scenes that I can't tell what's going on.

How accurate are the charts on the charts screen? I keep the charts screen up as much as possible, sometimes it indicates slow and sometimes it dosen't with the same code. Once, I commented out all vision and periodic processing, only leaving telop (which I did not enable) and it the chart indicated it was running slow.

[Kevin_F]

Anything that takes a lot of processor and doesn't yield to other loops can cause starvation. I find the charts to be pretty accurate here in the office but that's on a limited sample size of computers. If you are seeing that the the controller has high CPU or memory % there I think thats probably an issue.

I would definitely recommend posting your project- its tough to speculate without seeing exactly whats going on.