Jump to content

SIMPLE Object Based Framework


Recommended Posts

Hi all,

 

My concern is about object based framework.

I'd like to talk about a "sensitive" subject, which divides people around me.

I'm sure there are a plenty of objects aficionados here.

A few years ago, LabVIEW give us the first object based template : the Actor Framework, which is certainly powerfull

 

...but just

 

UNREADABLE !!!!

 

When I conduct Core3 training, I'm tempted to show what could be an object based framework in LabVIEW, then I remember how the actor framework looks, then I decide to make my trainies continue to use LabVIEW, and finally I don't show the actor framework.

When will NI provide a SIMPLE object based framework in the TEMPLATES ?

Something like the command patern exposed here by Elijal Kerry :

https://ekerry.wordpress.com/2012/01/16/oriented-design-patterns-for-labview-that-can-make-your-life-easier/

or in a the test executive example of the PTP sequencer :

http://www.ptpartners.co.uk/ptp-sequencer/

I still use the "old" QSM (please Daklu, don't bite me), for sure it is not an ideal solution...

I love objects, I used them a lot in my code, but not currently for my high level code.

Any links or suggestions ?

 

Thanks,

 

Sebastien

 

CLA

Link to comment

Full disclosure I don't use the Actor Framework and am not a fan.

 

That being said, NI apparently did consult with many real world CLA's on how to make the Actor Framework.  I don't know who in particular they consulted with, but the intent was to get the opinions of those that would end up using the framework, and try to understand the best way to make it.

 

Also if you are a CLA and have the opinion that the framework is UNREADABLE, then I feel there is something wrong here.  Either the framework does need major overhauling, or maybe you need to look at some training on the framework.  I'm not trying to suggest you aren't competent please don't read it that way.  I just don't know how much you have invested in trying to understand the framework and certainly anyone new to it will feel lost (I know I do).

 

I often fall back into the QMH on a fresh install of LabVIEW, or the JKI state machine if I have a chance to install it.  For larger applications I usually spin my own actor type design using user events and variants.  I can't get over several things with the Actor Framework like the re-entrant actors, which make debugging difficult.  Honestly it might just be how I think about my applications, but there is never a time when I would want to kill just a single actor.  The only time an actor should close, is if the global quit was issued.  With plugin architectures, and factory designs I can see a need, but that just isn't the world I live in.

 

EDIT: Just saw this crosspost.

  • Like 1
Link to comment

Predictably, +1

I laughed but that could be read a few different ways.  Let me clarify I actually made several efforts to use the Actor Framework.  So I wasn't trying to say I hate this thing that I've never used.  I was trying to say I made an effort and didn't like some things about it.  It isn't complete crap, but it over complicates things where I don't need it to be, and doesn't do some of the common things I would like it to.  People with different needs may find exactly what they need in the Actor Framework.

Link to comment

I laughed but that could be read a few different ways.  Let me clarify I actually made several efforts to use the Actor Framework.  So I wasn't trying to say I hate this thing that I've never used.  I was trying to say I made an effort and didn't like some things about it.  It isn't complete crap, but it over complicates things where I don't need it to be, and doesn't do some of the common things I would like it to.  People with different needs may find exactly what they need in the Actor Framework.

Pretty much my assessment so my comment was agreement with you. For clarity, it is well known I dislike the AF, hence the predictably bit since I view it as a Rube Goldberg machine that solves a problem noone really has, in a way noone really needs.

Link to comment

They use Text-Variant messages rather than Command Pattern, but the OP could also consider looking at:

— mje’s Message Pump, which uses “Actorâ€-like objects that can be inherited from to add functionality.

— my Messenger Library, which includes a Sample Project that redoes the NI “Continuous Measurement and Logging†example.  It uses OOP extensively in the Message-passing objects, though the “Actors†are actually just single VIs.   Don’t know if this counts as an “object-based frameworkâ€, as one isn’t required to do much OOP in actually using it.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By apoorve kalot
      just following a tutorial on YouTube [https://www.youtube.com/watch?v=Ko0heNZhRvI], for setting objects in lab-view for simulation, doing the steps as stated. as program executes, the resultant spheres, ( which has been added to the 3D picture object, are very far out zoomed ) , done the following steps  to correct it, still no help
      1) seen online help of using "shift + drag" to correct it, but it's still no help,
      2) changed camera position to : none and auto - redraw, still no help,
      since i am new to this, it is request to state the measure to correct the problem and to avoid these problems.
      Along with one question : how to add Co-ordinate axises for reference to it, independent of any other objects, [ i.e. the axises shouldn't be affected by rotation, translation or objects ] in 3D picture object
      edit : same question is posted as well on : https://forums.ni.com/t5/LabVIEW/camera-postion-stuck-in-3D-picture-control/m-p/3990030#M1138526
      trial.lvproj trial_001.vi
    • By Benoit
      Manufacturing a satellite or a simple pen require to test the quality of the product before delivery to the customer.
      LabVIEW is widely used for that purpose. Since 20 years of LabVIEW development I saw numerous test framework. I was wondering if people where interested to work in a collective and open source test framework.
      Per example the following feature can be included:
      HAL (hardware abstraction layer)
      Database to record test results with the data viewer (PostgreSQL)
      single/asynchronous/batch/debug mode
      multi-language support
      Image analysis (open CV) + bar code reader
      User access level
      Remote monitoring
      Jig identification to prevent user error (testing the wrong product with the wrong jig/test sequence)
      HTML/xml/txt report
      and so on....
      Benoit
    • By Nerich34
      You'll find the object, lay the plots, but did not remain there in the plots and do not tie them together. 
      How could I lay and connect the plots?
      Thanks for the help!
      Object tracking using.vi
    • By Mojito
      Hi all,
       
      I've been maintaining and improving a LabVIEW project which controls and automates a prototype microscope array for 2 years. I'm an engineering apprentice so I don't have that much experience with LabVIEW.
       
      The current framework of the project is a simple "Producer/Consumer" which has served well but is no longer future proof and scalable. I want to revamp the program which is quite big and complex. And I need help since this will be the first time of actually starting a real project from the ground up.
       
      The most modular and scalable framework I found was the QMH (Queued Message Handler). It's similar to the basic P/C loop and has the possibility to have multiple parallel consumer loops. But I have no experience on starting from 0.
       
      If any you have docs or give advice on starting the project would be appreciated. Especially something on codding with a QMH structure would be helpful.
       
       
      Cheers from France!
       
       
    • By Fab
      Hi LAVA friends,
       
      We are pleased to announce that the Delacor Queued Message Handler (DQMH) is now available via the LabVIEW Tools Network:
       
      http://sine.ni.com/nips/cds/view/p/lang/en/nid/213286
       
      You can read about the thought process behind DQMH at our blog post: Ours is not better than yours (or YAF=Yet Another Framework) at WalkingTheWires.com
       
      The DQMH is based on the NI QMH Project Template. The DQMH expands on the NI QMH by providing safe, event-based message handling and scripting tools to encourage same style between different developers in the same project and improve efficiency. The DQMH is ideal for applications where multiple modules must run in parallel, possibly at different rates, while communicating with each other. The DQMH can also be used for applications that have a single module, where the developer would benefit from having a Tester with the capability of eavesdropping on the different DQMH events and messages. 
       
      The DQMH integrates with TestStand since all development and troubleshooting can take place under LabVIEW, while calling the public API VIs as individual steps in the TestStand sequence. The tester can eavesdrop during the execution of the TestStand sequence. This is specially useful when the LabVIEW code is written during the research and development or prototyping phase, because the same code can be called by TestStand in production or manufacturing sequences without any changes.
       
      The DQMH uses LVOOP for some internal functions, but developers need not be familiar with LVOOP to use or understand this architecture.
       
      Try it out and let's us know what you think.
       
      Fab and the Delacor team.
         
       
×
×
  • Create New...

Important Information

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