Load file quicker

[siggy2xc]

My labview code has the robot loading an xml file that has been previously recorded for autonomous. There is about a 9sec lag to load a 5sec recording. Is there a way to have the robot load this file ahead of time or make it load faster?

[Vikesrock]

I doubt I will personally be of any help on this issue, but to get the best help possible from the guys here that really know their stuff I recommend you post either a screenshot or the VI for the code in question so they can see how you are currently loading the file.

No way to know if there is a faster way if they don't know what you are currently doing.

[Joe Ross]

Originally Posted by Vikesrock

I doubt I will personally be of any help on this issue, but to get the best help possible from the guys here that really know their stuff I recommend you post either a screenshot or the VI for the code in question so they can see how you are currently loading the file.

No way to know if there is a faster way if they don't know what you are currently doing.

Siggy, the same request was made in your previous thread. In addition to seeing the code, seeing the data file you are loading would help also, because there may be some features in it that would point to the problem.

Without seeing that, here are two stabs in the dark.

XML tends to be a "heavy" format. Is it faster if you save and load your data as another format, for example using the spreadsheet or measurement VIs?

It sounds like you are loading the data in autonomous independent. You could load the data in another place, such as begin or disabled, and then publish the data via a global variable to be read in autonomous independent.

[siggy2xc]

I have moved the load file vi into autonomous disabled, but there is still quite a bit of delay. Attached is my autonomous independent, load file, autoflex code, and a snapshot of where i'm loading the file. The 1st vi in the flat sequence structure of the snapshot just chooses the autonomous mode.

Autonomous Independent.vi
Load File.vi
XML AutoFlex.vi

[Greg McKaskle]

Thanks for posting the code. I still have several questions, and some comments about the way the code is written.

How much data is being written? File size and array size?
What is the typical delta between the points? I'm not sure that you really need to record at 50Hz, but that appears to be what you are doing. I suspect that 1/10th of that much data would still be a pretty good autonomous recording.

For the coding comments -- first off, I wouldn't put this into RobotMain at all. You can put it into the Disabled subVI instead, or you can put it into an independent loop, probably into periodic tasks. A few times a second, check a load or reload global or button on the panel and use the panel to show, perhaps even graph out the file that was loaded.

The Autonomous subVI has a loop with no sleeps. It spins as fast as possible waiting for the clock to pass up the retrieved timestamp. Perhaps you should instead, compute when the point is due, and sleep the loop by that amount. This will lower the CPU from guarantees 100% to far less.

The other comment about the code is that it uses far too many global and sequences. As an example, I've uploaded the load diagram written using wires to transfer the path and array. You can make the code correct with globals, but it is more difficult, and you will get burned by parallel updates or race conditions. Also, it is far less efficient than using wires.

You don't need to immediately stop using globals and sequences, they are a useful tool. But if you find yourself using them to pass data between frames of a sequence, try using a wire instead.

The code comments will improve your runtime performance somewhat, but my guess is that this is a large file and that the bulk of the time is spent loading it. Go ahead and measure that. Put a sequence around the load and the parse nodes and determine the time they take. This will be a cool tool for your team if you can get the implementation cleaned up a bit.

Greg McKaskle

[jrz126]

You may also want to reduce the number of inputs you are logging. That should cut down on the file size quite a bit.

[siggy2xc]

Thanks for all the help guys, I just took a lot of globals out of the program and also removed all the inputs I no longer needed (which is ALOT!). With as much useless data that I took out, I think it will load a lot quicker. Before I was recording 53 different inputs, now i'm at 19 and I could still remove a few more if necessary.

I'll be testing my code in about an hour, if I'm still not satisfied I'll see if I can find out how to write to a different format as Joe suggested.

[siggy2xc]

The code works now thanks to the changes you guys suggested, I never had to change the file type but I will definitely look into that in the off-season as it would be nice to have the program run without any noticeable delay at all. The one thing I noticed is that the program seemed to playback much faster in autonomous mode than it did in teleop mode (I have a mode to record it in teleop & play it back). Any ideas on what could be causing this?

[Greg McKaskle]

How much difference are you seeing? Are we talking about a small rounding error that accumulates, or something else?

Greg McKaskle

[siggy2xc]

like its running twice as fast or so.

[Mark McLeod]

Could be your Teleop loop is slower than the 50Hz packet rate.
You might be dropping every other DS packet and your playback rate would appear half speed.

Check the timing of the Teleop loop with Greg's Elapsed Times.vi under Support Code in your Project Explorer window.
Drop one copy in Teleop and another in Autonomous to compare the speeds.
View the Elapsed Times front panel while running the code from your PC.

Then match the Autonomous loop to the times you're getting from Teleop.
I'd suggest using Wait Until Multiple to get the times. A simple Wait will lag just a tiny bit every loop.