Design problem: RS232 communication

Question

Hi,
I have a design problem for communication with a device via RS232. Since I'm normally a C++ programmer I might just look at the problem from a wrong angle and hope for some hints how to do it in LabVIEW.
The scenario:
A device is communicating with the PC via RS232. The device permanently sends data packets. At the same time, commands can be sent to the device and it returns replies. Data packets and reply packets are arbitrarily mixed, i.e. after sending a command there could be a couple of date packets before the reply comes back but the packets can be distinguished by an identifier.
At least one, ideally several VIs should communicate with the device. Commands should be sent by pressing buttons and the incoming data should be parsed (the packets contain mutliple data streams) and shown on graphs or saved to files.
My initial idea:
Coming from C++ I wanted to build a class for the communication that permanently reads the incoming data and splits it to reply and data packets. This class would then have a function to send out a command and would return the reply or a timeout and it would be possible to register and unregister listeners (I wanted to use queues for this) for the various data streams.
The problems I ran into:
There were a couple but the two most pressing problems were: how could I communicate with the constantly running sample VI (e.g. to stop sampling) and how could I propagate changes to the class to it (e.g. new listeners). Since it is not returning I don't see a good way to implement it as in instance funcion (i.e. pass it the object). I could probably not let the sample function run continously but call it periodically from outside. However I planned to implement the class as a singleton, so it could be used parallely from different VIs.
Is there a best practice for a case like this?
I'm glad about any hints or ideas.
Thanks,
Tobias

Answer 1

tfritz wrote:
Hi,
thanks. Since almost the same thing was suggested to me in a German forum I guess this is really common practice (using one VI with different methods controlled by a queue). It still seems a little "unnatural" for me but my biggest concern (bad interface description) was shattered by the suggestion in the link you sent me to wrap these functions with wrapper VIs, thus caller VIs won't have to deal with the call-by-queue-mechanism. This might also be easier to port to a different implementation later. However I still see the danger that the continously running VI could easily become bloated. 
It also requires me to change the way I have looked at VIs until now. In our course they told us that VIs are basically functions. Using this design patterns, the VI becomes more of a module, really (Like a C module implemented in a C-Source file). But I will try it. It sounds as if it could work.
I will still look into the OOP solutions a little more, though. Do I understand you correctly that you wouldn't recommend using LVOOP because it's still buggy? What about dqGOOP for example? This sounds like it could do what I need (however it doesn't seem to implement things like polymorphism, late binding and inheritance so I don't quite see what's so OOP about it. It seems more like programming with structures in C.)
I don't know if LVOOP is buggy or not.  I think early on it was buggy and things have improved in recent versions. I have read that it doesn't have all the features that you would have in OOP like C.  I wouldn't recommend it only because I'm not familiar with it at all.  I can't recommend something that I'm not comfortable with.  If you go that route, plan on spending time in these forums and in LAVA to reading up on what others have done.  I haven't hard of dqGOOP.
But back to your suggestion. I still have a couple of questions:
- How do you return values from the module? Would you use a queue for that as well?
- Where would the parameter queue be held (created and passed to the VI)
 I would store all of these in a functional global variable.  This is the VI that stores data in shift registers.  Ben's action engine nugget is an advancement on that.  This allows for both the calling VI and the parallel running subVI to get and set the data as needed.  It runs quickly so neither process should be forced to wait while the other  VI is doing its thing.
- My VI has to be constantly sampling and this shouldn't be interrupted too long by other functions as adding a listener. However both functionalities have to access the same kind of data. Is there an easy way to parallelize this? Would the sampling be a case in the case diagram that's always used if no command was sent to the VI or would it somehow run parallely?   Yes.  There are a couple of ways of doing this.  One would be for the dequeue to have a timeout function.  In the event the dequeue times out, you run the code that is doing the acquisition.  I think a better method is that the code that does the acquisition enqueues its own command again to the end of the queue.  Let's say that is command A.  So when case A finishes, it enqueues A, which seeds itself to run again.  So if nothing else comes into the queue, it just executes A , A, A, A.  But let's say another section of code needs to do something such as command B.  It will slip B into the queue while A is executing.  So you would A, B, then A again, because A would get slipped back into the queue when the first A finishes, but B has already been put in while the first A was running.
- Would it be possible to make the VI reentrant and in this way use it simultaneously on different COM ports (using different parameter queues as well)? I'm not sure if I will need this but it would be neat if it could work.
I think you could do this.  It may be a case where the VI is saved as a template  (.vit) and you initiate it multiple times.  I haven't needed to do this before, so I'm afraid I can't provide any details or useful tips. 
Well, I will fool around some more. Thanks so much for your help. This is kind of exciting since the concepts are quite new for me. Btw, is there something like an academic theory (computer science) for LabVIEW? I came across functional languages in university but data flow languages are still a new concept for me.
Tobias
tfritz wrote:
Another question about the "dynamically starting" of the VI:
How is the path handled? Is it guaranteed that it always takes the VI from the project or does it just search for the first VI by that name it finds in the file structure? Does this still work when building an .exe from the project? What happens if the VI is already running? Can you test for this?
While I'm at it: is there a way to stop LabVIEW from searching for subVIs it can't find when openin a VI? This resulted in very unexpected behaviour sometimes where it would find the VI somewhere else (with the same name but maybe an older version).
In my case, I just had the path hardcoded.  It is my only instance, I'm not planning on moving the VI's.  If you don't have the path, it will take a VI by that name if it's in memory.  If it isn't in memory, it starts searching relative to the calling VI's path.  One thing I know, if you are dealing with relative paths, a subVI has a different relative path in an .exe as opposed to the development environment.  The name of the .exe becomes a folder.  So in development, if your sub VI is mySubVI.vi.  In an executable, its path is MyExe.exe\MySubVI.vi
For all of this, I recommend searching the forums to get more details.
If it is searching for a VI, you can hit ignore.  But of course you'd have to do it before it finds it.  When you are dealing with versioning issues, I recommend making a backup copy of the entire directory structure elsewhere.  Some location where it shouldn't stumble across it.