We are a seasoned Labview team and this year I have a 3 year experienced Labview programming student.
We are having a frustrating time with Labview this year. Normally we don't have any problems. However the problems we are having are concerning.
The problem we are experiencing is out of the blue, the RIO seems to locks us out of doing anymore deployments. Here is what state we get to.
We are connected via USB tether when we try these things:
We can connect to the Webtool.
We can ping the RIO with an IP address.
We CAN NOT "connect" to Target in Labview.
We CAN NOT deploy because Target is not found.
The drive station does not connect. It connects to the radio but not the RIO. Sometimes the driver station connects for one msec then it drops off. so it never really connects but acting like it tries.
Firewalls are OFF, the green driver station firewall LED is lit.
This happens randomly and about the 3rd or 4th time this is happened this season so far.
We tried making a new Robot Project and deploying and the same problem with a new fresh default program.
To fix the issue, we have to FORMAT the RIO. After we do this, we can deploy and connect to the RIO with the driver station again. Every-time this has happened, we have to FORMAT the RIO to fix it. For example it worked all day on Sunday with live programming, deployed the code. Then came in on Monday and it would not connect to the driver station and would not allow deployment.
Before we even had issues with the Talons SRX can-bus not enabling even though the driver station was enabled, however we saw the Team Update 14 and have updated to CTRE Phoenix 126.96.36.199, we have not had enough run time with the new update to know if that problem is solved.
Tonight we swapped out RIOs just to try and see if we have a bad RIO. If this happens again, who is the "expert" that can do a WebEX or GotoMeeting with us to help us figure this out?
Is there any advance troubleshooting we can do to understand what the problem is?
For the target, instead of using the DNS name, we even tried using the raw RIO IP address. We can ping both uses of IP addresses for the RIO. We tried on two different laptops as well. One laptop is Windows 10 and another is Windows 7. Both laptops do the same exact thing.
Solved! Go to Solution.
I tossed a reply your way on the same thread on CD. Generally, it sounds like you're getting into a loop that consumes your CPU. If you're able to access the Web Interface, you should try to disable the startup application. If not, get into safe mode. From there, you should be able to remove the startup executable and avoid the formatting step.
This work around works for now:
1. connect via webtools.
2. checked the box "Disable RT at Startup"
3. rebooted the RIO from the webtools.
4. Once comms was up again the RIO said "No robot code".
5. deployed new code.
6. after deploy, go into webtools again, uncheck the "Disable RT at Startup".
7. restart code, and it worked. That was faster than a 5 minute RIO format...
So last night we wanted to make sure we did not have "Bad Loops" or "100% CPU utilization".
When we first look at the CPU% he had about 85-90%. Then he moved some code from 10msec periodic task to the 100msec, stuff we don't need to update that quick and that dropped us to the 50-80% range depending on what the robot was doing.
So I am convinced now, it's not a bad loop problem. Here is a video of where we are today.
Here is the video:
In this video, Code is Deployed.
The driver station is connected to the robot.
He tries to Deploy code.
You can see the CPU is 50% in the disabled state.
When it tries to deploy, there is a huge loss of comms on the radio. (He is trying to deploy over wireless in this video, but we have the same problem with the USB CABLE too, but will double check this when we get back to the shop)
When teleop is enable the CPU only goes up to about 60% maybe
There is still something else causing a can't deploy.
Are you using the CTRE library?
Another thread here is mentioning a similar problem when the library hasn't given the console a message saying it's completed.
The ports used to deploy code and send commands are different. This is something you can notice by watching the field. When plugged into the field, you cannot deploy code to your robot. But, you can clearly compete so sending commands works.
If stopping the code allows you to deploy, something in the code is holding you up. That's true whether it's something you've added or it's something that's part of the general architecture. Beyond the CTRE library, are you using any other potential libraries, NavX as an example?
We seem to be having similar issue
After first time building and installing code we could not deploy code again - it would hang.
We are running CAN and the CTRE libraries - we are not using the NAV-x
We checked our loops and they look ok , our max CPU usage is 86% which is consistent with last year.
If something is going on in the CTRE libraries we need to know what?
Have you reached out to CTRE? As it's a common thing among those reporting issues, it's at least worth engaging them to see if they're aware of anything. Keep in mind, they make and maintain their library. We aren't exactly the best source to tell you what's taking place inside that library.
I can try to download it and dig into it. But, I can't promise I'll have anywhere near the knowledge of their API as they do.
I am in dialog also with CTRE - but it is difficult to know if it is a CTRE issue or a Labview issue - would be great if you guys would collaborate in the interest of all.
They have said they are now aware as of yesterday - funny that teams are all finding this in the past couple of days -that a hint?
I'm pretty sure everyone in this thread was also over on the CD thread and in communication with CTRE.
For anyone else that finds this thread, CTRE's write up on the fix is hosted here: https://github.com/CrossTheRoadElec/Phoenix-Documentation/blob/master/LabVIEW%20Deploy%20Issue.md
Short version, update to their newest installer (5.3.1 or newer) and the problem should be resolved.