Leaderboard

I started a new job yesterday that I think is going to be great, and I just got my CLA results...I PASSED!!! Life is good!

There is no universal "best" way that I'm aware of. There are ways to provide more flexibility to accomodate changes at the expense of writing a little more code and adding more abstraction layers. What's "best" depends entirely on the requirements for your application. (Of course, there are bad implementations that require more code and provide less flexibility, but we'll skip those. ) The answer partly depends on the framework of your existing code and how much refactoring you and management can tolerate. Given a blank sheet of paper and knowing nothing about your actual physical system, my first inclination is to have each reaction object running in it's own thread, either by using parallel loops or perhaps by implementing them as active objects. Then I'd implement an AnalysisInstrumentManager class that can hold n number AnalysisInstrument objects, one for each actual instrument in the system. The AnInstMgr class would also run in it's own thread. When a reaction needs access to an analysis instrument, it requests one from the AnInstMgr object. If one is available, AnInstMgr sends the AnInst object that refers to the free instrument to the requesting reaction object, which uses it and returns it to AnInstMgr when it's no longer needed. This design gives you a lot of flexibility in the number of of analysis instruments you have in your system, frees you from having to create logic to decide which AnInst object to use, and avoids the danger inherent in using singletons. An unspoken assumption I've made in the above paragraph is that the driver for the analysis instruments supports multiple driver instances for multiple devices. For example, if you are communicating with the instruments via string commands over independent serial ports, no problem. If you have to go through the vendor's dll to talk to the device, this design might not work. Most, if not all, dll's I've worked with handle connections to multiple devices internally within a single instance of the dll. If that's the case I believe you'd need to change the design around a bit, though this is an area I don't have much experience in. I mentioned private globals and private functional globals in my previous post. Either of those would work if you don't want to connect the class methods to a wire carrying the actual object. (Note that unless you ditch dynamic dispatching you'll still have to wire a class constant to the method.) However, in general I don't think it's a good idea to make your lowest level instrument driver class a singleton. Keep it a regular by-val class. Who knows how you'll want to use that driver class in the future? It's easy to wrap a by-val object in another class to give it singleton behavior when you absolutely must have it, but I don't know of any way to get by-val behavior from a singleton object. I would probably also approach this component from the standpoint of a regular by-val object that is distributed by an object manager class to a requesting client object. Here's a thought that finally coalesced as I was sitting here thinking about your problem: When using a singleton (or action engine) for your instrument driver class you have to provide lock/unlock methods for those times when a reaction object has to execute multiple steps without interruption. There's always the chance that someone forgot to (or didn't know they were supposed to) lock the resource. This kind of bug could easily go undiscovered for a long time. By distributing the by-val instrument object to the client as opposed to having the client make calls into a singleton class, you've guaranteed by design that no other reaction object will be able to use that instrument until the first one is finished with it. That design decision just eliminated an entire class of potential bugs. My sense is that this is a pretty significant advantage but I'll have to ponder this for a while before I add it to my list of best pretty good practices. "What if..." is an excellent question and is not asked nearly enough! To expand on that thought, what happens if one of them breaks and has to be sent in for repair? Will your software still work with a single instrument? What happens if the instrument is irrepairable and you replace it with a different model? What happens when the powers that be decide that 8 concurrent chemical reactions and two liquid handling systems are needed? You probably don't need to build all that flexibility into the system, but you should have a reasonably good idea of how much effort it will take if those kinds of requests come down the pipe and communicate the design limitations to your customers.

New Feature Request: It will be nice if we can have a search state Control on the top. It could be a combo box where user will type a search string and the combo box will populate all the relevant States which contain that search string. It could be such a way that as when the user types the closest match case could be automatically shown to the user... this will be really useful when there are many states Rajkumar

An easy way to accomplish this is through VI server and the usage of Re-entrant Front Panels or the use of *.vit 's First step is to make a VI that will be cloned over and over for each new note. Flag the open with option 0x08 and it will open a new VI with each call. <object width="1020" height="628"> <param name="movie" value="http://content.screencast.com/users/NJKirchner/folders/Jing/media/5fc68419-458d-495e-a4fe-582888c1dcf6/jingh264player.swf"></param>'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/5fc68419-458d-495e-a4fe-582888c1dcf6/jingh264player.swf"></param> <param name="quality" value="high"></param> <param name="bgcolor" value="#FFFFFF"></param> <param name="flashVars" value="thumb=http://content.screencast.com/users/NJKirchner/folders/Jing/media/5fc68419-458d-495e-a4fe-582888c1dcf6/FirstFrame.jpg&containerwidth=1020&containerheight=628&content=http://content.screencast.com/users/NJKirchner/folders/Jing/media/5fc68419-458d-495e-a4fe-582888c1dcf6/2009-12-07_1054.mp4"></param> <param name="allowFullScreen" value="true"></param> <param name="scale" value="showall"></param> <param name="allowScriptAccess" value="always"></param> <param name="base" value="http://content.screencast.com/users/NJKirchner/folders/Jing/media/5fc68419-458d-495e-a4fe-582888c1dcf6/"></param>'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/5fc68419-458d-495e-a4fe-582888c1dcf6/"></param> <embed src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/5fc68419-458d-495e-a4fe-582888c1dcf6/jingh264player.swf" quality="high" bgcolor="#FFFFFF" width="1020" height="628" type="application/x-shockwave-flash" allowScriptAccess="always" flashVars="thumb=http://content.screencast.com/users/NJKirchner/folders/Jing/media/5fc68419-458d-495e-a4fe-582888c1dcf6/FirstFrame.jpg&containerwidth=1020&containerheight=628&content=http://content.screencast.com/users/NJKirchner/folders/Jing/media/5fc68419-458d-495e-a4fe-582888c1dcf6/2009-12-07_1054.mp4" allowFullScreen="true" base="http://content.screencast.com/users/NJKirchner/folders/Jing/media/5fc68419-458d-495e-a4fe-582888c1dcf6/" scale="showall"></embed> </object>

I remember an issue with LabVIEW crashing if you CTRL+Drag'd linked tunnels. I haven't run into it yet, but it's certainly made me wary of them.

I've changed this to look at the FP.State. I fixed this. I wasn't updating the list so it looked like it wasn't working. These are good ideas. Stay tuned. Thanks, it's perfect.I don't have LV 8.2 to test on and really appreciate your feedback. The latest version is here. Jim