jcz

Thanks for all your replies. @Ben : good idea with using VI server. I will have a closer look into this. @Mark : yes, I am aware that I still could use LVOOP, but I think the whole program would then be over complicated in this case. @Shaun: I will have a single device (different variants of this device) connected to a PC on multiple interfaces an protocols I think I am going to use my current architecture that I used to develop another application ( see: http://lavag.org/top.../page__p__58451 ).

What would be the best approach to design & write an application that need to control a device using multiple protocols via multiple interfaces (e.g. SCPI over GPIB and SNMP over ETH) ? Before anyone answers OO, I'd like to complicate this question by saying that it needs to work with LV 7.1.1 (aka not OO). Jakub

well done !

Thanks guys for all suggestions. They are very useful for me. As soon as I get to the coding again I will implement your suggestions. Jakub

QUOTE (Mark Yedinak @ Mar 25 2009, 03:59 PM) Hi Mark, Thanks for reply and sorry for my delay in response. I foolishly believed that the forum will automatically notify me about reply, and simply forgot to check it Firstly I should say that I am still working on this architecture, as I develop the main application, so all those things I am writing about might be solved within say weeks. What I'm dissatisfied with is mainly the fact that all sub-programs are waiting for the telegram by querying the "inter-process" queue status in a while loop. This lows down the message handling, and even it's just a tiny delay, sending hundreds/thousands of commands may delay the whole program. I still haven't worked out how to lock a subprogram from receiving any new telegrams (e.g. during initialisation). And finally at the moment the telegrams are one-directional only - the only response from any subprogram is the acknowledgement that it finished what it was asked to do. So that for me the telegram is only a message related to some sort of action (e.g. grab image from camera), and the result of this action (i.e. image) is then stored in a functional global which is accessible from main program. The main idea I had was to create a bunch of main programs that would pretend to be a real-hardware-devices. So then I could simply implement some sort of protocol, define commands and talk to each sub-program as it was a real device. For instance to grab an image from a camera, I could then add a command to a queue (in exterme version SCPI-like command) :camera:image:snap, and only camera interface would run this command returning ACK. I am curious if there is anyone who came up with similar approach. At the moment I am trying to work out in details LabVIEW Queued State Machine Architecture by expressionflow.com : http://expressionflow.com/2007/10/01/labvi...e-architecture/ Below some screenshots of my implementation: Telegram queue (from,to,subject,message) : Telegram send & wait for ack Receive mechanism in a subprogram: Jakub

write about it http://decibel.ni.com/content/docs/DOC-3278 - Enter the Flip for LabVIEW DIY Contest :-)

cross-post with http://decibel.ni.com/content/thread/2532 : NI Home > Communities > Groups > Large LabVIEW Application Development > Discussions Dear All, I am developing a medium-sized application. I've got a camera that detects a laser beam on a wall, a system that controls this beam and a switch to change between various beams. I used a modular architecture such that a separate program controls the camera (image acquisition and analysis), separate program to control the mentioned system, and a separate small program to control the switch. Each program can be run independently and can be build as a standalone application (used a consumer-producer architecture). Once I had those three small applications (let's call them sub-programs), I've written another application to control other apps. I implemented a common queue for all sub-programs and the main one to send 'telegrams' between all of them (cluster with two enums FROM,TO and two variants SUBJECT,MESSAGE). Each sub-program continuously checks the status of the 'telegram' queue and once the message is addressed to it, the queue element is dequeued and analyzed. The sub-program then does what it was asked to do and sends back an acknowledge telegram back to where it came from (the main application waits for this acknowledge). Then the main app access the data from the subprograms (functional global or reference to controls).. but it's a different story. Basically it all works quite nicely, but it's not perfect, and I want to change it. I've got some ideas, but I was wondering if you have any suggestions, links to a good resources or ideas on how to develop such modular (is that a good word for it?) applications. Ideally with examples, and screenshots (or LabVIEW 7.1 compatible code). BTW. I know about http://zone.ni.com/devzone/cda/tut/p/id/7198 - Large Application Development in LabVIEW http://zone.ni.com/wv/app/doc/p/id/wv-160 - Software Design Architectures in NI LabVIEW http://zone.ni.com/devzone/cda/tut/p/id/3252 - Developing a Modular Software Architecture but it's not really what I am looking for. regards, Jakub

QUOTE (Mark Yedinak @ Mar 5 2009, 08:02 PM) Good point, I will change the global variables to functional globals. What I tried before using global variables, was a simple change of subVI's input contol values (using VI reference > Panel > Controls[] > Name,etc. ) and then running the subVI dynamically (Invoke Method:Run) . For some reason it didn't work. Well it worked when I run the VI that was loading the subVis dynamically, however when anything higher in the hierarchy was calling the VI, all 'dynamical' subVIs had the controls set to default.

Thanks guys, I forgot to mention that I am (still) using LabVIEW 7.1.1. I guess I should really update to at least 8.2. I found a solution without using classes. Basically I am using a mixture of "Open VI Reference" with global variables as a substitute of "inputs" and "outputs". See attached screenshots. It's not perfect, but it works. Jakub

hi all, I couldn't think of any good topic title. Anyway. A bit of intro: I am developing an application that uses one camera. This application will be used on two different PCs. So I need 2 cameras and I have 4, but every one is different (and it could change). So say I've got N number of cameras, each may be using different type of interface and drivers (USB with it's own DLL drivers, USB based on NI IMAQ USB driver, FireWire with ActiveX control, or one connected via BNC cable to a NI PCI-1407 framegrabber). Every single one of them needs installing a driver of some sort. Now. What I want to avoid is an installation of all possible drivers for each type of camera. The question is how can I develop an application that is capable of using various cameras, without need of installing all drivers ? E.g. PC #1 will use USB camera, and it will have a drivers for it installed but not for any other type of camera. PC #2 will use FireWire Camera, and it also have drivers for it but not for any other type of camera. I guess the answer lies somewhere in dynamical loading of the VI's, but I am not sure how to do it correctly (in a 'what would be the best practise' way). Basically what I want to develop (in fact I already wrote it, but needs refactoring) is a VI with inputs [iMAQ image,type of camera, other settings, err.cluster] and an [iMAQ image, err.cluster] as the outputs. thanks, Jakub

Hi, One of the cursors (the green one) on my XYGraph somehow shifted itself and is no longer above the cursor (see screenshot). I have no clue how to fix it (apart from deleting the cursor, adding new and setting everything from scratch). Any suggestions ? Jakub

Hi there. Do you know any method of checking the number of times a VI ran ? Something similar to #run in Tools >> Advance >> Profile VIs.

Like Bender from Futurama used to say: Aw, crap! Not many people voted for my solution Anyway I am glad to be in this the finals, and I wait for more codding challenge And thank you to all who organized this challenge. jcz

"This site is no longer available." I only found part II here : http://zone.ni.com/devzone/conceptd.nsf/we...81?OpenDocument part I seems to be not complete : http://zone.ni.com/devzone/conceptd.nsf/we...625692F0062EADF

I totally agree, however some issues might occured when: 1. different "small details" that every software engineer use in his own way (like the way of passing data from subvi to main vi - one is using queues, one notifications and the other one somethin else) are in one big program. 2. when software eng. are in 3 different countries and in different time areas 3. when quite often students come from outside and they want to do some VI's 4. puttin 2 and 3 together --> when people have got different LV experience 5. it is always good to have templates - that is one part of what I am doing. True - "coding" perhaps is not a proper word. Designing software is something different than writing it In general You are right, and I am not getting bureaucratic (at least I hope so), and we always talk about our software It's just getting everyone experience on how to write good and fast programs and writing it down in one document - so that it will be easy for everyone to debug the software knowing standard solutions used by other person. Thank you all for the references. I know most of them - it means that there are not many LabView coding standard books/ebooks, etc. cheers, jcz

hi all, I have started to write a labview coding standards for our small software team. Have you got any pdf articles, templates, or any other documents, ideas and suggestions that might be usefull for writing such spec. ? cheers, jcz