bjustice

Thanks JDP for the background information.  I just kudo'd your idea.

Our code supports nested and arrays of classes that inherit from the base "Serializable.lvclass" gracefully.

Classes are represented as a nested cluster in the serializable string (JSON, XML, TOML)

Objects that don't inherit from the base "Serializable.lvclass" are treated in the same manner as JSONtext handles objects... flatten/unflatten from string.  If error on unflatten, then return default object

We adopted the notion that classes must inherit from a base "serializable.lvclass".  This activates the Project Provider plugin (project tree scripting methods).  We didn't see a convenient way around this, and we didn't see this as too much of an inconvenience.

Where we noticeably diverged from AQ Char Lineator is that we (through scripting) create a "SerializableData" cluster typedef that gets dropped into the class private data.  Only data within this cluster is consumed by the serialization framework.  all other data is ignored.  This simplified things in that we only need a single future-proof data read/write accessor for this cluster.  A user can update serializable data by only editing this typedef... they don't have to touch any VI source code.

Pros and cons to this solution.

2 minutes ago, pawhan11 said:

Also worth to mention:
https://forums.ni.com/t5/Actor-Framework-Documents/AQ-Character-Lineator-working-draft-version-of-serialization/ta-p/3512840?profile.language=en

Yes!  Did a deep dive through that code as well.  We're taking a similar approach

While researching this, I discovered 2 other projects that solved serialization of objects using (de-)composition of private data using the flatten to string and TypeDescriptors:

JSONtext branch with object support:
https://bitbucket.org/logmanoriginal/jsontext/src/lvobjectserialization/

paid 3rd party library "JSON Object Serialization by GCraftsman":
http://sine.ni.com/nips/cds/view/p/lang/en/nid/215788

I would certainly be interested in taking a look.

Internally, we made the early decision that we didn't want to directly access class private data through string flattening or by inspecting the class' *.ctl file.  We felt that this violated the covenant that class data should only be accessed through data accessors.  As such, we moved towards a Project Provider plugin framework that scripts accessing of class private to work with our serialization engine.

LabVIEW 2013 SP1 32-bit yields proper behavior for fixed point:

Just to confirm, do we want to continue to build this OpenG VIPM package for LabVIEW >= 2009, or upgrade to LabVIEW >= 2013?

I was going to use "LabVIEW Class Instance" in an effort to somewhat standardize with the modern NI datatype palette:

3 minutes ago, Jim Kring said:

I just looked at some statistics and I think it's safe for us to upgrade this library to LV2013.

 

Can you try re-running your fixed point experiment in 2013.

sure thing, in work

Interesting, "Only used internal to LabVIEW" was a conscious decision within the OpenG toolkit.

Any notion why this was the case?  Is it time to reverse this decision?

Per: https://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/type_descriptors/

Quote

The first word (16 bits) in any type descriptor is the length, in bytes, of that type descriptor, including the length word. The second word (16 bits) is the type code. LabVIEW reserves the high-order byte of the type code (the xx in the following tables) for internal use. When comparing two type descriptors for equality, you should ignore this byte.

I wonder if the fixed point was in some sort of weird BETA state in LV 2009

Not sure if this is relevant, but here is LabVIEW 2019 SP1:

Here is LabVIEW 2009 SP1:

The hi(x) byte is marked as "Private" within OpenG, but it seems suspicious to me ^

Well, I just encountered a weird issue with the Fixed Point data type.
Here is code in LabVIEW 2019 SP1 32-bit:

Here is code in LabVIEW 2009 SP1 32-bit:

I'm not immediately sure what to make of this

Ok, so, now knowing this information, it seems like the following needs to happen:

• Add the following to: "Type Descriptor Enumeration__ogtk.ctl"
  • "Fixed Point"
  • "Map Collection"
  • "Set Collection"
• Add the following to: "Refnum Subtype Enum__ogtk.ctl"
  • "LabVIEW Class Instance"
• Update the holy LabVIEW wiki

It's interesting to learn here that we can't 1:1 match "Type Descriptor Enumeration__ogtk.ctl" to "NI_Data Type.lvlib:Data Type.ctl" since these are inherently different

yepp, I also found this:

https://labviewwiki.org/wiki/Refnum_descriptor

Relevant test in LabVIEW 2019 SP1.
It looks like the Lo(x) of index:1 is no longer enough information to discern between a refnum and a LabVIEW Class Instance.  I need to figure out how to properly differentiate between Refnum and LabVIEW Class Instance

At an absolute minimum, would there be any interest here in releasing a new update for the OpenG LabVIEW Data VIPM package to include the following datatypes in the OpenG TD?:

• LabVIEW Class instance
• Map
• Set

It seems like this would be an easy and backwards compatible update.
I make this request because legacy code such as EasyXML heavily leverage the OpenG TD.  It would be minor hassle to replace this with the native LV TD.

I now understand why James made this SubVI for his JSONtext library.
I hope that he built this thing with scripting.  Brute force, but seems to work well.

I did a deep dive into JSONtext, JKIJSON, and into EasyXML.
I made a few interesting observations after doing a bunch of work to integrate object serialization into a branch of these libraries.
Basically, beware usage of OpenG LabVIEW Data Palette SubVIs when working with LabVIEW objects

1) The OpenG TD doesn't include "LabVIEW Class Instance" (or any of the new datatypes either... maps, sets)

2) In the following code, note how the top method produces an error, but the bottom method is fine:

3) In the following code, note how the top method produces an error, but the bottom method is fine:

I feel the need to highlight the absurdity of how Shaun answered this question within 4 hours... about a post that he made 10 years ago.

This community is amazing

Upvote Scratch.

I used to teach scratch to 12 year old kids at summer robotics camp.  Very approachable, fun to make games.

Lego Mindstorm is another good one

Riiight, so Hooovahh is hitting the nail on the head here with my thoughts exactly.

Quote

I'd estimate I probably have wanted to create a constant, control, or indicators from those conditions probably 5% of the time.  The other 95% I want to change the tunnel options or make that datatype the selector input.

It would have been nice to maybe make the plugin menu a bit more intelligent such that it wouldn't have these "create constant, create indicator, create control" for these situations.

The consistency argument is interesting and not something that I had considered.

Give me 2 months with this new change, and I'll report back on how my muscle memory and opinion has changed.  I might indeed be the old man yelling at a cloud right now.

I'm trying to beat Darren for fastest programmer in the world, so muscle memory plays alot into things like right click menus and quickdrop names

I've started working in LabVIEW 2019 SP1, and I've observed that the right-click menu on the block diagram has changed such that "create constant/control/indicator" are always at the top for almost every block diagram action.  Example:

If I recall, this was a pretty popular right-click menu plugin that alot of LAVA folks were using in prior versions of LabVIEW.  It looks like NI simply cemented the idea in base LabVIEW 2019.

I'm just curious though, does anyone here find this annoying?  It's really wreaking havoc on my muscle memory.  Furthermore, in situations such as above with a case structure, I'd much prefer the "Replace with case selector" to always be the top-item

I've not run into a situation where I've needed to get the actual image data into LabVIEW.  I've mostly needed to handle file streaming to/from disk.  It would be easier to use files on disk as a middleman between LabVIEW and FFMPEG.  If you need a live streaming solution to LabVIEW, then you probably need a different technology

I've never run into the situation where I've needed to send the "q" command.  The ctrl-c command exits properly for everything I've needed, even for bad commands or non-connected cameras.  I've not run into any crashing

I've attached an example of a piece of code that will stream an RTSP stream to a file on disk.  This also contains a copy of a FFMPEG build that I've found to be pretty stable.

I'm not sure that I fully understand what you're trying to do

distro.zip

Thanks Hooovahh, I've used your TDMS concatenate VIs in a few places.  Really convenient to see this wrapped in a VIPM with a few other tools.  Will install this right alongside Hooovahh arrays