NetworkTable save and read Entries causes persistent exception

Anyone try to use NetworkTableInstance.getDefault().saveEntries() or .loadEntries() with success.

I’ve tried both of the following and receive a persistence exception when either runs.
I’ve tried both “swerve” and “swerve.ini” for file name and both fail with exception and stack dump.
OffsetTable is “SmartDashboard/Swerve/AngleOffsets/” … I’ve tried this both with and without the last “/”.

NetworkTableInstance.getDefault().loadEntries(swerveTableFile, offsetTable);

NetworkTableInstance.getDefault().saveEntries(swerveTableFile, offsetTable);

Is there a special format for file name or does it have to have a full path? If so what should be used?

Is there special format for the prefix? The prefix is the same that is used to create the keys in the network table… and I can see the network table entries in the correct tree location in outline viewer.

I can’t find an example of this or another post where it’s used.

What is the exception and stack dump? If you don’t provide an absolute path to the file, it will assume the current working directory, which is typically /home/lvuser on the RoboRIO. It has to be the actual file name. Are you deploying the .ini file to the robot? You shouldn’t be getting an exception on saveEntries. You’re right that these functions are rarely used, so it’s entirely possible there’s a latent bug.

I’m away from our school and dev system now so it may be next Wednesday before I can get a copy of the stack dump. There was no error other than persistence exception or it may have been persistent exception … then a list of line numbers in a series of java files.

We’re not copying a file to the rio so we expect to get an error in attempt to read. However, we should be able to do a write without error and then follow it with a read after the file is created. We’re using the same parameters for both the read and write.

I think I’m going to try … should be the same result but seems like first code should also work.
NetworkTableInstance.getDefault().getTable(offsetTable).loadEntries(swerveTableFile);

Here’s the actual code and a screen shot from outline viewer:

try {

  System.out.println("SwerveSub::writeAngleOffsetsFile Saving swerve offsets");
  System.out.println("table prefix = " + offsetTable + " filename = " + swerveTableFile);

  NetworkTableInstance.getDefault().saveEntries(swerveTableFile, offsetTable);

} catch (PersistentException e) {
  
  System.out.println("SwerveSub::writeAngleOffsetsFile Error writing angle offset file");
  // TODO Auto-generated catch block
  e.printStackTrace();
}

image

Stack dump:

  • SwerveSub::writeAngleOffsetsFile Saving swerve offsets

  • table prefix = SmartDashboard/RobotBase/Swerve/AngleOffsets/ filename = swerve

  • SwerveSub::writeAngleOffsetsFile Error writing angle offset file

  • edu.wpi.first.networktables.PersistentException: could not open file

  • at edu.wpi.first.networktables.NetworkTablesJNI.saveEntries(Native Method)

  • at edu.wpi.first.networktables.NetworkTableInstance.saveEntries(NetworkTableInstance.java:997)

  • at frc.robot.subsystems.SwerveSub.writeAngleOffsetsFile(SwerveSub.java:200)

  • at frc.robot.subsystems.SwerveSub.lambda$createNTvariables$2(SwerveSub.java:54)

  • at frc.robot.utils.UtilsNetworkTable$NTvariable.lambda$new$6(UtilsNetworkTable.java:139)

  • at edu.wpi.first.networktables.NetworkTable.lambda$addEntryListener$1(NetworkTable.java:191)

  • at edu.wpi.first.networktables.NetworkTableInstance.lambda$startEntryListenerThread$0(NetworkTableInstance.java:262)

  • at java.base/java.lang.Thread.run(Unknown Source)

Okay. Definitely try doing the full path "/home/lvuser/swerve.ini".

Full path seems to run without causing stack dump.

We’ve a workaround writing directly to binary files using our own methods.

The network table write method said that it executes properly but the values don’t seem to read back in correctly…

We’ll look at this in more detail if we have time later. For now we have the workaround.
Thanks

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.