NI-Scope(+DAQmx?) property ring output to readable string

[Henrik_Volkers]

Hi,

I want to program a more generic vi to store NI-Scope (and later DAQmx) properties in a readable format (JSON string).

Some properties (like Terminal configuration here) output a ring value.

I would prefer a enum, easy to format into a readable string, but before submitting an idea, maybe someone from NI can tell why they choose a ring?

I can type cast the ring to an matching enum, but that solution will break if the ring output will be changed. 

How to solve that in an generic (and elegand) way?

Or submit an idea for a format ring to string txt vi? 

[GerdW]

Hi Henrik,

---

@Henrik_Volkers wrote:

Some properties (like Terminal configuration here) output a ring value.

I would prefer a enum, easy to format into a readable string, but before submitting an idea, maybe someone from NI can tell why they choose a ring?

---

You have the same problems with several DAQmx function inputs. I guess NI uses rings when the values behind those string labels are not starting from zero in a consecutive manner…

---

@Henrik_Volkers wrote:

How to solve that in an generic (and elegand) way?

---

Read the ring item list using a property node including their values, then use the current ring value to pick the corresponding ring item string…

[Henrik_Volkers]

---

@GerdW wrote:

How to solve that in an generic (and elegand) way?

---

Read the ring item list using a property node including their values, then use the current ring value to pick the corresponding ring item string…

---

You mean something like this (no list and index, but basically the same result I already proposed) ?

.. BUT: Will that work when in a new version of  a driver the ring values have changed?  I think NO, the ring indicator stuck to the values at the time the indicator is created.

So how to read the properties of an property output ??

[billko]

Something like this?

[billko]

---

@billko wrote:

Something like this?

---

I'm sure that even if this was basically right, Altenbach would come up with a solution with no FOR loop and just one node.  😉

[GerdW]

Hi Henrik,

---

@Henrik_Volkers wrote:

Will that work when in a new version of  a driver the ring values have changed?  I think NO, the ring indicator stuck to the values at the time the indicator is created.

---

I think it will still work: you are reading the text from the ring. And for a new version of the code you have to recompile anyway…

[Henrik_Volkers]

It's no problem to get the text of a known ring (control,const, indicator)!

An updated driver with a changed property ring output can't be captured..

And even a recompile wouldn't help, one would need to recreate a ring from the changed property ...

[Kevin_Price]

If I'm understanding your use case correctly, you're concerned about storing the *text* for a given ring value today, and then sometime in the future needing to convert that text back to the correct integer value.  And the catch is that perhaps the ring definition could change between the time you store the config and the future time when you need to retrieve and interpret it?

I would think you'd need to incorporate some kind of versioning into your config data.

So for example, today you start with version 1.0.0 of how all your config information gets interpreted.  When you store your config data to file, you'll also tag the data with your version # 1.0.0 in that same file.   Each time you read in config data, you start by reading in the version # so you can know how to interpret it.

So let's say that some years later, you find you once again need to change some aspects of your config info.  Let's call this version 2.4.0.  You'd then *also* need to create any code needed to convert data stored in any prior version to the format you need for 2.4.0.   (At this point, you'd already have made the function that converts to 2.3.0.  Your convert-to-2.4.0 function could make a call to the convert-to-2.3.0 function and then just add code for the incremental changes.)

You might make this conversion part of your app, or you might just convert the config files offline, perhaps depending on how many installations there are of this particular app.

Did I understand mostly right?  Is your concern largely about future-proofing against changes to the config data format (such as definitions of text rings)?

-Kevin P

[Henrik_Volkers]

Kevin, storing the versions and the numeric value allows to keep track, that isn't the problem. And it's more for documenting than for saving a setup and load it back.

It's a bit annoying that just because the ring output type is choosen as an property output, without the ability to get the actual ring strings at runtime to make it human readable, one is 'forced' to check  that after each update 😞

Spoiler

I'm no scripting wizzard , maybe one could (re)define type defs and write a script to check&update them after a version change ...

Since I assume that a lot of applications created setup panels by 'create control' from properties (or VIs) that arn't type defs, I hope NI will be quite conservative to change such ring contents .. 

---

@Kevin_Price wrote:

Did I understand mostly right?  Is your concern largely about future-proofing against changes to the config data format (such as definitions of text rings)?

-Kevin P

---

Yepp. No problem today, using the solution in my first post. Just getting older and see stuff running longer than expected ...

Question still remain: Is it possible to get the actual ring strings from an property output, (at runtime) ?

Seems to be possible for enums ...

[Kevin_Price]

---

@Henrik_Volkers wrote:

Question still remain: Is it possible to get the actual ring strings from an property output, (at runtime) ?

Seems to be possible for enums ...

I'm not *certain* about this, but you might need the ring to be a *strict* typedef to ensure that all instances contain the same number<-->string association at runtime.  

-Kevin P