Stobber

I want to decouple the producer of a set of data from the consumer which turns the data into a formatted string. The producer should run super fast, so I don't want it to spend effort formatting the data into a string; just throw the parameters (which the producer knows but the consumer doesn't) into a data structure and send that to the consumer. The consumer should be bindable to any shape of producer, so it doesn't want to know which parameters it'll get or how it should format them.

This should be straightforward. I can send a "format string" along with the parameters so the consumer does whatever it's told by each producer. But LV's Format Into String primitive requires a fixed number of parameters at compile time! I'm trying to roll my own using regex or the tokenizer, but I realize I'll have to implement the whole format specifier syntax if I want it to work generically.

Can anyone think of an easier solution? Preferably one that doesn't establish an external dependency on my code...I don't want to have to ship a VIPM with its own license terms or install a new .so/daemon on the cRIO.

1. This looks great! Any attempt to reinvent the crusty LV IDE is fully supported here.

2. I was pleased to find this tool instead of another package manager when I clicked the link to this thread. Any reason you called it a "code manager"?

3. Are you actively developing it to address bugs like the one you posted today? Do you intend to invite community collaboration on the plugin framework?

Oh yeah. Good idea.

Has anyone published a tool that'll copy a VI's entire dependency chain on disk with all the correct re-linking and such? I need a way to move chunks of features in and out of projects, and sometimes these features aren't nicely separated into classes/libraries/ppls, or they call into lots of scattered non-VI.lib code.

I see there's a "Get VI Dependencies" method in VI Server, but it doesn't include XML files like classes, libraries, xnodes, etc.

The "Duplicate hierarchy to a new location" option in the "File >> Save As..." menu does exactly what I want, I guess...but that's insensitive to code from VI Packages that don't use <vi.lib>. It'd sure be nice to extend that tool with programmatic access and a feature that scans installed packages to avoid copying their code.

Edit: I realize that "dependency chain" is a much broader term than just the call hierarchy, but I'm really just interested in the call hierarchy here.

One major problem was there was no way to avoid making multiple copies of the image in memory, even though the actual content didn't change. First, converting the string (from the TCP connection) to integers (DMA FIFO format) incurred a copy, and then a second copy occurred to copy the integer array into the DMA FIFO.

Honestly, the solution to that problem is to write a C application using the NI-RIO C API instead of LabVIEW.

Definitely sounds like another language feature hacked in to support the improvement of NI-internal APIs. I wonder if there's any intent to publicly document it better with examples of creating, say, a DLL that uses this feature to share data with a LV app.

I also wonder whether the Scan Engine exposes a similar feature to NI-RIO that lets me post scanned values directly into a file!

http://zone.ni.com/reference/en-XX/help/371361L-01/lvscript/datavalrefnum_isexternal/

I just found that by accident while clicking around in a class typedef that contains a DVR. What does it do?

I'm walking through a LVRT Project using the VI Server API, trying to find a particular build spec on my FPGA target. I can get the target ("FPGA Target") by name and use that ref to find the build spec by its name, but the reference returned can't be cast to type ProjectItem:BuildSpecification. If I probe the reference wire, the only interesting thing I see is the type GUID...

{F4C5E96F-7410-48A5-BB87-3559BC9B167F}

Does anybody know of a way to deduce the VI Server object type from this GUID so I can perform a downcast on it?

There were no "what's new" sessions at the CLA-A summit. I can't recall when there ever were. I recommend just reading the help docs anyway, as most of the info you need is put there with every release.

That looks like the kind of red flag this graph is intended to show. Find the ribbons without pointy tips and fix your dependency chains so they all have pointy tips again!

Edit: Also, a good rule-of-thumb is not to nest libraries (or classes within libraries). It slows the editor down badly and creates dependency hells like the one you have there.

I originally thought the shape of the leaves on the dependency wheels indicated the direction of the dependency, but it now seems to me that it only depends on the size the libraries takes on the wheel.

The pointy end of the ribbon (or "leaf") connects to the dependency.

Mrmas, the link drjdpowell gave above will help you tell the API where your SQLite library is. You'll have to install SQLite using NI's opkg server. if you want to use the very latest version of SQLite instead of the one NI's currently distributing, you can follow these instructions.

Ah, that makes more sense!

in order for the fractional seconds part to be recognized. As our string is a standard and used in all ASP.NET we would be greatful if you could include it in the next release.

That seems like the kind of thing that should be added to a wrapper or extension to the library's classes, not to the library itself. As someone who never uses ASP.NET (or any of hundreds of other frameworks, services, and tools I can choose from for a new project), I don't want to lug that VI around in my code base.

You should go sniffing around for a STIL API. If there's none native to LV, look for one in another language that can be built into a DLL (C++) or called from the command line (Python).

You want to manipulate STIL data using a JSON API? Sounds like turning a screw with a hammer...

Can you get your vector generator (or whatever test equipment you're using) to output STDF instead?

I've posted the VI over on the NI Community (awaiting moderation) in case anyone else needs a GZip compression VI.

Nice, thanks! Mind re-posting them here with a more friendly license?

 

Is this really a box you want to open? You can't inherit from multiple parents and the Character Lineator is designed for this.

I haven't looked at the Character Lineator, but my impression from forum chatter is that it's a monster that runs slowly. Is it worth use in production software these days?

That said, I still don't know whether jdpowell's suggestion is the right way to implement an app-specific ser/des protocol. I feel like that's a different code module than this one, maybe using this one as a dependency with the existing API.

 

Note: I’m thinking of putting in an abstract parent class with “To JSON†and “From JSON†methods, but I’m not going to specify how exactly objects will be serialized.  So Charles can override with his implementation (without modifying JSON.lvlib) without restricting others from creating classes than can be generated from different JSON schema.   I could imagine use cases where one is generating objects from JSON that is created by a non-LabVIEW program that one cannot modify, for example.   Or one just wants a different format; here’s a list of objects from one of my projects:

Caution: a framework keeps all the assumptions but provides none of the code.

If you don't handle a lot of the work for the user (making assumptions about how to do so), I don't see what help your new classes will be. All you'll do is give people the opportunity to make your code package a critical dependency of their project. If anything, I recommend using the Strategy pattern to provide a default Serialization Behavior that people can override with their own.

Right, now that I turn to it, I see it. Harder, but perhaps not insurmountable: if I get it correctly, the showstopper is that there is no way to recast the saved class data back into classes by merit of some autodynamical mechanism; the hard way should be to include enough class-discriminating information in the JSON, and supplement a lot of ad hoc fragile code to place it back where needed. Anyway, tedious enough to wonder if it is really preferrable to my original xml dump.

I think you mean "objects" everywhere you say "classes". To that end, I once created an "INI Serializable" class that did what jdpowell suggests. In addition to providing overridable protected methods for "Serialize" and "Deserialize" actions, it had infrastructure to generate a GUID for the object to be serialized and all the objects that composed it. The objects' GUIDs were the names of sections in the INI file, and their private data were written to keys in that section. A key was added for each object composing the one being written, and the composing object's GUID was assigned to that key. In this way, the Deserialize method could build up an object's simple-datatype members, then look up any sub-objects by their GUID, build those up, and insert them into the owning object.

i.e. the output of "Child of INI Serializable.lvclass:Serialize.vi" would be:

# Flattened object

[5FF01668-0B7A-4EAF-9CF7-B09754EB4A07]
__class = "Child of INI Serializable.lvclass"
__object1 = "64F7B537-BC57-48BE-B425-8C4197D51925"
__object2 = "79C1503B-4745-41FF-B3D9-3B2DCD3B079D"
number = 1.0
string = "Hello World"

[64F7B537-BC57-48BE-B425-8C4197D51925]
__class = "Behavioral Strategy.lvclass"

[79C1503B-4745-41FF-B3D9-3B2DCD3B079D]
__classs = "IO API.lvclass"
visa name = "ASRL2::INSTR"

I wish I'd kept the code, but it's lost to the ages. You could recreate it in a day and probably add stuff for handling variants in the same way, since they amount to key-value dictionaries anyway.

Edit: This still required that every serializable class override the serialize and deserialize actions to manually output a VCluster of their private data and later accept that VCluster, parse it, and build up its own private data again.

Yeah, that'd be great!

The error description from the log file is:

 

Error 402864 occurred at redacted.lvlib:redacted.vi on "INSERT OR IGNORE INTO redacted (  redacted, redacted, redacted)  VALUES (?, ?, ?);" Possible reason(s): database is locked

When throwing an error from the API, could you add the SQLite error code to the error description? My client got error 402864 last night, and it took a lot of digging to figure out what that meant. The code doesn't resolve in the Explain Error dialog, and even if it did, I'm more interested in the code returned by the sqlite3 DLL because I use that code to search their documentation when troubleshooting.

It's almost 2016. Can I serialize LabVIEW objects to a standard interchange format yet?

It looks easy enough to add a Boolean to enable use of NaN, Infinity, -Infinity.   It will have to be default False, though, as the default should be to meet the JSON standard.  I would like to see this myself, as I use JSON mostly LabVIEW-to-LabVIEW.   Maybe this should be an enum instead of a boolean, in case we want an alternate extension in the future?

FWIW, I'd stick to the Boolean. There's no reason to assume any other extensions would need to be mutually exclusive from the LV numeric extensions. An enum would enforce that exclusion.

Not sure we can get default values of clusters in arrays (also, which array element should be used?  First? Same Index?).   As a work around, you can just index over the JSON Array elements in a FOR loop and convert each to a Cluster individually.  Then you can either provide the same cluster as default, or have an array of different default clusters.

Same index, of course. I'm specifying the default value of the aggregated data structure. If I want all elements to have the same default values, then I'll either need an interface that lets me specify the element type of the array (instead of the array), or I'll have to use the "Initialize Array" prim.