From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

FIRST Robotics Competition Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Error reading file on the cRIO (error 1430)

The idea is to log driver inputs for a 15s duration that will be played back during autonomous to let the team come up with some pre-loaded programs to run depending on their initial position.

Theoretically, the path that they record would be the path auto-driven if there aren't collisions as it would replicate the driver's inputs in approximately the same time resolution.

We haven't had time to get the camera running, nor any of the playing surface to practice on, so this was my idea to make something simpler to create than reading sensor values and whatever on their practice day before the competition.

I've saved a file to the cRIO using logging as /data_log/test.dat

using the 'Picture_Write.png' code pictured.

Then I try to load the file back in (stored on the cRIO ) using the 'Picture_Read.png' code pictured, but I get an error:

Error 1430 occurred at Open/Create/Replace Datalog in Autonomous Independent.vi

Possible reason(s):

LabVIEW: The path is empty or relative. You must use an absolute path.

/data_log/test.dat


so the same path works in write, but not in read.

I've run this in a stand-alone vi and it seems to work fine. The values seem fine 'replaying' the files on a PC indicating that it actually logged OK.

All I need is to know how to correctly reference the files to create the 'absolute path' when in playback mode.

Thanks for the help.

Regards,
Sten

Download All
0 Kudos
Message 1 of 6
(9,947 Views)

oops. forgot the 'Read picture'

0 Kudos
Message 2 of 6
(2,880 Views)

I'm somewhat surprised that the path works at all the way you have it formatted.  Try using a standard windows-style path (C:\data_log\test.dat); you might need to switch the back-slashes to forward-slashes. You can find out what an absolute path should look like on the cRIO by putting an indicator on your front panel connected to a function such as Current VI's Path.  It's possible that the string-to-path function in your write is modifying the path in a way that isn't happening when you pass in the path directly in the read function; try probing the output of string-to-path.

I assume you're renaming your test data so that your read function can find it.  Also, when you're reading you're passing in a different data type than when you're writing (the writing includes an integer that's unused in the read).  You do not need the "deny write-only" nor the function to which it is wired.

0 Kudos
Message 3 of 6
(2,880 Views)

Thanks for the reply nathand.

I was going on the assumption that the cRIO uses a LINUX type file structure with a root '/' path. I probed the paths and they were the same format.

So giving it a c:\ type of path, the program wont be confused by the naming if I'm in windows with the files living on the robot, or should I create a directory in windows to match?

Yes, I am renaming the test data files. I figured they'd do several runs with logging and pick the best few as their defaults and rename them as like 'position_a.dat' etc with an enumerated case structure based on some physical switches on the driver's station to pick which they would use.

Thanks about the 'deny write only' I just scrounged that out of an example, but the program never got that far when it couldn't find the file. Didn't seem to damage anything when running on the pc.

I realized that I discarded the time data all-together before after I had taken this screenshot, when I thought that might be an issue and before I discovered the file path problem.

0 Kudos
Message 4 of 6
(2,880 Views)

A correction to my previous comment: the correct form of a path for the cRIO when using a path constant is /c/path/to/file.txt, not c:\path\to\file.txt.  If you use build path (and maybe also string to path), it should fix it for you automatically.  See this knowledgebase article.

There's no overlap between the cRIO filesystem and your Windows filesystem, so you do not need to have matching directories.  When you run your program it downloads to the cRIO, executes on the cRIO, and uses the cRIO filesystem.  In order to run your code on Windows you need to specifically tell LabVIEW to run the VI on your Windows machine by right-clicking in the lower-left corner of the VI window and selecting "My Computer" as the target (and if you do that, your code will, of course, use the Windows filesystem).

If you regularly plan to run the same VIs on both your cRIO and your Windows machine you can have your code determine on which system it's executing by using a property node, with the property Application->Target->Operating System.  Connect the output to a case structure that contains the correct path for each operating system on which you might run your code.

0 Kudos
Message 5 of 6
(2,880 Views)

Thank you very much for the update. We'll get to try this out tonight, I think. I've had very sporadic access to the cRIO, which makes testing hard to do.

Best regards,

Sten

0 Kudos
Message 6 of 6
(2,880 Views)