Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reading a SLSC Capabilities from File Can't Get the Default Values #17

Open
Alexbarp opened this issue Apr 3, 2019 · 2 comments
Open

Comments

@Alexbarp
Copy link
Contributor

Alexbarp commented Apr 3, 2019

In the version 1.1.0 of this CD, if you try to load a Capability from a file (which we can call it "offline"), then the existent JSON JKI parser is not able to define the "default" values in the capability. This happen because that information is in the "registers" and not in the properties, so the parser has to do that. In this meanwhile, if you want to obtain the "default" values, the best way is to read the Capabilities from a online card and, then, Export the parameters. Then, you can just read this file afterwards (better than trying to just a raw or capability file.

To make the transition easier, SLSC R&D was able to create an API that allows you to do such work. It would be advisable to use this API instead of the JKI tool: https://github.com/ni/slsc-capability-explorer. Also, this new tool uses RapidJSON. which is faster. However, this API only support 2017 and up. @jashnani , @csjall , @buckd

@Alexbarp
Copy link
Contributor Author

Alexbarp commented Jan 8, 2020

Hey @Austrim and @Karl-G1 , I am tagging you so you can "manage" this request. This request is not very "hard" to be done and the benefit is considerable. If we change from JKI JSON parser to the RapidJSON, then this API above could be leveraged easily. That also only requires you to change one place in the custom device, so I think we should consider scheduling this before the next release of the EDS.

@Alexbarp
Copy link
Contributor Author

Alexbarp commented Jan 8, 2020

And one more comment: since in VS 2020 we make the earliest support version of VS 2017, this could be a good opportunity to remove the extra code necessary to support VS 2015/VS2016. That way, this can make a lot of the code branches not necessary anymore (or the extra XML file for previous version).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant