code will not download

[apalrd]

I am having an issue where code will not download. I flip the No App switch, reboot, and it will download again. I am already aware of this fix. However, having to flip the No App switch often is not good enough. I spent 1/2 hour of a 2 hour unbag session trying to get the code to download. It simply won't download. I am aware that the No App switch is a workaround, but I would like a solution to the problem. When we designed our machine, we put the cRio way in the middle of the robot under lots of stuff, expecting to never touch any of it except the ethernet port ever again. While it is possible to get to it, it is not in a location that makes flipping the switch easy. With bumpers on (which is almost all the time during competitions and practise sessions) it is actually impossible to see the No App switch, and very hard to get to. It would be nice if NI would fix this issue, as it seems to be a common issue - See http://www.chiefdelphi.com/forums/showthread.php?p=938307#post938307 for many more people who have had the same problem. At Kettering I was next to team Rush (27), and asked their software guys about the issue, and they said they had the same problem. It is not an isolated incident, it is common, and deserves to be fixed. I would send an email directly to NI, but the NI support thing won't let me. It already takes 700% longer than the IFI system to download code, now flipping the No App switch makes this even longer.   As a side note, there appears to be a bug in LabVIEW where placing a probe after the code is loaded but before it is done initializing (when running Robot Main) will cause LabVIEW to crash, which takes several minutes to recover from.

[nathand]

Most likely you can fix this by modifying your code.  If you tie up the processor completely with your robot code, it will starve the thread that handles communication with LabVIEW (which runs at a lower priority), making it difficult or impossible to connect and download code.  I realize you probably can't / don't want to post your code here so I can't make specific suggestions, but do you have any while loops that run without any sort of wait function inside the loop?  That would be a likely cause.

[apalrd]

All of my while loops have a 20ms wait in them, except the main loop which waits in the FRC lib and some autonomous VI's which update at 10ms. I am not running any vision code.

[nathand]

Try increasing the wait times in some or all of those loops.  If you're already overworking the processor then a longer wait time won't affect your robot performance.  You can also try setting some of your subVIs to run at lower priority.  To do this, open the VI, go to VI Properties in the File menu, choose "Execution" and change the priority.  I understand everyone likes their code to run as fast as possible, but I doubt that you actually need anything on the robot to run 100 times per second.

[tsa256]

My team has also had the exact same problem's regarding the downloading and deploying. And we are currently using the dip switch method at the moment. But during our two days of troubleshooting the cRIO way got a vast amount of data points, but due to the inconsistency have no idea what to do.

These data points include all the above symptoms described, but in addition we noticed some very inconsistent code speed. Sometimes we reboot the robot and things will just lag, and this may not seem like anything, but when we power cycled it the code ran at a normal speed. Also, when attempting to run the code as startup while there is currently code on the cRIO it fails about 99% of the time. When it fails and the robot reboots, the status lights on the cRIO blink orange 4 times. Further research on the NI website showed that this can be due to "The controller software has crashed twice without rebooting or cycling power between crashes. This usually occurs when the controller runs out of memory. Review your RT VI and check the controller memory usage. Modify the VI as necessary to solve the memory usage issue." Then thought that is was a coding problem. As a troubleshooting step we re-imaged and then attempted to run as startup the FIRST default code. As we expected the default code deployed the target settings successfully, and that worked flawlessly. Then we attempted to download our code. This failed, which surprised me because if something on the cRIO code related was using too much memory during the deployment why would it fail when deploying out code over the FIRST default code. Our isn't that modified from the FRC structure. Basically what we've done is read drive encoders in a 20ms loop then send those to another 50ms loop. The 50ms loop executes some calculations depending on the global variables sent into and out of the loop. e.g joystick, I/O and encoder values. It then drives the motors within the same 20ms loop. Furthermore, more complex code has been downloaded to the robot with 100% success about 2 weeks earlier. Which would point away from a code problem. Also when running the default FIRST code we get constant watchdog errors when disabling and enabling the robot. Another instance of these bugs are sometimes one of the PWM outputs being controlled by a PID loop will drop out. But this only happens when the process variable of the encoder reaches a specific point. To diagnose the problem I coded a emulation of that control loop, there was indeed one point on the code were the PID loop seamed to just stop outputting updated error. After further investigation this point where it drops out is also a cross over point for the encoder, e.g. The encoder jumps from -2.5 to 2.5. I'm am unsure if this would cause an error, or the PID loop to just stop working. The final data point we've gotten is that sometimes changing one number by .1 or some small value will allow successful deployment.

Also, I was wondering if a MAX reformat would be of order. As far as I know this would allow us to reconfigure the cRIO from it's default off the shelf state. Would there be any repercussions, besides having to reconfigure the cRIO just like it was just shipped? If not, we could try running the default code twice. Build run as startup, and then determine if it truly is the code or something else?

Finally, I've heard of the idea to turn of the FTP, HTTP server, or the error logging on the cRIO. Does anyone have any wisdom about this. I've heard conflicting views, and does it actually make any noticeable difference?

Unfortunately at this point to my knowledge it's like finding hay in a needle stack. Any help would be greatly appreciated.

[UberMentor]

My team is also having the exact same problem... Not only can we not always download - but we bel

ieve from

time to time - while operating the robot the 'code get boogged down' and is slow to respond. We are finding a

HUGE lag with the camera.

Is there a way to 'completely clean out the CRio and start over??? A super low level format???

We too need help here - we have spent hours upon hours chasing issues we now believe are being caused by the CRio not processing things on time.

We started the code all over again - but it seams like the CRio is remembering something from the past.  Also note this is the same CRio we used last year - so perhaps there is that old stuff in there also.

Looking for some direction.

[nathand]

Here are a couple of ideas and thoughts that I hope may help.  I have not seen the issues you're describing with any of the teams I've worked with, so this is based on my experience using a cRIO professionally - and in that situation I was able to get the cRIO running smoothly after modifying my code.

First of all, the most thorough way to clean the cRIO is to format it.  There is probably no difference between using MAX versus using the cRIO Imaging Tool, except that MAX does not configure and image the cRIO after formatting.  Even if you format through MAX you'll still need to use the Imaging Tool to get the cRIO into a usable state.  I doubt that repeatedly formatting the cRIO is going to solve any problems or have any different effect than formatting it once.

There are a number of tools for investigating cRIO errors.  Try right-clicking on your cRIO target in the Project Explorer and look under Utilities.  You can view the system's error log and crash log to determine if the cRIO actually crashed, and if so, why (if you're lucky - the error messages are not always helpful).  Be patient, sometimes it takes several seconds to load the log.  Of course, formatting your cRIO will wipe out this error log.

tsa256 wrote:

This failed, which surprised me because if something on the cRIO code related was using too much memory during the deployment why would it fail when deploying out code over the FIRST default code.

I'm not clear at all what you're trying to say here.  Can you provide the text of the error message?  Did it fail during deployment or once the code starting running?

Basically what we've done is read drive encoders in a 20ms loop then send those to another 50ms loop. The 50ms loop executes some calculations depending on the global variables sent into and out of the loop. e.g joystick, I/O and encoder values. It then drives the motors within the same 20ms loop. Furthermore, more complex code has been downloaded to the robot with 100% success about 2 weeks earlier. Which would point away from a code problem.

Code "complexity" in your mind may have nothing to do with how the cRIO executes it.  If the only thing that changed from the working to non-working is your code, that does point to a code problem.

Another instance of these bugs are sometimes one of the PWM outputs being controlled by a PID loop will drop out. But this only happens when the process variable of the encoder reaches a specific point. To diagnose the problem I coded a emulation of that control loop, there was indeed one point on the code were the PID loop seamed to just stop outputting updated error. After further investigation this point where it drops out is also a cross over point for the encoder, e.g. The encoder jumps from -2.5 to 2.5. I'm am unsure if this would cause an error, or the PID loop to just stop working.

A PID loop will definitely not like having its input suddenly shift.  Can you upload your testing code?  I have no idea what you mean by "stop outputting updated error" - it's still running, but not providing updated values?

The final data point we've gotten is that sometimes changing one number by .1 or some small value will allow successful deployment.

Do you have to make that change in order for it to succeed, or is it possible it's just that you're making a second attempt?  I wonder also if it's just the fact that you're making a change, forcing a save and recompile before deploying.

If you'll be attending the Boston Regional, I would be happy to help in person - I'll be there all three days as a volunteer (note that I'm a long-time LabVIEW user but not in any way affiliated with NI).

[tsa256]

tsa256 wrote:
This failed, which surprised me because if something on the cRIO code related was using too much memory during the deployment why would it fail when deploying out code over the FIRST default code.

I'm not clear at all what you're trying to say here.  Can you provide the text of the error message?  Did it fail during deployment or once the code starting running?

Oh sorry, I was a bit vague. Basically what happens is when we are trying to deploy the default code, it works when the cRIO is blank, or freshly formatted. Then as a troubleshooting step we attempted to deploy the exact FIRST code twice in a row. To my surprise it failed, during the run as startup deployment process it pops up with the "Stop Waiting And Disconnect" dialog box. We've waited for 5 minutes for this to go away. (On successful deploy it takes about 10 seconds), then as we click the disconnect button it says that the target settings deployed unsuccessfully. This investigation was trying to determine if our code was too resource intensive to actually complete the set at startup application. This problem was mentioned else ware on the NI forums, and was also touched open on Chief Delphi: http:/http://www.chiefdelphi.com/forums/showthread.php?t=84311&highlight=crio+downloading+dipswitch

Basically what we've done is read drive encoders in a 20ms loop then send those to another 50ms loop. The 50ms loop executes some calculations depending on the global variables sent into and out of the loop. e.g joystick, I/O and encoder values. It then drives the motors within the same 20ms loop. Furthermore, more complex code has been downloaded to the robot with 100% success about 2 weeks earlier. Which would point away from a code problem. 

Code "complexity" in your mind may have nothing to do with how the cRIO executes it.  If the only thing that changed from the working to non-working is your code, that does point to a code problem.

I agree, the cRIO executes the code in a completely different way then the human mind would normally think. Over my time spent programming in Labview I've attempted to learn and implement the correct optimization methods.I've uploaded the current code, and am planning on testing the timing in the loop tonight.

Another instance of these bugs are sometimes one of the PWM outputs being controlled by a PID loop will drop out. But this only happens when the process variable of the encoder reaches a specific point. To diagnose the problem I coded a emulation of that control loop, there was indeed one point on the code were the PID loop seamed to just stop outputting updated error. After further investigation this point where it drops out is also a cross over point for the encoder, e.g. The encoder jumps from -2.5 to 2.5. I'm am unsure if this would cause an error, or the PID loop to just stop working.

A PID loop will definitely not like having its input suddenly shift.  Can you upload your testing code?  I have no idea what you mean by "stop outputting updated error" - it's still running, but not providing updated values?

As far as I can tell, the PID loop continues to run, but the output of the loop remains the same, regardless of the process variable or setpoint. I've uploaded the code and there is a simple emulation of the loop that is having the issue. It appears to only be on the back chain. And in this simulation we are assuming the absolute analog magnetic rotary encoder outputs a value of 0-5. We do have a normalization of the magnetic encoder to reposition this rapid switch of 5-0 in a position where the encoder will never end up going. But it could be something else.

The final data point we've gotten is that sometimes changing one number by .1 or some small value will allow successful deployment.

Do you have to make that change in order for it to succeed, or is it possible it's just that you're making a second attempt?  I wonder also if it's just the fact that you're making a change, forcing a save and recompile before deploying.

I will admit I'm not positive if it is the number that causes it to work or just a lucky deploy. So far we haven't found a procedure to 100% successfully deploy besides using the No App dip switch on the cRIO before setting the code as startup. I'm questioning how forcing the code to save and recompile would make any bit of a difference. Our standard procedure for running code as startup is, Save All,  Build, Run as Startup and then reboot.

If you'll be attending the Boston Regional, I would be happy to help in person - I'll be there all three days as a volunteer (note that I'm a long-time LabVIEW user but not in any way affiliated with NI).

I really appreciate the offer, but unfortunately we are not going to the Boston Regional. Were headed to the Hartford Regional.

Thanks for all the help.

[nathand]

Unfortunately I don't have time at the moment to go through your code really carefully, and I don't see any immediately obvious problems, but here are a few thoughts:

- Don't put ! in the name of a file.  The cRIO doesn't run Windows, and it's possible it doesn't like odd characters in filenames even if they're OK on Windows.

- For your PID loops with the encoders, put in some code to detect when your crossover condition occurs.  When it does, make the "reinitialize" input to the PID block TRUE.

- Also with the PID loops, no need to convert back and forth between percentage and real values.  You could just set the PID max/min to +1/-1 and avoid the multiply and divide by 100.

Do you always do the Build, Run as Startup, Reboot sequence every time you want to run your code?  What if you just run it directly (click the white Run arrow in the Robot Main toolbar)?  When you do that, can you disconnect (right-click on the cRIO target in the project explorer and choose disconnect) and reconnect successfully?  Similarly, if you do have code set to run as startup, have you tried right-clicking on the target and connecting to it before you attempt to deploy?