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.

Another major bug I found in the formula node. A program I have would nut run in LV 2011+. It would only run in pre 2011. I couldn't find out what was wrong, the results only gave NaN when in 2011+, but was OK in 2010. I eventually made a special "NaN finder" to track it down. The error was inside a formula node, and it was a major bug in LV. The formula node up and including 2010 did not work according to IEEE. The function is z = (a/x)*exp(1/x) where a is a number from 0 to 1 (often, but not always 0) and x is a number from 0 - 1.5. When a = 0 the physical meaning should be z = 0. I thought this was mathematically correct because 0 * [any number ] = 0. In 2010 and earlier the result was 0 when a = 0 for any x (except x = 0), and everything was OK. The point is that this is not correct. If x is less than approximately 0.00145, then exp(1/x) = Inf due to double precision. Then z = 0 * Inf = NaN (According to IEEE) while formula node in 2010 gives z = 0. In 2011+ this is fixed and the formula node gives correct result, z = NaN. But I have seen no mention of this bug, and no mention that it is fixed. Another problem with this is that if the formula node only calculates z = a * x, and a is 0 and x is Inf, the result is NaN also in 2010. So what exactly is going on inside the formula nodes is a great mystery.

There are several things you can do to that formula node. The last time I checked (some years back), the formula node does no optimizing at all. You have to do that manually. For instance, the pow function is slow in any language. x*x = pow(x,2) mathematically, but x*x is much faster, x*x*x is faster than pow etc, etc. I use an ancient Maple (Maple R4) for that. A hopefully faster, but mathematically equivalent, formula node would (or could) be something like: t1 = alpha*dedys; t4 = t1*(y-y*s); t6 = w/b; t7 = x-c; t8 = s*s; t14 = t7*t7; A[0] = c-t4*t6*t7/t8; A[1] = s-t4*t6*t14/t8/s; A[2] = p-t1*t6*x; A[3] = q-t1*t6; [/CODE] Where the array is your result from the formula. I had to use array only for Maple to work.

How do you implement interfaces?

I have only used singleton for any real purposes so far (an object in a dvr using non-reentrant vi to obtain the ref). I have looked at some of AQ's patterns ages ago, but found them unintuitive and slow executing. While using DVRs things get light weight, fast and intuitive. Maybe I should take another look. Fundamentally what I use most are state machines, and I want them to run in parallel and be as reusable as possible while keeping the overhead down. They must also be able to communicate. That is why I find the actor thing very interesting.

I disagree. Most of the patterns used in OOP design are build around the very principle of references. References to objects. How do you make a singleton without using some kind of reference? You can do it with LV2 style globals, sort of. But when using a DVR, the whole process becomes much more natural and stright forward, and you stick to the principles of dataflow. You could say that when using dataflow you can do well without a singleton, but then you also end up way outside true and trusted OOP design patterns that have proven their usefullness over and over. Sometimes the data is the reference, sometimes it is the value, it's still dataflow IMO.

I'm also "just" an engineer "cheating" in the programming department, but I have been programming for 25+ years. I use LVOOP for almost anything when using labview, but if you look at typical patterns used in OOP, most of them can only be implemented in a natural and stright forward fashion if you use references, typically an LVOOP in a DVR. Othervise LVOOP is an extension (a really powerful one) to dataflow paradigm, but not really OOP in a broad sense like OOP in C++. LVOOP is to dataflow like the ++ is to C, but LVOOP != ++ in a same manner as C != dataflow. But the moment you start using LVOOP in a DVR, you can use all the patterns in the book. I have to admit that so far I have seen no real reason to do that. I use DVRs, but not like that. Dataflow + LVOOP has been the tools that works great for me. The actor thing looks really interesting though. I use a similar technique (I think?), but I use DVR to pass values between an arbitrary number of state machines, while the synchronizations are taken care of by dataflow alone.

Then you are doing something wrong that does not filter out overhead etc. I also get consistently 20-30 % improvements with diagram vs formula node. Try doing 2D array math in a formula node. Last I checked it was 50-100% slow down (but that was a looong time ago). Writing a DLL in C gives the fastest running code, but that kind of defeats the purpose of making the code accessible, readable and maintainable. Wire diagram HAS improved in the latest iterations of LV, and IMO that is overall the best solution (given reasonably complex math). I have written a matrix solver using exclusively wires. It's pritty fast for matrix smaller than approximately 200 x 200. For larger matrixes the native solver (using DLL) is faster, but I guess one of the main reason it is faster is it probably uses a more complex algorithm that scales better, parallel maybe, I don't know.

IMO Labview is natively dataflow. LVOOP is not "really" OOP unless you also use DVR, but it's still dataflow IMO. But have you seen this? https://decibel.ni.com/content/groups/actor-framework-2011 By the looks of it you have, and that should answer your question I think.

Formula nodes are slow, and in particular when using array manipulations. Things gets even worse for RT. This is a pity, because when doing math you want to just take one look and reckognize the code. I typically refactor as much as possible, and include a text with the equivalent text code.

Not running. Definitely part of a class (several), could be that they are protected, but I don't understand why that should warrant the grey-out when they are part of the same project ??