Jump to content

Object Oriented in Producer/Consumer

Recommended Posts

Hello Everyone,

I need litter suggestion about object oriented with Producer Consumer design pattern.

I have One MAIN program and Other 7 module that controlled (mean sending message or command by queue to module) by MAIN program and it has producer consumer design pattern.Now i want to convert this application into OOP but my doubt is if I will convert in OOP then each case in consumer loop is become a class(Command pattern).In such case I have more than 100-200 class in entire application.

is it good idea to have such big amount of class in application? or i misunderstand something?

looking forward to your suggestion.thanks

Link to comment
17 hours ago, Bhavin Gabani said:

is it good idea to have such big amount of class in application? or i misunderstand something?

It sounds like your plan would be to follow the actor framework approach, where each receiver is a class (7 module+1 main) and every message is a class (+100-200). Its definitely been done, and its a concept that NI supports given that actor framework ships in the product, but I personally wouldn't want to deal with that many classes in a project. Labview becomes significantly more unstable just by adding a single class, and both stability and (edit time) performance take a hit as you add more.

There are alternative half-way routes too...what benefits do you expect from OOP for your application?


Edited by smithd
Link to comment
17 hours ago, Bhavin Gabani said:

Well by oop i would expect Modularity and by adding HAL(in OOP) gives Scalablility .I will not going to follow AF but I am trying to use Producer-Consumer and each case in Consumer loop become Dynamic dispatch. 

The design of distributing code components among numerous self-contained processes is already geared towards the goal of modularity and scalability. Depending on how responsibilities are separated, these different processes could scale out (I need to handle 8 new devices so I launch 8 new loops) or  provide modularity (one of my devices changed over from a Tek to an agilent so I just need to swap out this one process). These benefits are similar to those of the more common synchronous OO code and both styles are related to https://en.wikipedia.org/wiki/Message_passing (see especially "synchronous vs asynchronous message passing").

What you're saying is that you want to layer the synchronous style of OO on top of what is (or is close enough to) the asynchronous style of OO. This is why I ask...what specific things do you want to do with LVOOP that you can't currently do with your existing design. The answer to that should give you an idea of how much LVOOP you might want to use to accomplish those goals.

To try to give an example rather than talking vaguely, actor framework has a few different goals and layers. (I am not the expert on it so I'd refer you to this document for a more official view.)
-It provides an interface for dynamically launching processes. In order for this to be generic, the developers went with an OO solution.
-It provides a mechanism for handling messages generically where each message is bound to a particular hierarchy of processes (eg mymessage might perform actions on myclass, myinstrmessage might perform actions on myinstrprocess, etc).
Actor framework combines the two but it sounds like you only want the second bullet -- unfortunately, this is where most of the class implementations are.

I mentioned half-way routes...one *example* is that you could implement something like this: have a class called "myStateInfo" and it has a "handleMessage" dynamic dispatch method which takes a string and a variant. In the "handleMessage" method, you have a case structure based on the string, and you use that string to perform whatever actions you'd like. In the "default" case, you call the parent method. This would give you some measure of reuse (you don't have to implement a message handler that your parent already implemented) but would only require 1 class per process. 

Edited by smithd
  • Like 1
Link to comment
17 hours ago, Neil Pate said:

I would second what smithd wrote.

What is your experience with OO in LabVIEW? Certainly trying to refactor an application to OOP is not a good place to start your journey I think.

I have intermediate experience in OO that'y i am not prefer to have Actor Framework because i know about how learning curve of Actor framework.

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.

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 cyro2015
      I tried to create a template based on OOP for QMH. During development I have been confronted with infinite crashes of LabVIEW so I decided to slow down with this project and open it to the community. I finished my working example and stopped for now.
      So if anyone is interested to play around with the code, see attached ZIP file (LV 2020).
    • By Marko Hakkarainen
      I had some time to learn about new interfaces and finally I could implement my collection class as I had envisioned. I didn’t want to use iterable and iterator names, because I thought that would have been too bold a claim.
      The original version of the collection class was (and is) used as a collection of sequence steps. Each element can be either a sequence command (send message, wait timer, wait complete etc.) or another collection of commands (sub-sequence). That’s the reasons for the labels and search method. Otherwise it is just a fancy (Rube Goldberg) array.
      Next method is recursive and it steps through all elements in the collection. Execute is only method, which requires override.
      For now, it’s at least an exercise in new interfaces. I don’t know if it’s useful enough to be in the code repository, but I can polish it up if needed.
      Marko H
      Certified LabVIEW Architect
      Iterable Collection LV2020.zip
    • By McQuillan
      Hi Everyone,
      I (re)watched James Powell's talk at GDevCon#2 about Application Design Around SQLite. I really like this idea as I have an application with lots of data (from serial devices and software configuration) that's all needed in several areas of the application (and external applications) and his talk was a 'light-bulb' moment where I thought I could have a centralized SQLite database that all the modules could access to select / update data.
      He said the database could be the 'model' in the model-view-controller design pattern because the database is very fast. So you can collect data in one actor and publish it directly to the DB, and have another actor read the data directly from the DB, with a benefit of having another application being able to view the data.
      Link to James' talk: https://www.youtube.com/watch?v=i4_l-UuWtPY&t=1241s)
      I created a basic proof of concept which launches N-processes to generate-data (publish to database) and others to act as a UI (read data from database and update configuration settings in the DB (like set-point)). However after launching a couple of processes I ran into  'Database is locked (error 5) ', and I realized 2 things, SQLite databases aren't magically able to have n-concurrent readers/writers , and I'm not using them right...(I hope).
      I've created a schematic (attached) to show what I did in the PoC (that was getting 'Database is locked (error 5)' errors).
      I'm a solo-developer (and SQLite first-timer*) and would really appreciate it if someone could look over the schematic and give me guidance on how it should be done. There's a lot more to the actual application, but I think once I understand the limitations of the DB I'll be able to work with it.
      *I've done SQL training courses.
      In the actual application, the UI and business logic are on two completely separate branches (I only connected them to a single actor for the PoC) 
      Some general questions / thoughts I had:
      Is the SQLite based application design something worth perusing / is it a sensible design choice? Instead of creating lots of tables (when I launch the actors) should I instead make separate databases? - to reduce the number of requests per DB? (I shouldn't think so... but worth asking) When generating data, I'm using UPDATE to change a single row in a table (current value), I'm then reading that single row in other areas of code. (Then if logging is needed, I create a trigger to copy the data to a separate table) Would it be better if I INSERT data and have the other modules read the max RowId for the current value and periodically delete rows? The more clones I had, the slower the UI seemed to update (should have been 10 times/second, but reduced to updating every 3 seconds). I was under the impression that you can do thousands of transactions per second, so I think I'm querying the DB inefficiently. The two main reasons why I like the database approach are:
      External applications will need to 'tap-into' the data, if they could get to it via an SQL query - that would be ideal. Data-logging is a big part of the application. Any advice you can give would be much appreciated.
      (I'm using quite a few reuse libraries so I can't easily share the code, however, if it would be beneficial, I could re-work the PoC to just use 'Core-LabVIEW' and James Powell's SQLite API)

    • By Zyl
      Hi everybody,
      I'm running into something I don't really understand. Maybe you can help me here !
      I've got a LVLIB that is used as an 'Interface': it exposes public VIs which wrap around public functions of a private class (see code attached) . The class is private because I want to force the users to use the 'interface' functions.
      In one of my interface VI, I create a DVR on the private class (Interface_init). The DVR is stored into a typedef (FClass_DVR.ctl) and this typedef is the 'reference' that link all the interface public functions.
      In TestCode.vi (which is not part of the lvlib and illustrates the standard code that a user can create to use my driver), I can call my public interface functions and link them without any problem.

      But as soon as I create an indicator on that reference (to create a state-machine-context-cluster for example), my TestCode VI breaks !

      The error returned is : This VI cannot use the LabVIEW class control because of library access scope. The LabVIEW class is a private library item and can only be accessed from inside the same library or libraries contained in that library.
      I understand that the class is private. But the DVR is contained into a public control. Using an In Place structure on that DVR into TestCode would not work, since the class is private. So why is the DVR control problematic at that point ? Creating it do not breaks any access protection...
      Am I missing something ?
      DVR Private POC.zip
    • By Brains
      Does anybody know the best way to make a copy of a byref object (open gds v4) at runtime and pass all the attributes values (including inherited attributes) to the new object?
      Thank you!
  • Create New...

Important Information

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