Gyro - Running robot code from laptop issue.

Technical NI LabVIEW
1

We have been trying to debug some gyro drive straight code, and have an issue that has been posted before, here about the bad data being coming from the gyro.

We have isolated the issue, think we understand the issue, but do not know how to fix the issue, if there is a fix.

Scenario, you are using labview, you load your code from the laptop, and are running the code from the laptop, so that you can debug.

You enable the bot, gyro is giving good data, you probe, data, see an issue in the code, disable the bot, stop the code from the labview laptop, using the stop sign icon, and fix the code.

At this point you click run again in robot main, and the gyro now is not giving correct data, growing, spinning, etc.

You stop the code, load up the gyro example, everything works, load up the robot code, everything works with the gyro, stop the code, gyro never works the second time.

Now that we have seen this scenario, we can reboot the crio each time and the gyro responds as expected.

We know that when you hit the stop button on the labview laptop, you are aborting code, and the cRio stops without going through the normal shutdown sequences, with the close.vi and closing all the refnum’s. We think that this is the main issue with the gyro code.

Question, are we doing something wrong with aborting the code this way, with the stop icon, and we should be stopping the code where it can finish and exit through the close.vi ? Is that even possible?

Have other teams seen this scenario? Can it be coded in a way where this can be avoided, or do we just need to power down between debug sessions, which is more time consuming.

Scott
TORC2137 Programming Mentor.

2

I don’t seem to have any problem.
I just ran a test and the gyro is responding properly after a run-re-run.
Anything else that might be a contributing factor?

3

I am sure there is…

We can run the example code just fine, stop, restart.

We put our drive straight.vi in teleop in a robot project and tested, and that is where we have the issue. We spent the day testing all of the gyros, and analog cards yesterday, and everything was in working order.

Thanks for looking into it, love the website, it is my goto for anything electrical.

4

The likeliest possibility I can think of is that the robot isn’t left to sit still long enough the second time through to allow the gyro to initialize and establish a zero movement point.

I should have addressed the matter of Finish.vi, since you asked and you say such nice things.
Normal robot operation/termination never goes through Finish.vi.
The power just gets cutoff and the code ceases mid-execution.
The Stop sign on Robot Main functions the same way.
That big “Finish” button in Robot Main is the only way that Finish.vi ever gets executed.

5

Well, I guess I’ll say some more nice things… :slight_smile: your cute too.

But the robot was not moving, we had it on “stilts”, that is what the kids call it, when we have it on 2x4’s so the wheels don’t touch the ground.

We will keep digging tomorrow. Thanks for the info on the big finish button, I was told this leaving the code hanging with the stop button, is sometimes a problem, by someone that uses Labview everyday.

I understand much of the control code, and understand labview, but stuggle with many things in Labview itself, I am a PLC guy by trade…

Thanks again.

6

The Stop button can be a problem in the commercial world for the same reason we bother with teaching the students to close opened devices in Finish.vi.

When the students move on from FRC and run into LabVIEW later in college or in the working world, some classes of peripheral devices must be shutdown cleanly or they won’t initialize properly when LabVIEW is later reconnected to them. FRC just doesn’t happen to use any data acquisition devices that are susceptible to that.

Finish.vi is there to teach them good habits even if it doesn’t fit our particular use case.

7

Mark,

Do you think it could be that the code is given the “reentrant” property? I am not sure if I spelled that correctly, but the property where labview will spawn a new “object” each time the vi is called, so you can have multiple sub.vi’s in the code, and they will not interact with each other?

Just trying to think about what the issue may be.

Scott.

8

Being called from a reentrant vi shouldn’t affect the Gyro Get.
It’s still just operating on the device reference given to it and simply reading the counter published by the FPGA.

If you have a simple case that repeats the problem someone could take a look at it for you. I have a small window to look today, but I’ll be volunteering or attending events with my team after today.

9

My son just told me that I have stated this wrong, it is not when the code is stopped from the programming laptop. The issue is when the drivers station is enabled, the data is good, and after the drivers station is disabled, and then re-enabled without stopping the code on the programming terminal, the second time the gyro data is not reliable.

Does this change anything? Thanks again.

Sorry.

10

Does it depend on how long the code/robot is disabled? The errors will accumulate over time, and restarting the code will calibrate again. If the error is caused by running the code for five or ten minutes while the robot is disabled, then yes, I think that explains it to me. If it happens for a disable of a few seconds, then it doesn’t.

Greg McKaskle

11

If it’s happening while Disabled, then you can read/display the gyro in the Disabled.vi to watch it while it goes awry. I imagine the center point calibration is off kilter. There are some calibration options on the Gyro Open that you can tinker with.
Disable only stops motor/Relay outputs, everything else keeps running, including the gyro.
Maybe it’ll be enlightening.