drjdpowell

I haven't used them yet, but I thought LabVIEW Interfaces are like LabVIEW Classes, just with no private data.

Yes, the new Interfaces will takeover much of the work previously done with abstract parent classes.

SQLite3.so has no dependencies, so I am suspecting access rights.

Is that not four levels?

Messenger Library is 4 levels, so I answered 3-6, though my more common use of Classes will be 1-3. Though I note that number of levels doesn't necessarily map directly on any meaningful measures of complexity, as it is easy to add additional parent levels that represent only simple capabilities. My top-level Address class in Messenger Library is just "a thing one can send a message to", and primarily defines only a "Send" method. It doesn't even define creation/destruction methods (those are in level two).

Does a Property Node, with multiple Properties set, execute as a single action, without a parallel Property Node executing in the middle? If so, then resetting the Active Plot in the second Property Node in the bottom loop would prevent any race condition.

I have an SQLite logger, yes, and the more expert Users do use it. But even there hard to read error messages are a burden. Especially the poor first line, as teh first line is what appears in the list of log entries, as in the "Error 63" shown here, which was a failure to find a TCP Service (because the service was not running).

I set the VI to Modal inside a Conditional Disable so it applies in a EXE only, which lets me debug in source code while the dialog is open.

I was hoping to get an "easy win" of improving error communication, without the cost of custom code to intercept and translate individual errors into more User-friendly ones. Of course, custom messages is what one should do for the "expected" errors (such as the User not plugging something in, say, or selecting a file of the wrong type), but you can't anticipate more than a small subset of possible errors. I should say my particular use case involves a large set of third-party code that can throw errors (often without error codes!), plus a variety of different categories of "Users", including not just "Operators", but subject-matter experts in the hardware and some of the third-party packages, who need to be able to use error information to debug problems in their areas. I need to be able to present arbitrary errors in a way that is most helpful to them.

If you just need to display a chart in a window, it's easy to do with a simple subVI. The subVI contains nothing but a chart control attached to a subVI terminal. Call the subVI periodically with new data. Open its Front Panel with a VI Server call.

This is a question to ask how people display errors to non-programmer Users. An example of a current Error Mesage that might be displayed to a User of one of my programs is this: The problem I find is that to a many, if not most, Users, this comes across as "Error N ocurred at blah, blah, blah, I'd better report this to the programmer". Their eyes have glazed over at the VI name, long before getting to the useful info that might actually help them fix the problem themselves (like realizing that they haven't pointed to the right folder where the file exists). I tend to get reports like "Error X happened", or even "It didn't work" . This is particularly bad with Error 1172, a .NET exception, which is full of .NET mumbojumbo like "invocation" and "inner exception". I would rather have error dialogs like this: Here, the info useful to the User is directly on the first line, followed by clear description not cluttered by techy-sounding fluff. Details only important to me, the Programmer, are at the back, where I don't care if the User has stopped reading. However, I am not sure how to programatically reorder Error dialogs in this way. The important key phrases such as "File Not Found" are buried in unstructered text. What have other people done?

Are Listener ports affected by this "half-dead" issue? I would have thought this is just and issue of TCP Connections (with a connected remote party) rather than a Listener.

More details: I'm not using the "Internecine Avoider" and I'm using a "net address" of 127.0.0.1, which I beleive means I'm not going through any network card (all three apps are on the same computer).

Sadly, I don't know as such an error would get lost in the code as written. This is a rare error in code deployed code on a low-powered single-board computer. Appears to be a loss of TCP connection, followed by the Client not being able to reconnect (which is why I suspect the Listener dying). An added clue is that an additional third-party non-LabVIEW TCP server seems to fail and restart itself at the same time (according to entries in its log file.

What work does Type Cast need to do with arrays that it doesn't do with strings, which are just arrays of bytes? Seems to me that the fastest cast would be something like array of U64 to Doubles, as those are the same size and don't require any length checks (unlike, say, a 9-byte string to array of 8-byte Double). Is the problem not a missing optimization for U8, but instead nonperformance code for numeric arrays?

Has anyone ever encountered a case where a TCP Listener is created and used, but at some point becomes invalid, throwing an error at the "TCP Wait on Listener" node? I'm trying to understand a rare issue on a deplyed system that might be explained by that.

In the actual VIM "Read Element by Index of Count" it is an I32, but I think when you connected a U32, and LabVIEW did type propagation through the code of the VIM. Note sure why this caused your specific issue, but this needs fixing regardless, perhaps just by a convert-to-I32 node. Thanks.

Again, I've never used PPLs, but that seems wrong. Why can't you put a class in a library/PPL?

I have never used PPLs, but my understanding is that you would first need to put the PQ library in its own PPL, and have all other code call that PPL. It looks like you have instead made independent copies of PQ in each PPL.

Here is a quick hack from some existing INI parsing code I had. See if this works on NI-MAX files. This VI converts the INI items to JSONpath notation, converts the values to JSON strings unless already a valid JSON value (such and numbers, true, etc.), and uses the JSONtext VIs "Unflatten JSONpath Array to Object" and "Pretty Print" to convert to JSON. INI to JSON Example.vi

Good luck AQ, Hope your new employer still lets you attend a conference or two in Europe.

Ah, it's because I added submenus in last release, and this added '_1' onto teh menu name. I'll fix that.

Fixed, thanks.

That is the Project I use to develop the library; it isn't meant to be used after install (and doesn't update the various paths, such as to teh examples). I should probably not include it in the VIPM. If you'd like to fork the package and develop it, I'd recommend forking the Git repo. That menu should have been installed by VIPM, though.

JSONpath doesn't have a specification, unfortunately, and so you can't really rely on different implementations matching on edge cases. I also haven't implemented everything (just due to teh effort required that I don't have time for).