09-05-2018 04:42 AM
Hi everyone.
sorry for the x-post i need to make decision whether to proceed with OOP or QMH.
I need help regarding LVOOP implementation. I have gone through several examples and documents on LVOOP for quite some time, and finally decided to use it in this simple application. In my project LabVIEW application communicates between a PLC(local) and a server(TCP).I have used command pattern.For the server part i have created class and methods and it runs in a separate loop(i pass messages from main process loop). my problem is how can i make my main process using the same method?
In QMH or state machine i can do it easily by checking condition and queuing next action how can i implement the same using OOP?
I have tried passing the next command in the current method. Is it the right way to do?
I am also thinking using a while loop inside methods for checking for validating conditions is it okay to do so?
should i use QMH for the main process to send commands to the server loop?
am i doing it all wrong?
Thanks.
Solved! Go to Solution.
09-05-2018 06:46 AM
The way you are getting things set up, you really should look at the Actor Framework. It looks like it was officially added to LabVIEW 2012. But there is an older version available. Just go here to start: READ THIS FIRST to get started with Actor Framework
09-05-2018 07:08 AM
Hi crossrulz,
Thanks for the suggestion, i have read that post before and i am not ready for the AF yet.
Since its my first attempt i'll stick with this LVOOP.
Can i use my process loop to just send commands to the server loop using QMH/SM instead of LVOOP/AF?
Thanks
09-06-2018 10:26 AM
I use Events when I want to send commands from a consumer loop to a producer loop in QMH. I change the Boolean stop event in the QMH template to be a Message type (Message String and Data Variant) like the Queue. By passing the Event handle to every sub-module I can send a command from any module to the producer of any other module. Each module decides how it handles each Event, most ignore most messages. Relevant modules pass the Event into the local queue, where it is operated by the module's consumer.
Sending things over TCP is a bit more interesting, because you have to handle making and dropping connections. I have always used Network Streams and dedicated communications modules, which make this sort of thing easier.
09-06-2018 01:12 PM
Hi MaxJoseph
To make things clear, I am not using TCP to send any stop methods. The TCP part in my application is a static connection to a remote server to which I send predefined messages and obtain reply. This is manged in a separate loop.
I send data and trigger these messages/commands from main loop and for the UI handling is done in another loop. For communication b/w main, UI and the TCP process I did use the way you suggested (or similar).
The application could have been done easily with QMH but I tried to use the LVOOP to get some insight into it (just wanted to give it a try). As crossrulz suggested AF might be the right choice (i understand it is used to communicate b/w multiple parallel independent process) but I am not able to make it for now.
I have managed to implement LVOOP for the main process and simulated some commands. The results look okay but I don't know how it's going to end up when the application is complete and tested with real hardware.
09-10-2018 02:04 AM
Hi,
The benefits of LVOOP come from being able to write code that is modular and cohesive. So you can swap out modules by simply changing the class that wires into a consumer loop, say. This could be done with the data of a command.
For instance, you could have a single module that handles obtaining data from a set of instruments, which are all children of Instrument (e.g. different types of digitiser). Put the child class into a shift register of the consumer loop on initialisation. Then when the module receives the command to 'GetData' it will carry out the method specific to that the relevant digitiser. Write a set of methods 'Init', 'ShutDown', 'Reset', etc. Then when a new digitiser comes along, LVOOP provides a framework on what methods you need to write to integrate the new digitiser to the existing project.
Basically, LVOOP is useful when code reuse or flexibility of hardware or extendability are in your requirements set.