Jump to content

bsvingen

Members
  • Content Count

    279
  • Joined

  • Last visited

Everything posted by bsvingen

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

    149 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
  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
  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
  15. 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
  16. 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.
  17. 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 ref
  18. 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
  19. 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
  20. 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.
  21. 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.
  22. 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 ??
  23. 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?
×
×
  • Create New...

Important Information

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