Dear CD,
I have been running FRC3548 team robot code on the cRIO2 successfully for some time and am finally getting around to program the original cRIO because the cRIO2 is headed for the robot this weekend at Waterford, MI.
I was success in re-imaging the cRIO from v28 to v43. I was able to deploy and execute the Run at startup command and hit the reboot cRIO as expected.
However, on the driver station the top light goes green but not the bottom light - it remains red (sorry not looking at it right now for proper description).
Any suggestions on how to proceed? Same Labview code, same bench, same ca bles, same Labview IO modules - etc. Only thing different is cRIO.
Try enabling NetConsole using the Imaging Tool and watching the NetConsole information during the robot boot-up to see if it shows any error messages.
Does it work if you try to run an unmodified default project?
The physically larger cRIO is smaller on the inside. There are some features left out of the image when it’s installed on an 8-slot cRIO because they won’t fit. Are you using vision processing?
Alan,
I’m not using any vision processing per say, the base program is installed but no additional software has been added.
As Alan said, please test running an example or basic framework. There are a number of differences in the image, but all test programs are run on both four and eight. If you don’t get it resolved, please contact NI technical support and supply your project code. I’d offer more assistance, but I’m out for spring break, after we finish up with WPI regional.
Greg McKaskle
Finally getting around to updating this post after Waterford, MI district tournament.
Alan, I took your basic idea and proceeded. I was able to run the original cRIO by returning to an earlier version of the team program - so everything operates as expected, although it seems like I need to fight with the original cRIO more in order to update the firmware and download team code.
The primary difference between the earlier version and the latter versions are the size of the autonomous program. Earlier, I had 15, individual one second structures(term?) like the example code in a sequence. For latter versions, I added 3 more copies of the first and began making modifications. With the 4 versions of the autonomous sequence I suspect I maxed out memory and/or throughput. ::ouch::
Does anyone have a simple means of determining if I maxed out memory on the original cRIO?
The Charts tab lists the free RAM, largest free RAM block, and free flash to the right side of the window.
What are the numbers, and do the change over time?
Greg Mckaskle
Greg,
Here’s the entire FRC3548 V28 Robot project.
Wow, that really sucks up the memory doesn’t it?
The project requires 28 MB of RAM.
17MB of that is just the Auto vi.
An FRC II has ~72MB available after the OS and other NI software load.
An FRC I has ~26MB available after the OS and other software.
It only leaves 44 MB free on an FRC II, and blows away an FRC I.
The biggest problem is the repeated references to the same sub vi’s such as Motor Set Output.
The VI Properties->Execution (under File) are preallocating a clone for each instance. You probably want to change that to “Share clones between instances” to preserve memory.
Mark,
Thanks for analysis - what I expected - memory hog with 4 copies of autonomous program structure. Can you make a recommendation of how to restructure the autonomous part? I tried a partial conversion to flat sequences with just one parameter sequence for Motor 9 but Labview complained profusely so I gave up that strategy for the moment.
I tend to think differently and not break auto into one second increments, but there’s no problem with doing it you way you’ve chosen to. You just need to minimize the duplicate copies of code. What you’ve done can be made over into a sequence, but it’d pretty much look the same.
Here are my suggestions to cut the memory way down (to ~10MB altogether).
Open up Auto:
-
Double click on one (only need to do one and the rest will follow) Motor Set Output to open it up, choose File->VI properties and go to the Category: Execution. Choose “Reentrant execution” and “Share clones.”
-
Do the same for Tank Drive and Relay Set.
-
Get rid of the error messages (the drive train name has an extra space in Disabled), that are maxing out your cRIO CPU utilization. That can cause a problem linking to the field while Disabled.
Mark,
OK - I gave up on the 15 - 1 second Autonomous routine configuration and went back to last year’s very simple Autonomous routine using timers. This setup starts with motors on/off and when the case structure boolean changes due to the autonomous time the motors on/off state changes. I also did the VI properties execution re-entrant share clones step you mentioned above and the Drive4 Motors name issue.
However, the symptoms remain. Motors 7 to 10 turn on and off intermittently on the bench even though the motor output is on constantly during autonomous. I saw this behavior on the robot itself, initially missing this
behavior on the bench. I have verified that it is not a PWM cable/Jaguar/Victor type issue. I can see the behavior on the PWM dashboard display as well.
There must be some routine timing out or interrupting this simple autonomous routine. Can you take a quick look and provide some feedback?
FRC 3548 V34 27Mar12.zip (803 KB)
FRC 3548 V34 27Mar12.zip (803 KB)
I’m not sure why they aren’t all twitching.
It looks like Periodic Tasks keeps setting the same motors as autonomous, just more slowly. Whoever is last wins. Sometimes that’s probably auto and other times it’s going to be Periodic.
Auto wins more often just because it’s running twice as fast as the Periodic Tasks loop.
Mark,
Thanks for input. I will try some different things when I get home. I’ve completely rewritten the Auton ring a few
times and suspected outside interference from another Labview operation.
-
Will changing tunnels to shift registers in Periodic and/or Auton help the situation? Doesn’t this pass info from end of loop to beginning of next loop event perhaps overriding the Periodic Loop values?
-
Should I make the 100 msec Periodic Loop even slower, like 250 msec to help the Auton last output
win more often? -
So during Auton, periodic operation continues and outputs values? Hmm! that seems counter intuitive? That means Auton and periodic are paired and TeleOp and periodic are paired. Need to stew on this a bit.
I’m jumping into this one late, but my advice is to decide which output is correct and only update with the correct value. Updating with correct and incorrect values almost randomly will not improve by using shift registers vs tunnels. Changing the rates only statistically changes the amount of time that a given motor value is correct. During Auto, do you want the periodic values at all? If not, use a global Boolean to skip all periodic updates that conflict. In tele, flip the Boolean to use the periodic values. If that isn’t quite the right logic for which to use, determine what that logic is first, then look for a clean way to implement it to avoid the inconsistent writes all together.
Greg McKaskle
Wahoo! finally works with everyone’s help. No more buzzing/intermittent operation of my shooting motors during Auton operation.
Stewing on the Auton and Periodic linkage (Mark) on the drive home from Pontiac, MI to Royal Oak I began thinking about how to disable the Periodic functions during Auton without changing my basic programming structure (using large case statement ring around nearly all periodic functions). Then, I read your message, Greg, and was off to the races. I am using continous, free-running timer inside Auton and made a simple compare statement inside Periodic to make sure I was above 0 seconds while below 15 seconds and voila! no buzzing.
Thanks Mark, Alan and Greg for you help! Now, I’m ready for the Troy, MI district tournament starting tomorrow ready to score in Auton.