hooovahh

I know this post is ancient by internet standards, but I've been using LVMark off and on for years now. I recently posted a Hooovahh String package here on VIPM.IO. I plan on making a video demonstrating features of that package including LVMark some day. The LVMark code is mostly unchanged from the version posted here, just some comments and VIA_Ignore tags mostly. I do think there are places where performance could be better, but I've only ever used it on relatively small strings. There seems to be other LabVIEW Markdown libraries, like the one Ton linked to (but links seem to be dead), and a QControl here that has similar functionality. I do like the simplicity of LVMark.

Yes you make a good point. Maybe I just see it as friction when going to a built application. Like ideally you just tell LabVIEW this is my top level VI and if it runs in the IDE it should run in an EXE. Anything that gets in the way of that simplicity feels like an annoyance to me. But you are right once it is done once that's it. I think the explicit find for each class is more obvious. Like you said a developer may drop down a Find VI and it will either be broken (with the required terminal un wired) or they will need to find what they need. I think I do find the Class Constant method easier in times when you don't know what hardware you want, and you want to just use any. But admittedly that is quite rare and most applications are for a tester with a known set of hardware. I can do both of course, but maybe have the Find for that class be the VI that is on the palette. I don't understand what you are saying here. Are you saying that if the hardware uses a DLL for example, you won't know until you try to deploy to a target where that isn't supported? I mean the VI will be broken in the context of a Linux target, so that will at least clue in the developer before having to deploy it and see it doesn't work.

I've used a variation of this design in the past and as you said if you load it dynamically from disk, LabVIEW needs to be told to always include it in builds. If I provide VIPM package to someone, I don't think it is an obvious step that they should need to find my class and add it to an always include for builds. I don't need to do that for other APIs, like DAQmx for example. If you can rely on the documentation to have the always include, and you control on disk where things are, your dynamic load solution with naming of the class will work. If I want to avoid always include, and if I want the code to have to be brought as a dependency, I think there are only one of two options for forcing the library to be in memory, so the dependencies are brought along. Either have a class constant somewhere, or a class specific VI. It must be one of those two options right? That was my original question of which design do people prefer and use to force some code to be dependent on that class?

Looks like Jim went with the design where class constants are passed in as an array of classes to operate on like my first example.

But the "Find" is child specific, you can't use the same find VI for each class type. Some will use RS-232 COM ports. But others could be 485, or Modbus, some TCP IP Addresses, UDP Address, HTTP Addresses, etc. And they will all talk with different protocols. So there needs to be new Find, for each package and class type installed. And using one classes find function should not force a dependency on all the other classes. This is because of the platform specific needs mentioned earlier. If I went the way I think you are describing, you would call a Find function, and it would "return an array of class objects" Okay but to do that don't I need to have all those children classes in memory? Wouldn't that mean using that Find causes a forced dependency on all classes? Then that breaks things like RT deployment when a target doesn't support that type. This is a great elegant solution that I like. But imagine the situation where I would like to pick the RSA polymorphic, and have no other classes in memory. Well no classes at the same level as RSA, obviously the parents of RSA need to be in memory. That's why this solution doesn't work, and that's why a Find which returns an array of classes doesn't work.

I don't think plugin architecture describes what I'm looking for correctly. Ideally the developer installs packages for the hardware they have. The package can have some idea of the system they have, so like 32bit DLLs can only be installed in 32 bit LabVIEW. I do think that I'm envisioning a static class constant (or VI call) to ensure dependencies are brought along for the build. Which does bring me back to the first question. Do people prefer or use one design over the other? And by that I mean the static dispatch parent with finding classes passed in, or explicit find for each child type? For that there would either be a separate CSZ TCP, and CSZ USB children, or there would be a CSZ Parent, CSZ TCP, and CSZ USB depending on implementation details and overlap between the two types. But I do get your point. As a developer I know I have a CSZ so I install that package, then start developing. Only once I go to deploy to an RT target will the USB one tell me it isn't compatible by saying it can't bring along some DLL requirement. I guess this is something that the LVAddons might help with. I haven't dived into it yet but as I understand it, files can be made available or not in the IDE based on the target. So then you might install the CSZ USB package, but it won't be on the palette if your target is Linux RT. I actually did run into this issue recently where I was using the JKI REST API. I tested it on Windows and assumed it would work fine on RT since it the normal HTTP functions are on Linux RT. But unfortunately later versions of JKI's package uses the Advanced HTTP functions which are not available.

How do you deal with built applications? Your solution sounds fine on Windows, and in a development environment. But if I make an RT or Windows application, it won't know to bring along the child classes into the build if they are called dynamically. Unless I add them as an always include I guess. I think there isn't any way around having to have either a class constant of the children somewhere (like into the Find Parent VI) or to have each child class have it's own Find which is part of it's own class and brought into the builds. I suggested the XNode option just because it could read those files on your Windows disk, then plop down the constants into the generated code. That has complications like only bringing along the classes on your disk, at that time, unless on load the XNode reloads and regenerates code which is a different kind of mess I wouldn't want to deal with. But then again it could be a cool right click feature for reload, or check boxes on what libraries are installed, and which ones to load. And while that is all cool sounding, the very large majority of the time a developer just wants to plop down a single VI, that finds the hardware for that specific hardware type. And then not have to do anything extra to make builds work.

The problem I have with that is you need a polymorphic VI that has all of the instances inside it. That creates a dependency that all children are available and installed. In my situation you may only install the Chamber package, and CSZ package. Then the developer only has the parent, and that one child (well 2 there is the simulate). So now where would that polymorphic VI live? In the parent package? Then that creates a circular dependency. I did explore creating an XNode that would look at your current system and drop a VI that had whatever children were available for that target, but that got a bit messy. The reason for having separate packages, is because some child classes, only work on some targets. I may have one chamber that uses a Windows DLL to talk to it over USB. This DLL wouldn't run on Linux RT, and I need to not bring along that child class as dependencies, because that will break the deploy or build, even when that child isn't being directly called.

Lets say I have a basic hardware abstraction layer for environmental chambers. Here I have the parent Chamber class, a Simulate Class which overrides the required members, a CSZ, and an Envirotronics which are two makers of chamber hardware. For this example lets say I want to distribute this as 3 different VIPM packages. I have my Hooovahh Chamber.vip, which contains the Parent, and Simulate classes, and I have two others the Hooovahh Chamber >> CSZ.vip, and Hooovahh Chamber >> Envirotronics.vip. On the palette I have the main functions all look similar to this. My main question is about how people handle the Finding and Opening functions? I want these drivers on the palette to be easy to use for my developers. At the moment when you install the main Chamber package it installs the Parent VIs you see, and the Simulate class constant on the Class Constants subpalette. Each child specific package then installs a new class constant in the subpalette. Then when a developer wants to use the Find Chambers, they must wire to it an array of classes to use. Here is an example: Here we have a Find VI that is static dispatch on the parent, with overrides insides for each of the Chamber types. It returns an array of found Chambers which is a cluster. In the cluster is the class for the chamber found, which is used in the Overrides for Open and Close. This works and is fine. But I like the idea of hiding away the class constants, and having more self contained Find VIs for each hardware type. In most cases we know the hardware we want to talk to and it isn't an array of classes on an array of COM ports, but instead the one hardware class we intend to use on the system. What I think I would prefer is some thing more like this: Here the developer gets a dedicated Find VI for each class which is a static dispatch for each child class. They all return the same array of cluster (which would be a data type from the parent) and then that array of found chambers is used in the Parent Open which has overrides for each class inside. In this design I would have the Find for each class installed on the palette under some kind of Find Hardware subpalette. In this case I imagine there would need to be some kind method of keeping each Find from only using one COM port at a time. Either through VIG or Semaphore of some kind. Admittedly this is simplified in the previous example since the Parent would be doing the finding, and would know to only pass a unique COM port to one child at a time. In all of these cases I imagine we have full control over the Parent, and all Children. If anyone develops a new child class, we would roll it into the reuse library as another package which would go through the verification process. Do developers prefer one design over the other? What pros and cons haven't I thought about? Thanks.

This year I went to NI Connect (the new NI Week) for the first time in 7 years. I thought I would be the exception and see all those that have gone year after year. But it turns out that many of us this was our first year back, or some last year was their first year back since COVID. In general I think this is a good sign, that things are moving in the right direction. NI has some new leadership that has a LabVIEW focus, and at least at the moment appear to want to push adoption. Reversing the subscription only is a welcome change, but for many it hurt the inertia of business. Once a ship starts moving in the wrong direction it takes a while to come back. Or put another way, respect is lost in buckets and gained in drops. Plenty of businesses have likely moved away from LabVIEW and NI because of poor decisions, that in my opinion, were so NI would look more valuable for an Emerson sale. I'm in the Detroit area, and plan to retire doing LabVIEW. At the moment I think I can do that. Not long ago I didn't think that would be the case. We were just blindly paying the SSP each year. The subscription only model, made management here reevaluated things. We took a few years off. Then perpetual licenses came back again so we renewed. I think we will likely get a new perpetual license every 4 years or so. This will hurt NI since this means less users on the newest release finding issues. Building back trust will take time here, and this will likely play out in a similar way around the world for other companies.

There are several SQLite libraries on VIPM.io. I personally use the one by JDP Science, but a few others also look promising. Changing over will obviously take some time finding and replacing one API for another, especially if there are differences in design choices in how they each implement similar functionality.

Can you describe the issue and steps you took?

VPN to the rescue. Yeah I see it. If you do a resource replace function outside of the scripting functions, you can probably get around the runtime environment requirement. But again I don't know what problem that solves, you still need to use LabVIEW in the development environment to use the controls. To me this is an extension of the IDE. Having something like QuickDrop be a separate application for instance doesn't solve anything, but adds unnecessary complications.

Several of the functions that this uses to generate the control are LabVIEW properties and methods that are only available in the full development environment. Control creation isn't the type of function NI had planned for LabVIEW to do at run time when it was created. What problem are you trying to solve with having this be a built application?

"I don't want your damn lemons!"