drjdpowell

Theoretically, there are no roadblocks to developing it to work on RT. See the SQLite Library package, which has conditional disables to point to the .so on Linux RT, as an example.

I note that even though I created a framework, Messenger Library, I did not re-architect any existing project using my framework, but instead just used it to add new features to those projects. Then I used Messenger Library for all new projects, armed with actual experience. Trying to rework the entire architecture of a large project sounds very expensive and risky.

You could also use a DVR, or similar mechanism, to manage access to a com port, instead of using a non-reentrant subVI.

Try just taking out the generated column. Those were added recently, in SQLite 3.31.0. If the NI Linux package for SQLite is an earlier version than that then it will throw an error at the Create Table statement. What error was given? The error should have given useful debug info.

You need see past your specific motor types to think what your generic motor needs to do. Is it returning configuration info? That can be JSON, rather than a typed cluster. Or a Variant, or an object of a "config" subclass. My advice is to NOT learn OOP with a Motor Parent class unless you have enough experience with different motor types so that you can form a solid view of what a generic motor does.

I'll have a read, but that looks a bit more complex than I have the time for. I will just do a simple Messenger-Library-only service discover implementation.

Another possible service-discovery design is a central broker; an actor with TCP Server at a known IP/Port that all services connect to to register their location, and to which clients connect to lookup services.

A beta version is now posted: https://forums.ni.com/t5/JDP-Science-Tools/UDP-Messengers/td-p/4099792 This is of the UDP comms itself; haven't done a service-discovery implementation yet.

https://bitbucket.org/drjdpowell/jsontext/issues/68/report-issue-converting-a-array-of

Decided to update this to 2020 and release (this is 0.3; I never posted 0.2): jdp_science_lib_malleable_buffer-0.3.0.8.vip

Note: I've also been thinking about UDP Messenger functionality, and am interested in people's use cases: https://forums.ni.com/t5/JDP-Science-Tools/UDP-Messengers/m-p/4099792#M17 The use case I'm interested in is discoverability on the network. So, allowing actors on different machines to announce their existence (ip address and port) via UDP, so that a TCP Messenger connection can then be established. This could be built in to the new Reconnecting TCP Messengers.

I don't think they did that. There is a couple of my lava packages on there, but I explicitly uploaded them to VIPM.io

Do you use any DVRs? I believe quite a lot happens when the LabVIEW execution system changes a VI from "running top level" to "idle", including destroying any references created by that VI. Not sure what happens if a DVR that it owns is currently being accessed by another VI; I assume it must wait for the DVR to be released before finishing teh transition to "idle".

Unfortunately, the NXG Web module lacks both recursion and VIs for determining the data type inside a variant. This makes porting JSONtext to it very difficult.

Working on Idea (1) https://bitbucket.org/drjdpowell/sqlite-labview/issues/12/add-an-execute-sql-statement-multiple

That's sloppy on my part. Arrays should not be supported at all and that should throw an "Unable to Bind Arrays" error. The code for that is in the Disabled case of "Parse Parameters (Code).vi". I was experimenting with the idea of allowing U8 Arrays as binding as BLOBs, and I seem to have not undone my buggy experimental modification.

That example isn't broken for me in LabVIEW 2020. What happens if you delete the broken wire and reconnect?

Hi Guys, Support for writing multiple rows in this manner is on the Roadmap, but not yet existing, partly because I am debating multiple options: A new function, "Execute SQL Multiple Times", that takes a parameter input of arrays of clusters or a cluster of arrays and does multiple executions of one SQL statement. Integrating it into the existing "Execute SQL" node. Upping the LabVIEW version to 2017 and introducing a new VIM version of either (1) or (2). The problems with (2), which you guys are thinking should work are: "Execute SQL" is a polymorphic VI with many members, and major changes to support functionality like this is very time expensive for me. That function is already quite complicated, and increasing what it can do is going to make it more confusing. Usually when one is executing the same SQL many times, one is INSERTing rather than getting any results, so a new function (1) would only be one VI, and it could have documentation (and a different icon) that clearly describes using it on multiple INSERTs. An advantage of the VIM (3) is that I can make the input accept only data in the right form (array of cluster, cluster of arrays). This is not high priority for me, as I see it as about convenience rather than new capability. You can already do things more flexibly and faster-executing using "Prepare Statement" followed by a loop, or you can do it easy (but slow) with "Execute SQL" in a loop.

I am trying to shift discussion of Messenger Library to a group at NI, as this conversation is at 12 pages and is hard to follow. New post about a beta feature for TCP that I am working on: https://forums.ni.com/t5/JDP-Science-Tools/New-Beta-feature-Reconnecting-TCP-Messenger/gpm-p/4092514#M5 Here's the image. The idea is to have a persistent TCP Client connection that will try and reestablish itself if broken.

You're right, this needs an example. How you describe it sounds correct. I've had as many as four update Booleans, I think.

It's documented in the DEV Template. I use a feedback timeout that is default 0 ms from every case but the Timeout case (which feeds back -1). This makes the Timeout case execute exactly once after the event queue is empty. Use a "Display needs update" boolean flag to record if the display needs updating in the timeout case. One can do this with Queues as well. With this one is able to look at all incoming data, but do expensive display operations only as often as possible (but as quickly as possible). So you could, for example, have information coming in a 100 a second, and display using fancy techniques (like complex 2D pictures) that take 100ms+. This is more responsive and a look more robust than the "drop old stuff" technique.

A Notifier is only usable is you only have one type of message coming in, and your display doesn't include any history, like a chart. Personally, I keep the data transfer lossless, but just make the actual front panel display update lossy.

They way you're using DVRs here, pulling the full data out of the in-place structure, forces a lot of copying. You have to do the work inside the event structure if you wish to prevent copying.

I've submitted a new version to the Tools Network.

This fix is on the Tools Network now. JDP Science Common Utilities 1.2.1.12