drjdpowell

I'm afraid I don't even have easy access to a Real-Time unit to try 2019 on. My clients are all 2017 or 2018.

You would need to compile a loadable extension to add that functionality. As an example, I compiled extension-functions.c in order to allow advanced math functions like standard deviation, so you could have a look at that. I note that there is a regexp.c extension on the SQLite website, so you could try and compile that using the loadable extension instructions.

I never use the wizard. I used the online documentation and wrote VIs by hand.

The "pretty print" includes a length check, and keeps small objects compact. You can see it in the code; it's 40 characters or less, I think. This was added to improve the readability of arrays of small objects. Unfortunately, "pretty" is subjective, and it is hard to come up with simple rules that work for all possible input JSON.

I haven't (yet) implemented an "any depth" wildcard character, but if you know how many levels down the item is, you can use wildcards for each level: $.*.*.*.*.NID_PACKET

Did you try a non-Messenger Library TCP example to see if it has the same issue? Another test would be to launch a basic actor (not the TCP communication ones) and see if that causes the same disconnect (if so it could by the ACBR stuff). Unfortunately I'm not on 2019 yet, so can't look into it.

That node starts the TCP Listener; can you try some simple example code that creates a TCP listener and see if it has the same issue? Note: if you change the "TCP Listener" Actor to non-reentrant and to open front panel, I think you can debug it on RT.

Sorry I could not help more.

Ah, so you need to get DLLs compiled for ARM. I think I just got those DLLs from the postgres install. If you have postgres on the ARM, look for those DLLs and replace the current versions with them.

Try your exe on a regular Windows 10 computer that does NOT have Postgres installed. This is to tell if it is a missing dll in the build, or something about Windows IoT that is the problem.

If those DLLs are there then my only idea is that perhaps there is an additional dll that is needed, one installed on your Dev machine but missing on the deployed machine. What is the exact error message?

If this is an EXE, see if libpq.dll and other dlls are included with the EXE, in its "data" folder. This should happen automatically (because the dlls are part of the PQ class), but I've seen this fail before. If they aren't there try using "Always Include" to include them. The data folder should look like this:

I'll have a look when I get a chance. You might just need to install 32bit postgres, just to get the pq dll from it.

Thanks. Issue 34 created.

Sure. I suspect smithd already has a backsaved version, so you might ask him.

Substitute more intuitive terms then. My point is that the OP is criticising "aggressively promoted frameworks", DQMH I guess, as if the point of such things is raw indicator update speed.

A note on "Messaging": A Messaging system is one where different bits of information "messages" come through and are handled one-by-one at the same point. Because different messages are mixed together, the communication cannot be lossy. Even if you have no messages that represent must-not-be-missed commands, you will still have the problem of missing the latest update of an indicator, because of an update to a different indicator. This is different from the case of using multiple separate (possibly lossy) communication methods to update independant indicators (often, this kind of system uses the terminology of "tags"). Because they are separate, the latest value of each "tag" is never lost. But this is not "messaging". Considerations of whether to use "messaging" or "tags" is another conversation.

One possible option with a bad hardware driver is to make your actor an independent exe, using the NetworkMessenger for communication Then you can kill the entire exe and restart cleanly. I've never done that, though.

Unfortunately one sometimes has to call code like hardware DLLs that are not well written. I have to use a dll that will throw up a dialog box underneath the main LabVIEW window (never to be clicked on by the User) if it has a problem.

Hi Max, Recovering from a stuck hardware actor is often impossible, as it is some dll call that is stuck and LabVIEW cannot abort the call. Nor can the dll be reloaded without restarting the entire application. However one still needs to recognise and report the problem. I use the "Timeout Watchdog" recently added to the library. The main actor uses that on the handling of some message that periodically comes from the hardware actor. Now, another unreliable actor is one that handles potentially large blocks of memory. An out-of-memory error will abort the actor, invalidating it's address, and you can use an "Address Watchdog" to notify Main. In that case you probably can restart the actor and recover.

It's because of the lack of quotes about 'MFG'. The first function you are using requires valid JSON values, but you are feeding it unquoted standard text.

I ask about performance because I wouldn't have thought your new method would in general be faster. When I was considering how to improve the performance of this library I became convinced that I should produce a new package that delt directly with strings, abandoning the objects and variant attributes used here. That package is JSONtext, which I use in all new work. So I am unlikely to make more than minor improvements to this library. However, someone else could continue development of LAVA JSON if they like.

What kind of performance improvement does this make?

working on it

As of the latest Tools Network version, the palettes should also appear in the "Flatten/Unflatten String>>JSONtext" palette, in place of the install link in LabVIEW 2019. It's programmatically added, so let me know if that doesn't work for you.