CRio Connection: Buggy

Technical NI LabVIEW
#1

We got the most recent LabView update today, and after reimaging the CRio (which was successful by the way), I opened the driver’s station. My computer is tethered to the bot and we have not had communications problems before now. Now, even though I can ping the robot successfully, the communications only like to come on for one second, turn off, wait a minute, and then repeat. On the CRio, the Status LED blinks 4 times in a row and repeats that. I have power-cycled the bot many times and, yes, I have restarted my computer. Nothing is working.

What happened? Does the Labview update contain evil?:eek:

#2

After imaging the cRIO, there is no code installed on the robot. Does that explain your problem?

#3

It’s not the fact that there is no code, it’s the fact that for some reason, the CRio doesn’t want to admit that it’s connected to my computer. My mentor said something about the CRio being “Bricked” but I have no idea what that means.

#4

We are having the same issue. After re-imaging the cRio (three times successfully) and updating labview, we cannot run code on the cRio. We can ping it but when we try to “run at startup” we get a message that Labview cannot communicate with the real time target. The status light on the cRio repeats a series of 4 flashes as reported above.

#5

Four flashes means a double crash. The manual mentions it could be due to running out of memory.

You may want to watch the deployment dialog closely to see if that indicates a memory issue.

Greg McKaskle

#6

Just got the same thing at one of the teams here.

Re-imaged the cRIO with v27 and we start getting the 4 blinks repeated.
Cannot download code but can reimage it to our hearts content.

I can reimage with v25 and everything works fine again.

#7

Does the serial console show anything interesting?

#8

I have console dumps, but haven’t been able to look at them.
I did get it working, but I’ll have to wait on posting an update.
I’m in transit between teams.

#9

We managed to get code to deploy/run a few times but mostly we get the four flashes in Status. On one of the times it worked, I checked the memory usage and there was still 16K or so free.

The four flashes in status start even after a reboot with no attempt to deploy. I tried disconnecting everything - removing all sidecar adapters, ethernet connections etc. And rebooted. And still the cRIO showed four flashes.

From a laptop I can ping the cRio before trying to run. When I try to run I get “can’t connect to real time target” but after cancelling, I can still ping the cRio.

I have not tried to go back to v25. I’ll check that out.

#10

16K is not much. Can you verify that number and clarify when you are at 16K?

Greg McKaskle

#11

I just want to jump in to say that we’ve seen similar issues since the update.

Since the update we haven’t been able to deploy code wirelessly. When we try to deploy wired, we haven’t been successful when hooked to the Dlink. If we connect directly to the cRIO, we are successful deploying about 25% of the time (i.e. it takes about 4 tries before it works).

After deploying new software and rebooting, we are able to get the robot to run wirelessly through the driver station. No issues.

We have not yet been able to run software via the Run button since the update. It starts to run and then it promply loses connection.

That’s all I have for now. I won’t see the cRIO until Wednesday night, so if I notice anything new then I’ll try and post it.

#12

I currently have a temporary solution. Our team had the same problem and what we found is that we plug an ethernet cord into the linksys slot 1 in the rear and plug the other end into a laptop and wait a bit it finally works. we have no clue why but it works. also, one of our mentors (going for his masters in computer science) played around with it a bit and all of a sudden it works well now. We don’t even have to plug it into an ethernet cord and laptop. :slight_smile: yay :slight_smile:

#13

I can later reply back with a post on what he did when i meet him next.

#14

We made some progress in identifying this problem.

First, reimaging back to the v25 cRio firmware corrected the problem. There were no blinking status lights and we could deploy code at will.

I then re-imaged using v27 making sure to connect directly from PC to cRio via ethernet. The four blink status light returned. We could not deploy code getting the “failed to connect to Real-time Target” message. We checked to make sure Labview was at 3.1 FRC level.

We had loaded the CAN driver for the Black Jaguar Serial Bridge and had that working under v25. In the cRio Imaging tool I first changed the plugin to “None” leaving “Enable NetConsole” checked. Reimaged at v27 and still had four blink status.

Then I unchecked “Enable NetConsole” and reimaged. That seemed to fix it. cRio booted and I was able to deploy code.

It appears that adding the NetConsole and maybe CAN is consuming memory and putting us over. We have a 2009 cRio. Does this make sense? Are we going to have to avoid CAN? An ideas?

#15

Please post console logs (both NetConsole and Serial Console) when you see this issue.

Thanks,
-Joe

#16

I don’t think the logs I captured are particularly useful, and they weren’t comprehensive.
I had to bring in several other laptops after the problem occurred to start the monitoring.

This particular log shows two boots, but unfortunately the problem may have been fixed by this point.
The first boot generated the 4 flashes, and caused an automatic reboot.
The second boot was a successful recovery from the same.

I have had several other cRIOs reimaged without any issues. Maybe one 4-flash that caused a then successful reboot.

In the case I saw, the v27 reformatting enabled NetConsole, and had None for CAN.
Cycling the power had no affect and the 4-flashes continued unabated.

Changing DIP switches, e.g., Safe Mode, didn’t seem to affect the 4-flashes and the cRIO remained unresponsive.
The flashes began very quickly, so it may be before any image gets loaded or early in the load process.

Reimaging (from same Classmate) with v27 completed successfully, but had no affect.

Reimaging to v25 worked, then a repeat of v27 was successful.

On a side note, Classmates that installed the LabVIEW Update, but didn’t install the LabVIEW DVD, look normal from a distance. :rolleyes:
I had to be there to notice all the missing software, but the version information was right up to date…

cRIO_bootup_V27.TXT (2.88 KB)


cRIO_bootup_V27.TXT (2.88 KB)

#17

We are having the exact same problem on our robot. I didn’t check for the blinking LED, but once we updated to version 27 we could still reimage and connect through ftp, however LabVIEW was unable to connect. Once we reimaged with v25, all was good. One of our tests included not imaging with the black jaguar plugin and we still had issues.

#18

I re-imaged our cRio to v27 first with just NetConsole and then with both NetConsole and CAN Jaguar Black Serial plugin. Of course, now it seems to work. I ran LabView code that was essentially the default FRC cRIO Robot Project modified to drive a single motor using CAN.

From the console log, I did see two troubling messages when the cRIO boots:
interrupt: PCI Error: initiator aborted due to timeout
interrupt: PCI Error: initiator aborted due to timeout

I’m not sure what they mean but the system appeared to work. I was able to deploy and run CAN code. The system crashed once, I think when I was using the System Monitor. In the several times I ran code from LabView I received the Unable to connect to real-time target only once, accompanied by four flashes in the status LED. I didn’t see anything in the netConsole at that time.

I’ll do more testing tomorrow. The NetConsole log I captured is attached.

NetConsole2.txt (7.37 KB)


NetConsole2.txt (7.37 KB)

#19

We afre seeing the same issue here. Spent a few days trying to figure out what was wrong with the rio before finding this.

We flashed with net console and CAN enabled for the black jags (didn’t try with can disabled).

Flashed to v27 innumerable times (flashing always worked fine), labview would not deploy code. I was able to ping and ftp into the rio without issue. The driver station would see robot comms on bootup momentarily, then it would lose it. I was able to successfully deploy from labview maybe 10% of the time. After a sucessful deploy, control through the driver station worked reliably.

This is pretty easy to replicate on our end.

The only fix that seemed to work reliably was to flah back to v25.

We seem to be hitting bugs this year every step of the way. Last week it was problems with the encoders. I don’t mean to complain, but these types of issues don’t help when your trying to teach the kids how something “should work”

What gives?

#20

I have an update from last night.

We added case structures to timed tasks to be sure that none of our code in timed tasks runs unless the robot is enabled. It took about 4 tries to deploy this software (using Run As Startup). After getting this software on the cRIO, we never had another problem.

It makes me think that something in v27 is taking up a lot of CPU overhead causing issues with the communication. I seem to remember issues last year when the user software started taking up too much CPU time, it became difficult to deploy code. Perhaps this is similar.