Request for suggestions on structuring!
Dear Group, Please can you educate me, my brain's exploding here. I've been given a huge, old-style procedural flow diagram to code up in LabView 7, to create an automated test environment. (Thanks so far to Chris Harden for your help, but I'm still stuck on details.) See http://www.spherica.demon.co.uk/LabView/basic%20flowchart.gif So far, I've broken it down into individual processes, which I've saved as individual VIs. Until I can get my hands on our GPIB instruments, these processes are just dummy VIs (i.e. chains of message boxes explaining what _will_ be going on) so that I can hopefully check the overall flow with the program designer. I'm having great difficulty in figuring out how to sequence these dummy subVI's, epecially since there's no actual meaningful data flowing yet, only the 'enable' input to the beginning of a chain of message boxes within any subVI, ending with the 'OK' output from a final message box at the end of that subVI. I don't understand exactly what to do with the connector panes; I wish they were connectable to the block diagram, not things on the front panel! I just don't know how well LabView actually allows a person to achieve any procedural programming at all; all I've seen so far are mostly stand-alone routines that seem to suffice in simple cases. I can drive a 3 or 4 case structure from a 3 button dialog box with no problem, but I want to run a subVI by pressing a button on that box and have it behave as a pop-up front panel that then closes and returns to the 3 button dialog box after completion. I expect I'm over-complicating everything as usual due to lack of knowledge. If anyone can suggest how to structure the LabView code to achieve the above flow diagram, I'd be supremely grateful! Best regards and may your code always work, Matt Rhys-Roberts UK
RE: Request for suggestions on structuring!
Here is a standard(private mail only) structure we use. We could call it a LV2 Global style queue driven menu state and event machine. Basically a global queue driven state machine with and event structure un the idle case. Also comes with other little preprogrammed functionnalities. Anyone interested in having it. Email me. Goodday :o) -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de [EMAIL PROTECTED] Envoyé : April 2, 2004 7:39 AM À : [EMAIL PROTECTED] Objet : Request for suggestions on structuring! Dear Group, Please can you educate me, my brain's exploding here. I've been given a huge, old-style procedural flow diagram to code up in LabView 7, to create an automated test environment. (Thanks so far to Chris Harden for your help, but I'm still stuck on details.) See http://www.spherica.demon.co.uk/LabView/basic%20flowchart.gif So far, I've broken it down into individual processes, which I've saved as individual VIs. Until I can get my hands on our GPIB instruments, these processes are just dummy VIs (i.e. chains of message boxes explaining what _will_ be going on) so that I can hopefully check the overall flow with the program designer. I'm having great difficulty in figuring out how to sequence these dummy subVI's, epecially since there's no actual meaningful data flowing yet, only the 'enable' input to the beginning of a chain of message boxes within any subVI, ending with the 'OK' output from a final message box at the end of that subVI. I don't understand exactly what to do with the connector panes; I wish they were connectable to the block diagram, not things on the front panel! I just don't know how well LabView actually allows a person to achieve any procedural programming at all; all I've seen so far are mostly stand-alone routines that seem to suffice in simple cases. I can drive a 3 or 4 case structure from a 3 button dialog box with no problem, but I want to run a subVI by pressing a button on that box and have it behave as a pop-up front panel that then closes and returns to the 3 button dialog box after completion. I expect I'm over-complicating everything as usual due to lack of knowledge. If anyone can suggest how to structure the LabView code to achieve the above flow diagram, I'd be supremely grateful! Best regards and may your code always work, Matt Rhys-Roberts UK Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may contain privileged information. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system. Thank you. Information confidentielle: Le présent message, ainsi que tout fichier qui pourrait y être joint, sont envoyés à l'intention exclusive de son ou de ses destinataires; ils sont de nature confidentielle et peuvent constituer une information privilégiée. Nous avertissons toute personne autre que le destinataire prévu que tout examen, réacheminement, impression, copie, distribution ou autre utilisation de ce message et de tout fichier qui y est joint est strictement interdit. Si vous n'êtes pas le destinataire prévu, veuillez en aviser immédiatement l'expéditeur par retour de courriel et supprimer ce message et tout document joint de votre système. Merci.
Re: Request for suggestions on structuring!
At 1:38 PM +0100 4/2/04, [EMAIL PROTECTED] wrote: Dear Group, Please can you educate me, my brain's exploding here. I've been given a huge, old-style procedural flow diagram to code up in LabView 7, to create an automated test environment. (Thanks so far to Chris Harden for your help, but I'm still stuck on details.) See http://www.spherica.demon.co.uk/LabView/basic%20flowchart.gif Ok, here is a start at handling this as an event driven system. This can be either a simple event structure or look at the producer/consumer template for doing the same thing using a queue to pass commands from the user interface to the work loop. pop up a dialog box to get the file name and test data. This is just a sub-vi with the vi properties set to dialog. It just loops until an accept button is pressed and then passes the filename and test data to the main prog. initialize Then big event structure in a while loop with events for (A/B radio button), (C/D/E radio button), (F/G radio button) and a stop button. Start with A/B visible and enabled and the other 2 invisible. When A/B has value changed, use the new value to select a case to hide (or grey out and disable) the C/D/E radio button and unhide the F/G radio button and do calibration procedure 2 (or vice versa for the other case) also hide the A/B radio button. For the F/G radio button event use a case to select a call to process F or G in a loop, for each iteration ask to re-do? in a dialog box or make other test and decide to exit the loop. Store the file and return to the main event loop. For the stop button change event case send the new value of the stop button to the main while loop to terminate. -Scott -- - Dr. Scott Hannahs, Head of User Research Instrumentation - - http://sthmac.magnet.fsu.edu - - National High Magnetic Field Laboratory, Florida State University- - 1800 E. Paul Dirac Dr., Tallahassee FL 32310, (850)644-0216/FAX 644-0534 - Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to build bigger and better idiots. So far, the universe is winning. -- Robert Cringley (Triumph of the Nerds).
