Posted 06 March 2012 - 03:16 PM
Well. My "negative" comments are'nt so much about your code. More about the serial implementation of VISA. The fact that once you are in a "read" you are stuck until it times out (not even the vi stop button will have an effect) means that you are forced into checking bytes at port and re-implementing the timeout. This makes any serial vis far more complicated than they need to be (and incongruous with all other VISA interfaces). My "positive" comment would be "if it's not broke, don't fix it" and you have proven it works since you state that you have "used for some time". Therefore it's only a style thing if anyone is going to comment.
Up until recently (well a year or two ago). I too used the action engine approach also. I eventually split out the sub-frames into separate VIs and pulled them together in a plymorphic VI. This has a couple of minor advantages over the AE in that you can have different terminals for each action, different icons (if you so desire) and a nice little drop-down under the VI instead of a typdef (slight readability improvement IMHO). You could just wrap the current vi in some more VIs to achieve this rather than pulling out the frames as I did, but it was just a personal preference and brought the serial in-line with tcpip and others that I chose to go that route with.
Wrapping in a polymorphic VI at this level does have one disadvantage though. Since you cannot nest polymorphs, it means you cant wrap higher level protocol vis that use these into a polymorphic VI. It forces you to make protocol dependant serial transactions (e.g reads based on a byte length) an item in the drop-down at the same level (flattens the hierarchy and couples dependancy).
A positive attitude may not solve all your problems, but it will annoy enough people to make it worth the effort. (Herm Albright 1876-1944).
Founder and general mischief maker on www.labview-tools.com
aficionado and websocket
If it 'aint in LabVIEW, then you 'aint got a clue!