Program crash caused by NXT Display VI

[Philbot]

Up until recently I beleived that the NXT In/OUT terminals on most NXT VIs were purely for sequencing (when downloaded and run on the NXT) but this week my opinion has changed.

We were debugging some relatively new teleop code and at one point in the program sequence the NXT would seem to lock up.

With some rough debugging, and some insightfull suggestions from the Rachael (new FTC programmer) we discovered that the NXT bus connection order can have a significant impact on program execution.

So this goes out as a warning....

Our Teleop program is two loops...  One for the Communications/Drive train, and another for all the other mechanisms.

The Copilot controls are shared between the two loops using a local variable.

At one point the second loop starts calling a VI calling "AutoBucket.vi" which reads the Arm encoder and adjusts the position of the block bucket servo to keep it level.

When this call was made, Auto bucket would run once, and then the loop would just freeze.  The comms loops still ran fine and displayed the battery voltage.

Fast forward to after much debugging...

As part of the AutoBucket opration it was displaying the Arm encoder, Bucket servo and Joystic positions on the NXT display.

Each NXT Display block was free-standing and had no NXT terminals IN/OUT connected.

See the attached "Causes Loop Lock.png" image.

So this configuration would not run more than once.

Simple soultion... We first found that by deleting all the NXT display VIs the code would start working....  Huh???

Just on a whim, we tried connecting the display VIs onto the NXT bus wire.

The next thing we discovered was that if we just hung the Dipslay blocks off the extising NXT wire we got a File Error crash.

See this code in the "Causes File Error.png" image.

Finally we rearranged the code to put the NXT Display vi's in-line with the other VIs.

This configuration worked fine.  No errors were generated, the loop did not lock and the vi ran as expected.

This code is shown in image NoError.png.

This was quite a revelation to me.

I was hoping that it was just the Display VI, but it later occured on a basic "Touch sensor" read.

I had just left the sensor-read floating in the VI (not connected to any NXT wire), and I got the loop lock again.

So now I'm going through all my code and connecting all the NXT VIs in series....

Am I paranoid?.... perhaps, but if you are like me, and don't connect all the NXT VI's, then you may want to start.

Is this a "Known error"?

Phil.

[Tunde_S]

Hi Phil,

The NXT In/Out terminals are mainly for sequencing NXT VIs, as stated in the help document (or context help) for the VIs that use these terminals. I tested all three configurations on my end and I did not run into any problems. As a result, I’m not entirely sure why you are running into this problem on your end.

If you only test the code in the code snippet that you attached, do you run into problems?

It sounds like the code snippet that you attached is in a subVI that is in a loop. It could be that this subVI (i.e. code snippet) in the loop is waiting for other instances where you try to write a number on the NXT screen.

By default, the “Number (drawNumber.vi)” is a non-reentrant VI, as defined in the link below.

Execution Page (VI Properties Dialog Box)
http://zone.ni.com/reference/en-XX/help/371361J-01/lvdialog/execution/

As a result, the drawNumber.vi will wait for other instances of the function to execute before it can execute a new instance. If the drawNumber.vi or its low level VIs are running in other parts of your application, then it could cause this loop lock (or delay) that you noticed.

I’d recommend using LabVIEW debugging tools like Highlight Execution, Probes, and Breakpoints to identify the cause of the problem on your end.

Debugging Tools in NI LabVIEW

http://www.ni.com/gettingstarted/labviewbasics/debug.htm

Regards,

Tunde

[Philbot]

Hi

I definately think there is a tie-in to other NXT screen writes in other loops.  It's not clear to me (an experienced programmer) how these will interract.... I wonder how a novice copes.

I find it very hard to run any of the normal debugging tools with the NXT during game play. 

You can't conenct with USB, because of the need for the Samantha module, and WiFi is out of the question.

Running in Direct mode is also out.

Writing to the screen is the only practical way to debug the code in real-time conditions... which is how I caused this problem in the first place 

[Tunde_S]

Hi Phil,

Regarding the issue that you noticed, I'd also recommend placing a Wait (ms) function in each loop to free up some processor resources to allow for more efficient communication between the computer and the NXT.

Regards,

Tunde