bsvingen

I have had the Application builder since forever. Up until now it has been sold with an ever lasting license. But installed 2022, and no Application builder. Then this can be found: "You can also purchase Application Builder separately as an add-on to use with LabVIEW Full or Base until the 2021 SP1 version. Please note that moving forward from LabVIEW 2022 Q3 you can only purchase LabVIEW Application Builder via LabVIEW Professional Development System." The only way now to build applications is to install the professional version. For a relatively low intensity user as myself, this is out of the question. I have no use for the professional edition, not even full, but the application builder is useful. Are there any other way to get around this, other third party builders, or anything? Thanks

Thanks. Yes, client implementation only is what I'm looking for (post edited). We are using RabbitMQ broker/server in a dedicated embedded PC. A pure Labview implementation is highly preferred (although not completely necessary in the long run). Got a pointer elsewhere for LVMQTT on github. Will look into that first. If that doesn't do the trick, then a wrapper is probably needed (if something else doesn't pop up).

Hello I am looking for a functional MQTT server client implementation for Labview. I have been doing some search, and found something, but they all seem to be unsupported. Does anyone have any pointers to a fully functional one? Is NI developing any stuff on this? Thanks Edited for correct content

Years ago (7 to be exact) I found a way to call and use C++ classes in LV. And, yes, you need a dll wrapper, or at least I think that is what it's called, if you are to use some of the C++ class methods in LV. These days I am using it again, and had to look at the old code to understand it, as I am no C programmer. Probably a no brainer to a C programmer, but what you have to do is the exact same thing you have to do to call and use C++ classes in C. You have to make the classes opaque by typedef'ing them as structs (a class IS a struct), and "extern" the prototypes. Then wrap all the methods. One cool thing by this, is that the method can be used for many C++ libraries (of simple complexity at least), and the C++ class becomes just like a by-ref'ed native LV class, only with LV DLL calling in all the methods. Maybe not a solution to your problem, but I have a working example.

Name: LU Solver Submitter: bsvingen Submitted: 08 Apr 2013 Category: *Uncertified* LabVIEW Version: 2012 License Type: BSD (Most common) A native Labview (wire) general real matrix solver. Based on BLAS (FORTRAN code included) Click here to download this file

In case anyone wants to know. Tested today and the COM port and the USB ports work with the newest drivers (PharLap RTOS).

Have anyone managed to get the com port on the NI3100RT module working (for RT OS, not Windows) ?

I want to add free labels (license description) to hundreds of vis in a project. Has anyone made such a tool? (couldn't find anything in the CR)

Then, is it correct to say that dataflow is inherently actor oriented?

Same problem. I can upload images to the repository, but not files. I tried both the "new" version and the "old".

This is very similar to what I have seen as well (not 100% but close enough), I think? The "do state" vis then becomes polymorphic vis and each subclass will "overload" the parent vi in a template-ish fashion. The good thing is that the performance will be good. No dynamic dispatch, but instead optimized and/or inline vis. The "SomethingManager" must of course be known at compile time for this to work, so it can't be used everywhere.

No, singleton as in singleton. I haven't said it would be particularly useful for PID. For MPC on the other hand it is very useful, but it is useful because it is by ref, not only because it is a singleton, even though you normally want only one single MPC controller in any system. The typical architecture in larger systems is several PID or lesser controllers, often per component basis, and one single MPC controlling all the other controllers and/or through direct control of actuators. Anyway, the actor pattern do look interesting.

Had some visitors popping by. What I meant was that I see benefits using those patterns from a maintainability point of view, but it is not clear to me that the end result is better overall. Partly because my experience with dynamic dispatch in LV is a killer of performance, and partly because the examples are too simple and too far from real world applications. A singleton (not the one used in the pattern site at NI, but another one) is simple and the performance is always top, and it is easy to integrate in the ordinary dataflow. But I must admit, there are lots about this I don't understand, the patterns and stuff. For instance the factory pattern, if you don't use it in relation with pointers to objects (by ref), what is the benefit?

Thanks I use lots of polymorphic vis for performance reasons. I still use LVOOP though, but polymorphic vis are of course compiled at compile time. I thought of it as interfaces, but maybe it's more "template style" ? I see that by using interfaces (as in your example + some restructuring), the code could be more easily maintainable, but the cost in performance is really too high. I tried once simply replacing some polymorphic vis with dynamic dispatch, and the slow down was unbelievable, about 1/3 performance. I looked at your example and some of the other patterns. It's all very nice, but I get the impression that all the work has gone into "making a pattern in LVOOP" and not so much into showing real world benefits (and shortcomings). For instance creating a bing bang type controller using state machines is done in a couple of hours, even when starting from scratch using "ordinary" G. It becomes more complex with some PIDs there, but still simple enough. But what about when you include more advanced and computationally much more costly controllers like multivariable MPC? A singleton would help me, because it is efficient and simple.