Error -63195 on DIO and Analog Opens

Recently, my team removed the pneumatics system (PCM and all) from our robot due to weight issues, and since then boot-up code and deployed code results in these errors being outputted to the driver station:

ERROR  -63195 occurred at Read/Write Control in>>>>Robot
NI-RIO:  (Hex 0xFFFF0925) The handle for device communication is invalid or has been closed. Restart the application.

ERROR  -44070 occurred at>>>>>>>>>>Robot
FRC:  The <b>Analog Channel</b> for the accumulator is invalid.

ERROR  -63195 occurred at Read/Write Control in>>>>Robot
NI-RIO:  (Hex 0xFFFF0925) The handle for device communication is invalid or has been closed. Restart the application.

ERROR  -63195 occurred at Read/Write Control in>>WPI_MotorControlOpen&>WPI_MotorControlOpen>>Robot
NI-RIO:  (Hex 0xFFFF0925) The handle for device communication is invalid or has been closed. Restart the application.

I tried re-flashing the roboRIO, but that did nothing to solve the problem. I checked and all pneumatics code is removed (it had been producing other issues related to CAN due to lack of PCM). I then tried reverting to older revisions of the code and was able to find a version without the errors, but the revision is old and would be very inconvenient to use and bring back to the current version, and I worry that the errors would not be resolved. I did not see any major differences in the code that could cause this, and the only change to (which is where all the errors were occurring as shown in the errors above) was that a Talon was inverted, which I un-did just to be safe, but that did not help. The old and current are attached (the newer one has an added I2C open, but that was added after the errors were found, not before).

What is extra peculiar is that if I ran the old code, stopped it, than ran the new code, everything works.

We also had functioning code on our bagged robot and after un-bagging it, we removed the pneumatics. On the robot’s boot with the start-up code, it had these same errors, in addition to penumatics errors. I put the most up-to-date code onto the robot and the errors remained, excluding those relating to pneumatics. I set the new code as start-up and re-booted the robot, but that still did not fix the problem. I tried running the code off of my laptop, but that also did not fix it.

This NI help page that I found also did not fix the problem.

We have the most up-to-date FRC update (2015.1.0). We also re-connected the PCM but that did not fix the problem. So I can’t blame the pneumatics, but it is very coincidental, and maybe it has something to do with it.

This post is about the same error, but in our case we have it for all analog and digital input/output, which is problematic, and I am not sure how to fix this issue based off of the information from that post. It appears to identify the problem as the functions in begin being run before an FPGA reference is attained by the code, but I am not sure how to solve this. I assume it would be possible to go deep into the WPI code and copy out the function that returns the FPGA reference and if it is not valid, loop in begin until it is, but that seems sketchy and it shouldn’t be needed.

Is there an easier solution to fixing this other than re-writing our code from the last working copy or by checking if an FPGA reference is present before opening our devices?

Michael (81.8 KB) (79.2 KB) (81.8 KB) (79.2 KB)

You have two different errors there. One is pretty straightforward, and one is confusing.

The easy one is the one about the gyro. It is coming from a VI that you didn’t attach, and is most likely telling you that you are reading the gyro from something other than channel 0 or channel 1. The accumulator for the gyro exists on only those channels. The error is not from Begin, but from the BuildCustomDashboardData VI.

The harder one is saying that the FPGA handle hasn’t been opened before someone tries to use it, or it has been closed. In order to optimize the runtime, some of the libraries in the past have had this bug. I looked and found the call to load the FPGA in the DIO function and elsewhere.

Looking at the report below, I think the first error is actually the PWM one. I guess the first thing I’d do is open Begin and push the pause button. Clear the error display, and run Robot Main. It should stop in begin, and you can single step over the Open calls and see which runs first and which produces the error.

I’ll PM you to get the rest of your code and see if I can reproduce the error with my installation and controller. Also, have you contacted support for this?

Greg McKaskle

The gyro used to work before these errors, so I believe this error results from the errors with opening analog channels. Also, the errors repeat, as in they keep popping up on the driver station even if you clear errors, so the ones I posted are not necessarily in order and may not be all of the errors, since they look similar but with different call chains.

I’ll try that the next chance I get.

The source of the error is the error out from the FPGA read/write function shown in the attached images. Both images are the same, except they have the error text scrolled differently in the probe watch window so you can read it all.

This function is in the in the WPI library. The reason for it not working is still unknown, and it does indeed output an FPGA reference of 0x00000000 where the functioning (old) code outputs valid references. And the current code outputs valid references if you deploy the old code then the new code. It just does not make sense.

At this point it seems like the best possible route is to take the working code and bring it up-to-date, unless a solution is found by tomorrow, since we have a competition this weekend. I very much would like to find a solution to this, since it seems this error has never been really solved by anyone, people have just found ways around it.

This issue was solved (thanks to Greg McKaskle for figuring it out) by deleting two charts from an autonomous driving VI. This solved the issue because there was likely a memory corruption relating to those charts. I was a bit suspicious of this VI, since occasionally it would not deploy along with the rest of the project, even though it was clearly a dependency.