FRC2014 problem deploying with UDP write

[joeyoravec]

[cross-posting since this is a much more active forum than usfirst]

Our students are trying to use an AndyMark AM-2645 (link) LED lighting kit. They've programmed the Arduino to accept commands over UDP.

Normally we have no problems with the robot. As soon as we add "UDP Write" to the robot project, build succeeds but deploy fails with an error that the cRIO closed the socket. It's during deploy; their code never actually runs. We've isolated it to adding this one VI. I didn't get a screenshot today, but will soon.

Couple questions:

1. Can anybody else reproduce this error? Is it a bug in the 2014 software?
2. Our interpretation is that R58 (link) restricts the dashboard to certain ports and types of communication -- we must use the cRIO to talk to the lighting controller, and cannot workaround by moving this feature to the dashboard. Are we right?

[joeyoravec]

Adding two attachments:

begin.png: Shows the modification to a default arcade drive robot project. I just added two VIs. Adding UDP Open is no problem. Adding UDP Write exhibits the rpoblem.

screenshot.jpeg: Shows the error message from Labview. The body of that says:

Deploying RT CompactRIO Target(successfully deployed target settings)
Deploying FRC Robot Boot-Up Deployment (failed to deploy)
LabVIEW: The network connection was closed by the remote peer. If you are using the Open VI Reference function on a remote VI Server connection, verify that the machine is allowed access by selecting Tools >> Options >> VI Server on the server side.

[Greg McKaskle]

The error message is somewhat clumsily telling you that you should verify that the TCP interface to the VI Server is opened. I don't really think that is the problem, but it is worth a try.

Also, did your project build successfully? If you perform the smaller steps of build, connect, deploy, which steps work and which fail? Also, what is the IP address of the target in the project?

Greg McKaskle

[joeyoravec]

After beating my head against the wall for a few hours, it "mysteriously started working". Right now I can't get it to fail. See some comments below

Originally Posted by Greg McKaskle

Also, did your project build successfully?

Yes, built successfully no problem. I don't have a screenshot handy to prove it. The example begin.png was the smallest possible testcase that reproduced the problem. I could start with a default project, deploy fine, add two VIs, and deploy would fail with that screenshot.

Originally Posted by Greg McKaskle

If you perform the smaller steps of build, connect, deploy, which steps work and which fail?

Build worked, not sure what you mean by connect, and deploy failed with that screenshot only when the project included UDP Write. As mentioned our normal code (not containing that one VI) and a default arcade drive project (not containing that one VI) would repeatably deploy fine.

We tried various things like cycling the power, rebooting the laptop, multiple known good laptops, and trying to deploy multiple times.

Originally Posted by Greg McKaskle

Also, what is the IP address of the target in the project?

10.12.50.2

Like I said it "mysteriously started working" after a couple hours of testing different things. What I'm monitoring right now:

• Our team has a mixture of systems with the release software (LabVIEW 2013) and which installed the NI Update Service update (LabVIEW 2013 f2). Maybe that was a factor?
• Not sure what the cRIO had originally. Somebody from NI warned us that existing, badly-behaved software might interfere with deploy unless you go into safe mode. I had not tested safe mode.
• I'm not certain if we were / weren't running driver station during all tests.
• This is our spare cRIO. We have no reason to believe it's faulty; but maybe it is.

I've got my fingers crossed right now that this keeps working.

[Greg McKaskle]

Is this an eight slot? They have less RAM, and we have seen teams run out and have odd behaviors. You may want to watch the memory count on the deploy dialog or in the DS Charts tab on the right side.

Greg McKaskle

[joeyoravec]

Yes it's an 8 slot, and thanks -- that is a great idea. We've never checked RAM or flash memory consumption in the past.

[Greg McKaskle]

If you are indeed running out of memory, it is most likely corrupted by the time the VIs finish loading. The easiest solution is most likely to change the ini file to leave out vision processing libraries from the startup list.

Greg McKaskle