Problems with autonomous in deployed vs run mode

[Jon236]

We have used the Autonomous Iterative mode for our auto code.  It runs just fine when we 'run' it from the PC.  But when we build and deploy the code, it will not work.  Has anyone else seen this?  Have any ideas what might be causing it?

Thanx in advance!

Jon Mittelman

[OliviaC]

Hi Jon,

When you say it "runs" on the PC, do you run just the Autonomous VI or do you run Robot Main?

In your Begin VI, did you select to have the Interative mode run?

~Olivia

[Jon236]

1.  run from Robot Main.vi

2.  Begin is set to iterative

[nathand]

Hi Jon - are you certain the problem is building versus deployed, and not something related?  I helped a team at a regional event this past weekend that said that their autonomous mode worked fine during testing, but wouldn't run in a match.  We found the actual problem was that when they were testing it, they always went into TeleOp mode first (to run the compressor to pre-charge an air tank) before going into autonomous.  For a match, they would pre-charge the tank, turn off the robot, take it to the field, reboot, and go directly into autonomous.  It seems that they initialized something in their TeleOp mode that needed to be set in order for autonomous to work.  Is it possible that your problem is similar?  Can you think of anything else that might be different between the way you run your autonomous from the computer, versus the way you run it when deployed?

[Jon236]

We run it the same way, whether deployed or 'run'

first teleop, then autonomous, disabled in between

[Jon236]

We finally solved the problem....from Nate Lim, a professional LV programmer on our team:

"Essentially the issue that we had was that I had an enumerated typedef control in the VI, and I used a property node to get the item name strings to use to convert input strings into the enumerated type.

When we ran this from the LabVIEW environment (targeted to the cRIO), it worked fine, but when deployed (standalone on the cRIO), the conversion did not work properly."

The solution was to use a constant for the enum.  The apparent cause, according to Greg McCaskle, is that when you build your app, the typedef is stripped away.  This is a default build spec, which can be changed.on the Additional Exclusions page.

[nathand]

Jon236 wrote:

We finally solved the problem....from Nate Lim, a professional LV programmer on our team:

"Essentially the issue that we had was that I had an enumerated typedef control in the VI, and I used a property node to get the item name strings to use to convert input strings into the enumerated type.

When we ran this from the LabVIEW environment (targeted to the cRIO), it worked fine, but when deployed (standalone on the cRIO), the conversion did not work properly."

The solution was to use a constant for the enum.  The apparent cause, according to Greg McCaskle, is that when you build your app, the typedef is stripped away.  This is a default build spec, which can be changed.on the Additional Exclusions page.

This is not quite right.  The problem is the use of a property node, not the use of a typedef.  Changing the build properties to maintain the  type definition link will not fix it.  Many property nodes rely on the front panel.  When you build an application for the cRIO the front panel is removed, so property nodes that need the front panel return an error in a compiled application.

See the following two links:

Unsupported LabVIEW Features (RT Module on VxWorks Targets)

Why Is My Executable Not Running As a Startup Application in an RT Target?