Labview Pwm/DIO ERROR -63195, need help

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.





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

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

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.

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.

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?

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.

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?

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.

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

This error has now returned, we tried to diagnose, loading the default project with multiple laptops, and multiple roborio’s. We have diagnosed that it is a single rio, (we have 4) that this error follows.

Any ideas?

So it seems to be an issue with the NAVX, we started rebuilding our project block by block, and everytime we add the NAVX communication loops this error is showing up.

Did the original poster have a navx too?

We were using SPI, and we have tried USB, and everytime we put in the code, the error shows up.

This error has now returned, we tried to diagnose, loading the default project with multiple laptops, and multiple roborio’s. We have diagnosed that it is a single rio, (we have 4) that this error follows.

Any ideas?

My team is using the NavX and we also had the problem. First, I suggest you make sure that your NavX libraries are located where the NavX software installer placed them. Regarding the problem as a whole, we believe we have found a way to evade the problem without removing the NavX from our code and robot. To summarize, our solution was to build a blank robot project down to the roboRIO (i.e. so the code runs at startup) and then build our actual robot project down. Here’s some of the troubleshooting and reasoning behind it (though I admit this might not explain why only one roboRIO is having the errors):

We first noticed that the errors appear on the robot depending on what was deployed or built at startup. If a blank/standard project was the first project deployed after the robot was turned on or after the roboRIO was reset, every subsequent project deployed to the robot caused no errors. If the first deployment caused the -63192 and -63195 errors, then every project after also has the errors.

Hence, we built down a blank project onto the roboRIO, and every deployment was fine. We then built down our actual project just to see whether the act of building down could resolve the issue, and the errors stopped appearing as well. This seemed to solve the problem for both of our roboRIOs.

I’ll put out a warning that the errors have occasionally appeared a few times during deployment of work-in-progress robot code, but they stop before the end of deployment and don’t inhibit the functioning of the robot like before.

I would offer an explanation for this solution/“evasion technique”, but unfortunately I don’t completely understand it either, especially with the new information about the NavX communication loop causing the errors. Maybe our errors have two different sources. It would be great if someone could shed light on this.

Thanks for all that work, and sharing.
I have sent a note to Navx about the their binaries installer, and placing the files in the wrong locations, and have not had a response. (Some of our laptops have ssd boot drives, and Labview was installed on D: and Navx installs on drive C: no matter where labview is.) We copied the libraries as other users suggested on CD, and it seemed to work. We really wanted to test the SF2 integration with vision this year, as we had good success last year with vision targeting the high goal in auto on the roborio. The SF2 installs for us, end up missing .ctl files, and we can’t get it work. I wonder if all of these issues are due to a bad installer…

We are down to crunch time, and we don’t have a running bot, and our autos are written and we need an accurate imu, that doesn’t cost us precious debug time.

So the error occurs with both SPI and USB communications? Can you give specifics on the HW and which year’s libs you are using? We don’t have a navX on the robot this year, but we have one we could test with to look into the error.

My guess is that the navX is going first and is doing something with the FPGA before it gets loaded. There is a cached handle, and every now and then, a code path finds a way through that doesn’t force the FPGA to load before using the cache.

Greg McKaskle

Does your robot application use the MXP expansion IO pins brought out on the MXP header? Since it appears the error codes are related to expansion IO I’m wondering if perhaps there is some sort of race condition going on where the MXP expansion IO ports are not completely initialized by the time your application begins running. Just a guess, but the pattern isn’t clear yet.

Perhaps if the expansion IO code is removed the issue the symptoms will too.

If this seems reasonable to you, it might be worth trying. And if you can send details of your application (language, communication mechanism to navX-MXP, and what if any expansion IO usage you have) that could help us reproduce the issue as well.

I would have to go back to our logs, I think we had the DIO error before we tried to use the MXP I/O, but I do know when we were testing last Saturday, and isolated it to the Navx issue, we did have code that was using the MXP I/O, as we had ran out of DIO ports.

I know for sure we were using a jumper(signal to ground) in MXP DIO9 to determine if the code was running on our comp bot or practice bot.

We pulled off the navx, and moved to a pigeon with the REV robotics More Board, (rev1) as I had them instock and continued code development.

We are really behind, so limited time available to debug this, but if you have a some specific tests you want to be tried, I can have the navx placed on a another rio to test.

So just to confirm understanding:

  • This occurs on one out of four RoboRIOs (all running same firmware)
  • When the error occurs you receive: error -63192 (RIO resource name invalid), and then -63195
  • Reflashing the firmware resolves it the first time you re-run your robot app, but after successive reboots w/the same code (or re-downloading the same application again) the problem reappears
  • The navX-MXP is plugged into the MXP slot (same for all four units)
  • The error occurs with both SPI and USB (they have completely different communication IO threads, so that’s singificant)
  • A jumper is on DIO9 to ground (which implies you are using MXP IO)

The one bit of information that would help is what the robot application is doing w/the expansion IO:

  • What ports are being used and for what?
  • When are these being initialized relative to the navX-MXP?

Perhaps if you can shed some light on the MXP IO behaviors, we can figure out how to reproduce the issue.

Do you recall what the resource name was? Perhaps that would shed some light on what type of FPGA resource to investigate further…

Scott, these posts of mine have happened over the last two weeks, so some of this is jumbled, let me try the facts straight, below.

This was my last statement, We have 4 Rios and 2 Navx. Some Rio’s do not have Navx. The error that occurs when this was stated, is loading our project with the “Navx Main.vi” in “Robot Main.vi”, will error out all 4 Rios. This was Saturday 2/11

This is the original post, approx. two weeks ago, we had this error, and we also were experiencing high CPU loading at the same time in the season. We were debugging analog ultrasonics at the time, and were using the Analog Channels. The error message contained DIO and Analog errors, and the analog port would not return values. At this point in the season we did not make the connection that these errors could have been related to the Navx. Re-flashing and reformatting the roborio did make the problem off the error codes to go away and we got readings from the analog channel. That rio and navx was on our programming mule, and it seemed to run a week and a half without the errors showing up. We did not experience the run once, it works, run a second time, it crashes, hangs, throws errors, that other teams have reported, it seemed to work for a week+ then it didn’t. Around the time the issues were showing up again, we had added code in begin.vi to use the MXP DIO9 to select between our programming mule bot, and the competition bot, for different driveline encoder values, so the same code would run on both bots. From the GitHub comments the MXP IO was added on 2/2

We have 4 rios, and 2 navx, both are the MXP

This was with regards to last Saturday, 2/11, We tried setting the Navx Main to SPI, USB, and I2C and the error persisted. It also happens on the rios without a Navx. Not sure how it is intended to fail, if you run Navx Main without a Navx.

Yes on 2/2 we added code to look for this jumper in begin.vi, if the input is false, meaning we are running on our programming mule, we load one set of distance per count values to the encoder, if the value is true, we load a different distance per count value to the encoder.
This is being done in begin.vi, one of the first items scanned. (no error wired to force execution timing)

Send me your github id, and I can invite you to the repository if you think that will help.