Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   NI LabVIEW (http://www.chiefdelphi.com/forums/forumdisplay.php?f=182)
-   -   Problem connecting to the CRIO (http://www.chiefdelphi.com/forums/showthread.php?t=126082)

Morgeno 08-02-2014 18:35

Problem connecting to the CRIO
 
Hi Chief Delphi,
So my team has run into a little problem. For some reason when we attempt to deploy code, about 90% of the time an error comes up at a completely random time in deployment that says:
"Error: waiting for real-time target CRIO to respond"

We don't know what is happening to cause this or how to fix it.

Sometimes it happens in the beginning of deployment, sometimes not util the end.

Has anyone run into this problem before? If so how did you fix it?

Thanks,
Morgeno

silas13579 08-02-2014 19:29

Re: Problem connecting to the CRIO
 
Hello all,
I'm from the same team and as an update, when we try to connect we get error 44002 about 50 times: Warning <Code> 44002 occurred at Ping Results: link-bad, DS radio(.4)-GOOD, robot radio(.1)-bad, cRIO(.2)-bad, FMS-bad Driver Station. It is something like this each time, except the radio flashes between GOOD and bad every other time. Both computers we have tried have windows firewall off.

Any and all help is appreciated.

Alan Anderson 09-02-2014 00:15

Re: Problem connecting to the CRIO
 
Quote:

Originally Posted by Morgeno (Post 1339786)
For some reason when we attempt to deploy code, about 90% of the time an error comes up at a completely random time in deployment that says:
"Error: waiting for real-time target CRIO to respond"
[...]
Has anyone run into this problem before? If so how did you fix it?

We've been regularly losing contact with the cRIO during code deployment for weeks. Our lead programmer just discovered that having it in Test mode when trying to load new code was a reliable way to have it fail, and after he started making sure it was in Teleop it hasn't broken again. I don't know what is really going on, but I do know that Test mode pegs the CPU usage at 100%.


Quote:

Originally Posted by silas13579 (Post 1339807)
Hello all,
I'm from the same team and as an update, when we try to connect we get error 44002 about 50 times: Warning <Code> 44002 occurred at Ping Results: link-bad, DS radio(.4)-GOOD, robot radio(.1)-bad, cRIO(.2)-bad, FMS-bad Driver Station.

The "DS radio(.4)-GOOD" part is highly peculiar. It's not typical to have anything respond at the 10.23.37.4 IP address. Besides the D-Link, do you have another wireless router in the network?

Zmarken 09-02-2014 00:32

Re: Problem connecting to the CRIO
 
Quote:

Originally Posted by silas13579 (Post 1339807)
Hello all,
I'm from the same team and as an update, when we try to connect we get error 44002 about 50 times: Warning <Code> 44002 occurred at Ping Results: link-bad, DS radio(.4)-GOOD, robot radio(.1)-bad, cRIO(.2)-bad, FMS-bad Driver Station. It is something like this each time, except the radio flashes between GOOD and bad every other time. Both computers we have tried have windows firewall off.

Any and all help is appreciated.

If you look here (under ping status), 44002 is explained a bit. That doesn't really tell you much though.

Looking further through the that website, under "Diagnostics Tab", it says
Quote:

"DS Radio" is a legacy indicator used to indicate the ping status to an external radio on the DS side at 10.XX.YY.4.
So, a couple of things I can think of... Does the 44002 warning change between
Quote:

Warning <Code> 44002 occurred at Ping Results: link-bad, DS radio(.4)-GOOD, robot radio(.1)-bad, cRIO(.2)-bad, FMS-bad Driver Station.
and anything else?

Secondly, and you might just want to do this anyways, but have you tried this? If you hook up your router to that, it should set the IP correctly, if that's the issue.

Also, something else to try: hook up directly to the cRIO and deploy to that, instead of going through the router, just to see if that works, or if you still lose connection.

That's all I can think of right now... Hope that helps.

Greg McKaskle 09-02-2014 08:22

Re: Problem connecting to the CRIO
 
I suspect that this is caused not by CPU load, but because the cRIO is pumping out so many error messages. Each time it does so, it causes a number of thread transitions. We discovered late last year that during those thread transitions, it is possible for the cRIO code to drop the deployment protocol.

If your Diagnostics tab is streaming errors, try another mode, tele, disable, etc. Then try to deploy.

If Test is causing lots of errors, that would probably be because some I/O was not opened correctly. Test mode reads every single I/O value and displays it, so if there was a rarely used or not used Open call, it will complain about it anyway.

Greg McKaskle

silas13579 09-02-2014 15:55

Re: Problem connecting to the CRIO
 
We managed to find our problem. Some of our refnum names were left blank. we fixed it and it deploys now.

Thank you all for your help.

EDIT:
Never mind. It still isn't working. We always have it deployed when the driver station is in teleop, not test. This happens whether it is attached to the radio or CRIO.

killer_rabbit3 09-02-2014 16:10

Re: Problem connecting to the CRIO
 
You may be experiencing a windows problem. we've had this same error before and all we did was reboot windows and then it worked fine

silas13579 09-02-2014 16:49

Re: Problem connecting to the CRIO
 
Quote:

Originally Posted by Zmarken (Post 1339951)
Looking further through the that website, under "Diagnostics Tab", it says

So, a couple of things I can think of... Does the 44002 warning change between and anything else?

The radio signal flashes between good and bad. Also when we try to deploy code without rebooting the crio since the last attempt we get this error: Access denied: Another project is using this target. You must disconnect the existing project from the target or restart the target before establishing a new connection. Note: The existing project may be running on a different host computer.

silas13579 09-02-2014 17:52

Re: Problem connecting to the CRIO
 
So far, connecting directly to the CRIO actually has been working, so we're just going off of that right now. The bridge config utility isn't working on our radio. It says login failed.

Zmarken 09-02-2014 18:25

Re: Problem connecting to the CRIO
 
Quote:

Originally Posted by silas13579 (Post 1340223)
So far, connecting directly to the CRIO actually has been working, so we're just going off of that right now. The bridge config utility isn't working on our radio. It says login failed.

If deploying directly through the cRIO is working, then I'm pretty sure it's a router issue.

I'd say you should do a factory reset of the router, then go through the Bridge Configuration tool again. If you're using the router in the KoP, reset it by holding down the reset button in the back of the router for ~10 seconds.

Try that, and see what your results are.

Invictus3593 10-02-2014 09:37

Re: Problem connecting to the CRIO
 
Quote:

Originally Posted by silas13579 (Post 1340188)
...When we try to deploy code without rebooting the crio since the last attempt we get this error: Access denied: Another project is using this target.

Rebooting the crio should work, but you'll have to redeploy your code. Are you trying to use more than one computer or robot project?

Quote:

The bridge config utility isn't working on our radio. It says login failed.
Have you tried resetting the radio fron the button in the back?

silas13579 11-02-2014 07:29

Re: Problem connecting to the CRIO
 
We have tried the reset button, however it is not working. Also, connecting to the CRIO directly failed yesterday. Towards the end of deploy, when it's mostly through our global variables library, it stops.

Greg McKaskle 11-02-2014 07:39

Re: Problem connecting to the CRIO
 
When it stops, there is typically a dialog on the screen explaining what succeeded and what failed. Can you copy/paste or take a screenshot so that we can help interpret what failed?

Greg McKaskle

silas13579 13-02-2014 19:09

Re: Problem connecting to the CRIO
 
The only response we get is when we are trying to connect, it will say Waiting for response from Real time Target (I forget the exact wording). When we reimage the Crio, or at the beginning of meetings, is when it seems to work the most often. Our head mentor (we don't have any actual programming mentors) said that maybe our code bugs up the CRIO image when it deploys? Also, though our electrical team said it should be irrelevant, the analog card(I think. It's whatever shows the voltage) is not in the CRIO.

Greg McKaskle 13-02-2014 19:57

Re: Problem connecting to the CRIO
 
The HW team is correct. The DS voltage will be incorrect, and you will need the module and breakout and jumper in order to pass inspection, but you don't need it right now.

My suspicion is that you have a great deal of Diagnostic errors being reported at the DS. If you can change the mode of the robot at the DS, you may find that one of the modes produces less errors and will have a better shot of deploying. If you fix the code issues that are causing the errors, the deploy issue will go away.

Also, you do not need to reimage the cRIO -- almost ever. Teams do this all the time, and I'm not sure why. The file system is very robust, and if not corrupt, why do it? You may sometimes need to turn on a setting such as the no-app switch or change the CAN or other settings.

Greg McKaskle

silas13579 13-02-2014 20:06

Re: Problem connecting to the CRIO
 
Well the reimaging of the CRIO seemed to help. We just tried deploying a default robot project, and the CRIO was still not accepting it. Then we switched to our practice bot, with a different CRIO and a different ethernet and tried deploying our code, which didn't work, and then tried deploying a default project onto that, and that too did not work. They both were stuck in the same "waiting for the target (RT CompactRIO target) to respond."

Mark McLeod 13-02-2014 20:12

Re: Problem connecting to the CRIO
 
Reimaging the cRIO works (in a brute force kind of way), because as a side effect it wipes out your user code that is responsible for the problem.

The No App switch (a DIP switch on the 8-slot or for the 4-slot virtual through the cRIO Imaging Tool) disables your user code when the cRIO is reset and is quicker.

Greg McKaskle 14-02-2014 07:34

Re: Problem connecting to the CRIO
 
Exactly. And once the errors on the diagnostic screen are fixed, neither will be necessary. Until they are fixed, don't Run as Startup, use the run button instead.

Greg McKaskle

silas13579 14-02-2014 18:08

Re: Problem connecting to the CRIO
 
Alright so I'm getting confused now. What is the diagnostics screen? The part of the driver station? Because I'm not sure how it may be in our code, seeing as the default robot project didn't deploy either.

Mark McLeod 14-02-2014 18:10

Re: Problem connecting to the CRIO
 
It's not the code you are deploying. It's the code already running on the cRIO from the previous deploy.

The Diagnostics tab on the Driver Station has a message window.
There are a lot of warnings that can obscure the real error messages, so copying and pasting all of them into a text file makes them a lot easier to look through.

You can also look at the Driver Station log from the Charts tab, in the lower right is "Launch Viewer."
You have to pick the latest log or two by date, then look at the Event List tab for error messages.

silas13579 15-02-2014 10:57

Re: Problem connecting to the CRIO
 
I'm pretty sure I found the error. We were kind of recycling last years code, and last year they had nothing in finish.vi, so this year we assumed that we could go the same. Would this have been causing the problem? I'm in the middle of fixing it right now, so I can update with whether it works.

silas13579 15-02-2014 12:54

Re: Problem connecting to the CRIO
 
Nope never mind it's still not working. We have tested deploying quite a bit today, and it seems to work after we flash it until the first time we perma deploy onto the robot, which then causes every attempt after that first perma deploy to fail, until we flash it again. It also occasionally gives this error: Access denied: Another project is using this target. You must disconnect the existing project from the target or restart the target before establishing a new connection. Note: The existing project may be running on a different host computer.

Mark McLeod 15-02-2014 17:35

Re: Problem connecting to the CRIO
 
That pretty much proves that it's your code.

If you want to post it we can help track it down.
The Driver Station log might show very high CPU utilization.

silas13579 18-02-2014 17:35

Re: Problem connecting to the CRIO
 
After searching, we still can't find any errors, so we will just only perma-deploy once code is finished, and temp deploy at all other times. We also created backup code in java.
Thank you all for all your help.

Levansic 23-02-2014 23:15

Re: Problem connecting to the CRIO
 
What did you put into your finish.vi? Make sure every peripheral opened in begin, is closed in finish.

By any chance, are you using CAN? We've had these issues when a Jaguar couldn't respond back due to not being connected.

Danny Diaz 23-02-2014 23:38

Re: Problem connecting to the CRIO
 
Just as an FYI, FRC418 practically NEVER updates code via the deployment method. On a 4-slot cRIO, it's just a major pain in the butt to get the device into Safe Mode to be able to upload code.

We only FTP file updates. Assuming you don't try to run code "interactively" via the "run" button from within "Robot Main" (which disables the "Run as Startup"), we just FTP the startup.rtexe file created by the build process. It is 100% effective, and "deployment" takes seconds - instead of minutes. Remember you have a full file system under the hood, and the "deployment" phase merely uploads the startup.rtexe file (via mechanisms that seem to always be thwarted by bad robot code) and sets a token within ni-rt.ini that tells the system to load the file. If you do that manually, it always works.

-Danny

Alan Anderson 24-02-2014 00:14

Re: Problem connecting to the CRIO
 
Quote:

Originally Posted by Danny Diaz (Post 1348735)
We only FTP file updates.... It is 100% effective, and "deployment" takes seconds - instead of minutes.

The standard Run As Startup also only takes a few seconds this year. It's obvious that there have been some highly effective fixes made since last year's version.


All times are GMT -5. The time now is 21:07.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi