drjdpowell

My own UIs, when I polish them, tend towards mostly white. I could give NI some suggestions on how to improve that UI, but I wouldn't change the basic whiteness. Although my UIs are graph heavy, which I find look better as all white. In a UI whiteout graphs the reasoning is less strong.

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