Importing .bin file

[rdp137]

Has any one had any luck programmatically importing the .bin configuration file? I am trying to do it in labview

[ryanvallieres]

Hey @rdp137 If I understand your trouble correctly, you're trying to do the following:

1. Construct the .bin configuration file externally in LabVIEW or something else.
2. Edit the system definition file dynamically to include the .bin file.
3. See the UDP Custom Device change based on that import.

Does that seem like an accurate assessment? Even if it's off by a bit, I think have some insight for you:

1. The UDP CD actually supports both .bin and .xml formats. If it's a formatting issue, you may get better luck out of using the .XML format. Else, I would suggest grabbing the .bin file type definition from the source code to get the right format.
2. Technically this is totally doable. But it doesn't do a whole lot actually due to 3.
3. This is where things get stuck in the mud. See below -

---

Configuration loading is considered an 'action' by the custom device. This means that the very act of loading a configuration file into the UDP Custom Device results in a chain of actions that parse the contents of the configuration file. This information from the file is then cached in memory until the system definition is saved. Upon save, that cached data is then pushed into the system definition file. When the custom device is deployed, that configuration data is read from the system definition file, serialized out to the RT target, and then handled by the runtime logic for the custom device (the engine).

The way this differs from programmatically editing the system definition file, is that you haven't had the configuration import action occur. No information has been read from the configuration file, it has not been cached into memory, and it has thus not been stored back into the system definition file.

This is all just a long way of saying,

it's not going to work like that.

In fact, the vast majority of custom devices out in the wild actually work like this. They have a local format for storing config data that can be 'imported' and merged into the system definition. In practice, this saves a lot of headaches during development, since we can just leverage the system definition file transfer for configuration. Developers don't need to include extra dependencies in their custom device XML, worry about default values with missing files, or make their deployed engine code heavier with file parsers.

---

To close up this response a bit - is it possible to get this to work today? Yes and no. Yes - Every value that's stored in the .xml/.bin files is stored in the system definition file. It won't be easy, but you you could always push that information directly into the file into the correct XML tags. No - There's no way that I know of right now to trigger that 'import' action to occur without opening the system definition directly and making a new instance of the custom device (or using the import function in the toolbar). There might be something tucked away in the Veristand .NET API though.

[rdp137]

Thank you for that detailed answer. Maybe I’m thinking about this incorrectly. All I really need to do is to change a few IP addressees programmatically. Otherwise I need to maintain multiple system definition files just for my different IP address configurations

[ryanvallieres]

Not a problem!

I haven't looked into the system definition file myself lately, but changing the destination/source addresses directly in the system definition file is the way to go here. I'd suggest making a backup of the file before taking any whacks at it though.

[ryanvallieres]

Just wanted to show what this data might look like in the raw system definition. You can see the local NIC address called out for this received packet (buffered) on lines 269 and 270. It's encoded as a binary string - so it's not entirely obvious what is being stored there. The value in plaintext is 'localhost' though.

[ryanvallieres]

Best I can tell so far, it's encoded in base64? You'll need to do that conversion first before pushing values into that field.

https://en.wikipedia.org/wiki/Base64

[ryanvallieres]

Turns out there's a pretty hefty set of VIs and examples to this:

https://forums.ni.com/t5/Example-Code/Fast-Base64-Encoder-Decoder-using-LabVIEW/ta-p/3503281?profile.language=en

They appear to work for this case too.