drjdpowell

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

BTW, you should probably explore the "Advanced" subpallet of JSONtext, in particular "Difference.vi" and "Flatten JSON Object to JSONpath Array", as they are useful for this kind of stuff.

That would be a perfectly good choice. You could also use an array of paths like '$[n].Enabled' and call Set Item in a loop. Aside: Note that you could also use a JSON Object rather than an array to hold your list of targets. Like this: { "My Inst X":{"Enabled":true,"Hello":-2,"Hi":6}, "My Inst Y":{"Enabled":true,"Hello":-2,"Hi":6}, "My Inst Z":{"Enabled":true,"Hello":-2,"Hi":6}, "My Other Instrument":{"Enabled":true,"Something Else":true} } I mention this as I have noticed that LabVIEW programmers often get stuck in a mental model of JSON Objects and Arrays mapping onto LabVIEW Clusters and Arrays. In particular note that JSON Objects are not fixed type and number or elements at edit time (unlike Clusters), and JSON Arrays are not restricted to all elements having the same type (like LabVIEW Arrays). I also made the last instrument in my example one with a differences in its config structure. By using JSON, you can still let your User change common settings (like "Enable") even with instruments that cannot be represented as the same LabVIEW Cluster. This is an example of "Duck Typing", which can be difficult to do in LabVIEW otherwise.

You should be using $[*] or $[0] to indicate Array elements; $.[*] indicates all items in a JSON Object and $.[0] is the Object item named "0". Look at the detailed Help page for JSON Path notation in JSONtext.

Two suggestions: 1) Consider using JSON as your config-data format, rather than clusters. Using JSONtext to manipulate JSON will be faster than using OpenG tools to manipulate clusters. 2) Programmatically get an array of references to all your config-window controls and register a single Event case for Value Change of any one of them. Then use their (hidden) labels to encode what config item they set. For example, your control with the caption "Baud Rate" could have the hidden label "$.Serial Settings.Baud Rate" which is the JSONpath to set in your config JSON (or config clusters).

Tried it on LabVIEW 2021sp1, and it seems to have at least fixed the problem with a broken VI requiring manual recompile. No working VI with apparently broken wires yet, either. Possibly I should just up the base version of this package to 2021.

Thanks. I see there is also this one that may be the problem I'm having: 1513139 Malleable VIs Are Sometimes Erroneously Broken When Operating on Cluster Data Value References

Put a new 0.5 version on VIPM.io Remember, this is still beta code.

@AQ, I've incorporated most of your improvements, and made some changes myself. Question, though. These VIMs seem plagued by (in LabVIEW 2020) strange recompile bugs: broken wires that are usually fixed by doing a manual force recompile on the VI. Though often this still leaves some broken wires in a runable VI?!? See image. What do you think causes this and is there a way I can avoid it?