drjdpowell

Here is a Beta version with a new “Treatment of Infinity/NaN†terminal on the JSON write functions. Three options: -- Default JSON: write all as nulls. -- Extended: use JSON strings for Infinities ("Infinity", "-Infinity"); NaN still null. -- LabVIEW extentions (compatable with the LabVIEW JSON primatives): Infinity, -Infinity, NaN (not in quotes) Note that the LabVIEW extentions are not valid JSON. The Extended option IS valid JSON, but not all JSON parsers will process strings as numeric values. lava_lib_json_api-1.4.0.28.vip

I mean alternate treatments of Inf, -Inf, and NaN. I can think of alternatives that are arguably better than the choice made in the LabVIEW primitive. Personally, I would choose NaN==Null, Inf/-Inf==“Infinityâ€/“-Infinity†(strings), as this would be valid JSON. The LAVA JSON package should already be able to read this (I think). Regardless, other JSON packages that we may want to interact with may have made other choices.

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? 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.

No, but I’ll add the same NI off-pallet VIs used elsewhere in the library to convert to/from Mac paths: “Path to Command Line String†and “Command Line String to Pathâ€. Thanks. Do you use LabVIEW on the Mac? I haven’t in a long while and I could do with someone testing it. — James

A beta version of 1.6 is posted here. If you ignore the newest features, you could use this in production code; it has the latest SQLite 3.9.2, including the interesting JSON1 extension.

Attached is a beta version of the latest 1.6 version of SQLite Library, for anyone who like to give feedback. A major addition (not yet well tested) is “Attributesâ€, modeled on Variant Attributes or Waveform Attributes, but stored in any SQLite db file. The idea is to make it easy to store simple named parameters without much effort. See the example “SQLite Attributes.viâ€. A more minor upgrade is making “Execute SQL†polymorphic, so as to return data in a number of forms in addition to a 2D-array of strings. See the upgraded example “SQLite Example 1 — Create Table.vi†which uses the new polymorphic VI, including showing how to return results as a Cluster. For Attributes, I had to make some choices in how to store the various LabVIEW types in SQLite’s limited number of types. The format I decided on is: 1) all simple types that already have a defined mapping (i.e. a “Bind†property node) are stored as defined (so strings and paths are Text, DBLs and Singles are Float, integers (except U64) are Integers. 2) Timestamps are ISO-8601 Text (the most standardized format of the four possibilities) 3) Enums are stored as the item text as Text, rather than the integer value. This seems the most robust against changes in the enum definition. 4) LVOOP objects are stored flattened in a Blob. 5) any other LV type is, contained in a Variant, flattened and stored in a Blob. Using a flattened Variant means we store the type information and LabVIEW version. drjdpowell_lib_sqlite_labview-1.6.0.51.vip LabVIEW 2011-2015 The Attribute stuff grew out of a project where SQLite files held the data, one for each “Runâ€, and the Runs had lots of small bits of information that needed to be stored in addition to the bulk of the data. When and where the measurement was taken, what the equipment setup was, who the Operator was, etc. I purpose-made a name-value look-up table for this, but realized that such a table could be made into reusable “attributesâ€.

Good eye. It’s because I had to read in the INI config file before writing this JSON, and so inherited the INI’s precision. Here is a redo where I have manually typed in 123456789 as extra digits before JSON output: "AI Bridge Torque (Poly) Setup Cluster Array": [ { "Bridge Information": { "Bridge Configuration": 10182, "Nominal Bridge Resistance": 350, "Voltage Excitation Source": 10200, "Voltage Excitation Value": 10 }, "Channel Name": "Bridge_Torq(Poly) - PCB Model 039201-53102 Serial 127511", "Channel Selected": true, "Custom Scale Name": "\u0000\u0000\u0000\u0000", "Fwd or Rev Coefs": "Use Fwd Coefs to Gen Rev Coefs", "Maximum Value": 1000, "Minimum Value": -1000, "Physical Channels": "\u0000\u0000\u0000\u000BMFDAQ-X/ai2", "Scaling Information": { "Electrical Units": 15897, "Forward Coeff": [ -1.78569123456789E-5, 0.00200225212345679, 1.20519812345679E-9 ], "Physical Units": 15884, "Reverse Coeff": [ 0.00891831812345679, 499.437812345679, -0.150142012345679 ] }, "Units": 15884 } ],

For comparison, here is the JSON-format of your config file: ConfigJSON.txt An excerpt: "AI Bridge Torque (Poly) Setup Cluster Array": [ { "Bridge Information": { "Bridge Configuration": 10182, "Nominal Bridge Resistance": 350, "Voltage Excitation Source": 10200, "Voltage Excitation Value": 10 }, "Channel Name": "Bridge_Torq(Poly) - PCB Model 039201-53102 Serial 127511", "Channel Selected": true, "Custom Scale Name": "\u0000\u0000\u0000\u0000", "Fwd or Rev Coefs": "Use Fwd Coefs to Gen Rev Coefs", "Maximum Value": 1000, "Minimum Value": -1000, "Physical Channels": "\u0000\u0000\u0000\u000BMFDAQ-X/ai2", "Scaling Information": { "Electrical Units": 15897, "Forward Coeff": [-1.78569E-5,0.002002252,1.205198E-9], "Physical Units": 15884, "Reverse Coeff": [0.008918318,499.437845,-0.150141962] }, "Units": 15884 } ],

Wow, that's really pushing the INI file format; what do the files look like? Personally, I switch to JSON format once I need to store arrays, let alone arrays within a cluster within a cluster within an array within a cluster. Note> the JSON package above saves DBLs with 15-digits.

For anyone listening, here is how to send messages (or any other data type) via a TCP connection. Basically, one just puts a message length at front and reads that first. TCP handles making sure you never miss a byte, so there is no need to identify data boundaries.

Remember this conversation? Those examples I gave use a TCP client-server. They should work with multiple copies of the client.

You can cross (1) off at least, as there is no need to poll a TCP connection. Just have one loop sit waiting for incoming messages, with a second loop to do sending in parallel. TCP is bi-directional and the two directions don’t interfere with each other, just like a pair of Network Streams. But being bi-directional, you don’t need to establish a second connection from server back to client, and thus don’t need to know the client name. If the client can reach the server you are done. And the TCP Listener is exactly what you asked for as far as a server handling incoming connections. To me, TCP seems much simpler than what you described. Re (2), I don’t have experience in unreliable networks. But I have always been confused by Network Streams, as TCP is already a robust network protocol that resends lost packets; what is Network Streams able to do that TCP can’t? — James

Not to distract from the question but I’m interested in why you aren’t using TCP directly. I haven’t had a multi-machine project in ages, but TCP Listeners and bi-directional TCP Connections seem intended for exactly this kind of problem.

Are you trying to measure volume? With a bright light wall behind, the meniscus should be visible. In this image the level (of a petroleum product) is very clear because of a layer of bubbles (white bubbles, but they appear black against the light wall), but even without bubbles one can pick out the level.

I am reminded of this Eyes on VIs video, and how it matters whether or not one closes the VI reference when using Run VI. Don’t know if this helps.

That’s surprising to me, but then I haven’t used the Run VI method in years. I only use ACBR, which always required a strict reference.

For async VIs** I use ACBR with option 0x80, which, like Run VI with Auto Dispose Ref = TRUE, means the VI never aborts like this. **We don’t seem to be talking about synchronous subVI calls here, but for those I just use a static reference (which cannot be closed).

Does it? Closing isn’t the same as unloading. Is your VI reserved-for-execution? If it is, I don’t think closing the FP unloads it or resets anything.

If you executed it, then it must be reserved for running, so the “nasty transition†Neil mentions doesn’t apply. Yes. I put Close Front Panel before Insert VI (I ignore any error from the Close, thrown when it was already closed). You can close the reference. The subpanel doesn’t (I don’t think) ever close the reference itself.

I solve this issue a different way, by making my messages all "control-likeâ€: a label and a value. So I would have messages: “Set Loggingâ€, a boolean that is True or False “Set Play Stateâ€, a string (or possibly enum) with values "Play" "Pause" "Resume" or "Stop"

Attached is the demo project developed over the Actor to Actor communication and Controller-Model-View videos. LabVIEW 2015. Messenger Library Demo.zip

I tried having call-backs that called methods on a LVOOP object inside a DVR. It worked, except that occasionally two events happening at about the same time caused the UI to freeze, possibly due to some kind of lock-up involving the DVR and the UI thread in which the callbacks run. This was near impossible to debug, and I abandoned callbacks in favor of an asynchronous VI that handled events with an Event Structure (calling the same LVOOP object held in a shift register).

Your code was not attached, but I often use variants, dynamic registration of arrays of control references, and control labels that encode the message that needs to be sent, as illustrated in this old post. I also done similar things connecting multiple controls with Camera Attributes or DAQmx channels.

In the end I sidestepped the bug by turning off "Advanced>>Auto Adjust Scales†on all my graphs.

I was more responding to: "It is my understanding I have one of two choices at this point: A.. and B.." I gave an option C.