We have run into a frustrating problem and you could some advice troubleshooting. When attempting to load last years code with the updated drivers, firmware, hardware, etc. we found that the code would could go through the deploy process and then lose connection the moment the code is done deploy. The driver station still shows communication, but there is no robot code deployed.
We spent the better part of a couple days tracking what was going on. The error doesn’t show up reliably, so it’s is really difficult to sort out. The key issue seems to be how many motors controllers are set up. Below are some screen shots of the begin program. The simpler one will run every time. While the more complex with either lose connect immediately after deploying or the Talon SRX controller won’t work.
Some strange symptoms. If I run the simple one first, the complex one will work. Once it works, I can redeploy it many times and it will always work. If it fails, it will keep failing.
Power cycling resets this. If I run the complex one after a power cylce it will never work on its own. Sometimes if I deploy the simple one, I can coax the complex one to work.
I have tried examples that have 4 controllers instead of 2 and 8 as in the pictures. Those example have a about a 50/50 chance of working.
All of these codes worked in the system last year. the problem seemed to occur after I implement the Talon SRX system on the roborio. But I can’t be certain that is problem.
I’m looking for advice on troubleshooting problems. This a pretty simple code and I’m struggling to figure out what is happening. Thanks in advance for any help.
Thanks Mark. The installation of the Phoenix for labview is when the troubles began. Prior to that installation deployment seemed to work fine (except for error because of the missing code). After the install the code began to lose connection immediately after deploying it.
I don’t have enough Talons handy to set up a testbed to experiment with.
Maybe try chaining the Talon Opens, so they are forced to occur sequentially.
That might point to race condition vi settings deeper down.
We are actually seeing a similar deploy problem as well, where the code deploys, then immediately says “connection lost”. After four or five tries it finally corrects and deploys correctly.
This is across multiple laptops and happens both through ethernet or wireless.
We are also seeing a very strange behavior we’ve never seen before, where the code running in the laptop runs further and further behind the robot. Indicators update more and more slowly. Yet the Rio cpu and can bus and the laptop cpu and trip times all look fine. This is fixed by closing every window with indicators. Then the code runs concurrently with the robot motion.
We currently have 4 Talonfxs opening, so our problem sounds similar.
We have the same behavior as engbrech. (3 Talons, 4 Spark Maxs). Mark… you recommended chaining the Talon Opens. How is that done? I can test that this evening when I get into the shop.
I wouldn’t call it a recommendation to normally chain those. Normally, we wouldn’t have to chain those operations.
It’s a diagnostic to see if opening them one at a time affects the problems you are seeing.
The results just lead us to another step in the debugging.
I’m digging through my supply of motor controllers to hook up a testbed…
We are using a RIO 2.0. I’ll try the chaining tonight to see what that does. Thanks for the suggestion Mark.
I’m both worried and relieved that others are seeing the same thing. It likely means I’m not going insane (relief), but also means the problem might not be an easy fix.
We got an initial report of behavior like this last week and we’ve been working with some NI folks to figure out the issue.
We’re still troubleshooting to determine the root cause and what changed between beta and kickoff (whether in Phoenix or LabVIEW) to cause the issue, however the workaround is to chain all Phoenix Open VI error signals to force sequential initialization, as Mark referenced in an earlier post.
Note that only the Open VIs need to be chained, all other VIs can be used as normal.
We’ll have some additions to our documentation up today that highlights the necessary workaround.
We are seeing the LabVIEW disconnect thing somethings, however changing the target to use the USB address seemed to help this.
We are also seeing a similar but different problem when using talon srx.
Sometimes it takes what seems like a long time for the robot code to restart after new code is loaded. (Same thing if you restart robot code, or reboot roborio.)
Sometimes the talon SRX don’t drive. We are using 2 talon per side (one follows the other). These are connected into the standard existing 2 motor. Then using the standard update 2 motor VI to set output (We haven’t tried strictly using the CTRE provided code yet).
Power cycling the roborio (not just rebooting), without deploying new code, seems to correct this.
Here are screenshots.
Begin
Periodic
Network table values update, but motors don’t move. Motor reference appears to be good.
Just implemented the work around and things seem to be working well now. Thanks all. Particularly Mark. If we end up at Championship together I’ll buy you a beer (or beverage of your choice)!
