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

On 15.9.2016 at 9:49 AM, demess said:

I believe it is the third party unmanaged c++ which is causing the problems. Do I need a dll wrapper for this to work?

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

When I am working on programs, I often put my parallel processes in a class called the "<parallel proc name> manager" that has a VI with its loop/process. What I am finding is that these managers will need some subVIs to keep them clean, especially in states where a decent amount of processing is done. I realize then, that these methods are always only being called only by this manager on it's loop/process VI so that said, they are always being called on the block diagram within the class. So, to me, it makes sense to make them private. But, then I end up with managers where all the methods are private, because their only real methods are wrappers to keep the BD's clean. Something seems somewhat off about this and I was just looking for people's thoughts, comments, and suggestions on better ways to handle this.

 

ManagerVIs.png

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.

bsvingen, are you using “singleton” in the same meaning as in OOP; something of which there can only very be one instance of?  Because I don’t see how that is useful in something like a PID controller, which one might easily want multiple of.  Do you perhaps use “singleton” to mean any by-reference thing?

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.

Oh no... same thing with the next critical part of the neurofuzzy controller algorithm! The machine learning algorithm (performance bottleneck) with primitive array operators is again 4x faster (and uglier) than the formula node version.

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.

We have implemented asynchronously communicating, stand-alone state-based components (which meet the descriptions I have seen thus far for actors, even though we don't think of them as actors) using native by-value classes and design patterns (see especially the State Pattern and perhaps my NI Week presentation on it.). (We have since also implemented orthogonal state machines within an application.) Our components can communicate over the network, allowing flexibility in deployment, and maintain state information in the proper places. And yes, we reuse the top-level state machine, for instance, in every component controller. :-)

I think that the Gang of Four Design Patterns book and Head First Design Patterns are wonderful sources on how to implement and use design patterns effectively, but those texts didn't really click for me until I began to understand interfaces, which is why I bring up the topic so often in the papers and presentations I have compiled on design patterns.

How do you implement interfaces?

I will concede that some design patterns likely require object references. On the other hand, we have successfully implemented all the GoF design patterns we have tried thus far with by-value classes, and we didn't need any special tricks to do so.

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.

Absolutely nothing about OOP requires a by reference design.

Even if 99.99% of OOP Implementations DO use references, it does not change the matter that the very nature of OOP does not demand either by value or by reference idioms.

Shane.

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.

Hmmm..., can you explain further what you mean by that? In the glossary of T. Budd, An Introduction to Object-Oriented Programming, 3d. ed., we find: "object-oriented programming: A style of design that is centered around the delegation of responsibilites to independent interacting agents and a style of programming characterized by the use of message passing and classes organized into one or more inheritance hierarchies." I see similar descriptions of OOP elsewhere. Certainly one can do all those things with native by-value objects!

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.

I only get a speed improvement of 4%

• LabVIEW 2012
  
• Win7 32-bit
  
• Intel i5-2410M @2.3 GHz
  

Ton

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.

Just a quick wild guess : amongst the reasons for a VI to have this option gray-out, you'd find "this VI is currently running, or is a dependency of another VI that is running", there are probably other reasons of course.

Can you give more details concerning your use case?

Is a part of your code running when you have this issue?

Is your VI part of a class or lvlib that is protected, etc...

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 ??

Right clicking on an iten (a vi) in the project explorer gives a menu with an iten called "replace with..." This is extremely handy. But sometimes this item is greyed out, and I can't figure out why and what to do to un-gray it. Anyone?