Jump to content

bsvingen

Members
  • Content Count

    279
  • Joined

  • Last visited

Community Reputation

0

About bsvingen

  • Rank
    Extremely Active

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2018
  • Since
    1991
  1. 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).
  2. 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
  3. 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.
  4. 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
  5. In case anyone wants to know. Tested today and the COM port and the USB ports work with the newest drivers (PharLap RTOS).
  6. Version 1.0.0

    145 downloads

    A native Labview (wire) general real matrix solver. Based on BLAS (FORTRAN code included)
  7. Have anyone managed to get the com port on the NI3100RT module working (for RT OS, not Windows) ?
  8. 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)
  9. Same problem. I can upload images to the repository, but not files. I tried both the "new" version and the "old".
  10. 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.
  11. 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.
  12. 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?
  13. 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.
  14. 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.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.