LabVIEW
Flatten to JSON String - Can I wire a variant to its input?
Solved!
Hello Fancy Folk,
I am running into an issue with the Flatten to JSON vi being used in a subVI and I was wondering if anyone has a work around. TLDR, is there a way to wire a variant to the input of the Flatten to JSON or is there a way to keep the “Anything” control from JSON as an FP control?
Background:
I want to make a DQMH module that lets me save/load FP controls. I believe that using JSON will be the easiest way to do this since JSON seems to be about taking complex data types, converting it to a string, sending it somewhere, and converting the string back to the complex data type. My idea is to save off control values as JSON strings and save those strings to a text file, then when I load them back, convert the JSON string to the control.
Issue:
For all of this to work, I believe I need to have my DQMH module use a variant as the data type being requested/broadcasted since my data could be anything from a bool to a cluster to a class. The issue that I have ran into is that when trying to wire a variant into the Flatten to JSON Vi, I get an error stating that the polymorphic terminal can not accept that type (see image below). This makes sense to me because the Flatten to JSON string needs to know what type of data that is being written to is so it can create the string.
The other thought that I had was to wire the “Anything” terminal from the Flatten to JSON as a control, but that creates a void wire type which breaks the Vi, see image below.
What I’m looking for:
I am trying to see if anyone has any work around to my problem. I’m trying to make it as easy as possible to save any data type to a file and then load that data back in without having to create the entire save/load scheme from scratch every time. My other thought was to just use a variant to save my data, but I have no idea how I’d be able to pick apart and rebuild clusters in the DQMH module.
Thanks,
Matt
What do you mean by native datalogging? I am assuming you mean writing to text/ini files. At the end of the day, the JSON string will be saved to an ini file, I'm just trying to use JSON's "we can save anything as a string" ability.
However, instead of having to write custom code to take take all the FP and aux controls out from clusters/classes, dump that into a text file, I could just send all the controls to the flatten to JSON and save off the resulting string to said text file. Likewise with loading, I'd have to write custom code to load the data individually and shove it back into the proper clusters/classes instead of loading the JSON string and running the unflatten from JSON function and cast it back to the proper form. Yes, I'd still have to write some custom code for loading, but that code would be waaay less than having to rewrite the scheme every time since all I'd have to do is cast the data after the unflatten structure. The analogy I'll make is like you can either use the project template to create a consumer producer setup or you can manually create the consumer producer set up every time you want to use one and this DQMH module would be the project template.
Basic flow would be something like the below image. All my actual project has to do is know how to cast the resulting JSON string to the proper control.
Matt
Edit: changed text file to ini file
@JÞB wrote:
They have been there forever but, they seem to have had a really bad PR agent. About once every decade someone finds where a previous developer used them and asks "What th F is This?" On the forums.
I've only seen it in the wild once.
I tried to use them in the beginning (about 30 years ago for me now) several times. And found they work in a way if you have a front panel that you execute over and over again for an experiment and then want to replay the experiment series. But if you build a larger fully integrated application, it tends to be more hassles in the long run than what I felt happy to put up with. They did teach about this feature in the LabVIEW Basics Course back then however!
