We have a vi that generates values for our elevator. It uses two copies of a sub-vi, which calculates a motion profile. It ran great yesterday, so we decided to plop it into our robot code.
In testing today, things just didn’t run right. No problem, we thought, we’ll just tweak it some more off the robot to see what wasn’t going well. That’s when we hit a problem.
Now, when we try to run the elevator vi by itself, it fails with allusions to running out of memory, and points to an array initialization in one of the sub-vi. We tried deploying the code to the robot, which doesn’t throw any errors, but nothing happens. For some reason, we can’t run the vi by itself anymore. Now, no matter what, we cannot get the vi to compile to run on the PC. It only does math, and doesn’t control any motors directly.
We are able to run the sub-vi in other vi’s, without issue. The problem seems to be localized to running the sub-vi under our elevator vi.
We’re stumped. Could it be the FRC update (which we installed this morning)? It worked perfectly yesterday, and we did not change anything in it. I’ll include a screen shot of the error later. Our school blocks chief delphi, and I’m writing this from a mobile device.
OK, we know now that it isn’t the FRC update. We pulled the code over to a non-updated computer and had the same issue.
It is almost as if adding the vi to the robot project poisoned it from running independently. We cleared the compiled object cache (several times), and nothing helped.
Curiously, the first time we tried to run the vi, we got an error message that said there was a generic problem with the sub-vi. The next time we attempted, we got a more specific message, that indicated an array initialization as the problem. We replaced the array initializer with a for loop with an indexed output, and still go the same error, this time implicating the for loop structure.
No problems with this sub-vi in building the entire robot project, or in running under another vi which is not targeted at the roboRio.
I’ll be happy to look at the VI. You may just be able to post a picture of the diagram, but it may be better to PM me, I’ll give an email, etc.
My guesses without seeing the VI is that the value going into the initializer is a huge number, and to allocate that much would truly fail. I just did it and received the same dialog. One of the things about RT is that the error handling is a bit different. We pipe most of the errors to the DS. So I suppose this could happen on RT and simply fail differently.
If you choose to debug it yourself, probe the dimension size(s) and see if they explain why the dialog is coming up. Then, of course you’ll need to work backwards to see why this function is calculating or being given bogus inputs.
Thanks for the reply Greg. That’s the wierd part for us, we aren’t passing big numbers to the initializer. The size is calculated at run time. When we use the exact same number inputs from a vi that hasn’t been incuded in our robot project, everything compiles and runs fine.
We were trying to debug our elevator code offline, because one case that we tested on the robot generated different numbers than we got when we built and tested the logic offline on the PC.
Elevator.vi - our problem child
Motion Profile Filter.vi - The sub-vi
Filter Tester.vi - VI that runs fine with no compile issues, containing the sub-vi.
I think I found the problem (smacks forehead). I’ll have to check in the lab tomorrow (no LabView access today), but it seems that we have a few uninitialized feedback nodes. These may be feeding garbage as inputs to the sub-vi, which may be causing the issue.
We added the lowering logic at the very end of the night, so I can see how this was missed.
Well, we fixed the problem. We made a change to our motion filter sub-vi.
I think the issue is that although we set sensible default values that should have given a sane size for the array at compilation, there was no error checking to catch insane values or sizes that may be undefined or not a number. The array initializer wants an integer input for the size, rather than an unsigned int. For all I know, the value the compiler could have been accounting for may have been a very large negative number.
We coerced the array size to between 1 and 10 elements, which is generous for all of our anticipated use cases. We can always bump up the upper limit if we need a slower ramp rate.
If you are interested, the code is at our git repository, posted above.
Hi Tim. Yes, we made them re-entrant. That’s standard practice for us for sub-vi’s, as we tend to make utility functions that can be used in multiple places. The motion filter used here is such a vi, as we are using it in our autonomous to generate acceleration and deceleration for more repeatable robot placement.
This problem was hard to diagnose, because we couldn’t get to a running state, except in a non-interactively deployed running of all of our robot code. I think we tried every iteration that we could find on the execution pane of VI preferences, just to try to shake out any clues.
Schooled. I didn’t finish reading the thread. I had been trying to teach re-entrant lately, and had array initialization problems for a while…
After the season’s over question:
Did you really need 4 state bits (well, 5, there’s an integer masquerading as a state bit)? I love programming; there are so many answers to a question
