Labview Pwm/DIO ERROR -63195, need help

[klink135]

Labview is improperly/not writing pwm/DIO channels. I am currently unable to make any pwm work. It gives me ERROR -63195, and sometimes the driver station will say no robot code even when it is deployed. I have even made a brand new default robot project and it suffers from the error.

[Tom Line]

This probably has nothing to do with it at all, but why does your PC CPU show pegged at 100%?

[Mark McLeod]

Have you formatted the roboRIO with the 2017-v8 image?

[klink135]

Tom,
I don't really know, sometimes it just spikes and nothing was done to it.

Mark,
Yes, the Roborio and all following components are updated to the most recent firmwware.

[Dave Campbell]

Following...same exact error has happened to us on two different Rios. Spoke with NI and they sent us a config file, still same error. Will follow up with them again today.

[JeffB]

With the default project, you'll create a connection to a pair of Talon SR motor controllers on PWM0 and PWM1. If you're using a different motor controller or different PWM ports, I wouldn't be surprised to see that error.

I'm making the assumption you don't change anything with the sample project. Is that a safe assumption? If so, what PWMs are you connected to and what types of controllers? I wouldn't be shocked to hear you checked that, but for completeness we'd want to see that.

If you get an error there, I'd want to see what happens if you replace the motor initialization code with just the Open Motor VI found in WPI Robotics Library->Actuators->Motor Controller

With that, you can open a single motor rather than two at once. If you open up the motor on PWM0, do you see the same error? If not, do you see it on PWM1? Once you find a single PWM port that's causing the problem, I'd try moving the PWM to PWM2. Does the error go away? If not, try changing out the cabling. Does the error go away now? If so, it could potentially be the port.

If not, try swapping the original cabling so the two PWM ports go to the opposite motor controllers. Does the error follow the port or the controller?

[klink135]

The default project worked, and I tried rebuilding my code from scratch. This went fine until I put set outputs into teleop, that caused the first error. So logically I tried removing the motors in the program. It then said that encoders were the problem, so I removed the encoders. This process repeated until I had removed every input/output on the Rio, except for the can bus, which works fine. So I dug in and tried to find the source. The errors led me to the fpga open system.vi. In there it seemed the problem was the address of the Rio. I didn't take pictures. But I will try to post some soon.

[JeffB]

The FPGA portion sounds a bit like a red herring.

Ultimately, all IO goes through the FPGA using a standard bitfile that you don't have to touch. If the bitfile itself was the problem, you'd have a problem right from the start. It's also a problem that every team would have because it's part of the imaging process.

You'll want to focus your attention on building out. If you start with the initial project, it includes a couple of PWM ports going to motors. If that doesn't error, you can try to add the next component on. If you're working with Command and Control, it's even easier to test in this modular mindset. Start with the drive subsystem and see if the error pops up. If it does, you know it's the most recent thing you added. Check the wiring. Check the hardware. Make sure it's responding. If it's not, you'd expect to see the error. Take a look at the lights on the motor controller when you enable. What do they tell you?

[HSi]

Our team has had the same FPGA and device handling error show up in our driver station and prevent our code from running when we enable. This has been happening on different robots and computers, and even with blank projects, all in the past week. As far as we know, none of the hardware on the robots has changed.

Interestingly, error -63195 is always preceded at the beginning of runtime by error -63192, which says that the RIO resource name is invalid. We checked it with NI MAX, however, and the resource name seems to be fine.

We suspect the problem is in the WPI libraries at the base of LabVIEW or on the robot and know that we didn't touch that code. Occasionally, rebooting the robot/roboRIO multiple times, clearing object cache, and removing code from the roboRIO has solved the problem, but none of these solution has been consistent--the problem still occurs intermittently.

The latest method we tried was shelling into the roboRIO and removing the "frc" folder, which appears to hold the LabVIEW libraries. So far it seems to work, but we're not sure yet whether it's a permanent fix.

[tr6scott]

We were having this error also, but we did a roborio complete format, and firmware load, and that seems to have fixed the issue.