James McAnanama

JeHoB, You need to use a local variable for the listbox. Just feed it an array of indices to highlight (if more than one highlighted, make sure your selection property is set for 1 or more). See example - one highlights one and only one, the other adds another to the selected bunch per iteration. Cheers, James Download File:post-365-1092684380.vi

What I want? What I want? What I really, really want? I would like a cross compiler for LV. That is, it would be nice to develop and build executables on a Win32 machine, but targeted for Linux or Mac and vice versa. :thumbup: :2cents: , James

It looks like you want to build an array in the loop and use the data logged in previous iterations. For persistent local storage, use a shift register. In the attached vi there are four arrays that are populated from a while loop that terminates after a set number of iterations. The first array is trivial - it is populated and autoindexed from the while loop. The second array is populated manually using a shift register and the "Insert into array" function. The third array again uses a shift register, but only populates the itself if 'i' is an even number. The final array uses two shift registers - one, is for local storage of the array (just like the above two arrays), but the second shift register stores previous values of 'i'. By right clicking on the shift register, you can add historical elements. So, the first shift register thingme on the right side of the loop is the last element stored, the next is the second last element, etc. As a result, you can keep track of variables from previous iterations. This last array only populates if the current value of 'i' is equal to the sum of the last two values (e.g. 1+2=3 - so 3 is a valid number). When the loop starts, it initializes all values. However, this is not necessary - you could make the vi reentrant and keep the value persistent for each call the this vi. Hope this helps. Cheers, James Download File:post-365-1092659541.vi

Okay. The problem is with your ini file - it can't find it or open it. Probe the input to the open config data vi (see attached image). Make sure your ini file has the same path and file name as shown in the probed results. It amuses me that LabView often blames the GPIB controller for misc errors - even if you have no GPIB devices or code. It is like NI has a great deal of contempt for the GPIB bus! :laugh: The test still attempts to work, but with default values (that's why you get more errors as it tries to access the ini file, but ultimately runs the test). I should have added some more error handling around the ini access to allow it to fail gracefully. Next time... :clock:

hmmm... I am not sure why it doesn't work. Make sure the ini file is saved as SerialParams.ini and not SerialParams.ini.txt and that it is in the same directory as the llb.

Here's the ini file... OK, never mind... I can't upload an ini. So, you will have to resave this file as SerialParams.ini Download File:post-365-1092325393.txt

Thanks Michael. Sarah, I agree with Michael - you can simplify your code. I have taken a crack at it (and improved some of my own code at the same time ) From what I interpreted from your code, you are trying to make a serial comms tester. You want the ability to test the transmission (TX) from one comm port to a series of receiving (RX) comm ports. When you run the attached program, it waits for you to specify which comm ports are to be tested in TX, and which comm ports will be tested in RX. Each TX port will try to write to each RX port (i.e. if you specify COMM1 in the TX array, COMM1 and COMM2 in the RX array, then the program will try to write from COMM1 to COMM1 and from COMM1 to COMM2. The results of each test are displayed (see attached .jpg file for screen shot). The actual COMM tests are done using the same sub routine. This subroutine takes the serial settings from an .ini file (ex baud etc). The purpose of this example is the show programming considerations with abstraction, loose coupling, and good cohesion. (A topic that I am still learning myself, so don't expect perfection! ) If this were an application that I were using, I would go further to move all parametric data to a MySQL database and get rid of the .ini text file. Further, I would add routines to pull "test recipes" from the same MySQL DB - The UI would have a drop down showing the available test recipes, and the user would either select the desired test, or the program would sequence through them. Finally, the test results would be stored back to the DB. Make sure that the ini file is in the same directory as the .llb. Cheers, :beer: James Download File:post-365-1092325016.llb

We build commercial printing equipment. We use LV and LabWindows CVI for our custom production and test equipment - machine vision, laser gauges, paste dispensing etc. and to monitor our waste water tx plants.

LV has many built in examples - check out "Help> Find Examples" in the LV IDE. In terms of programming patterns, I would recommend Conway and Watts, "A Software Engineering Approach to LabVIEW" ISBN:0130093653. You may want to look at old presentations from the the LAVA user groups (that's where I found a reference to the above book - from a presentation given by some guy named Michael Aivaliotis).

No, I don't think it is possible to get events from an idle vi such as a "RUN" command button. :2cents: That being said, I think there is a general belief that you should not use the Run button for a deployed VI. Instead, the top level vi should run when opened (right click icon on top right of vi, select vi properties, then select the Execution category and click the "Run when opened" box.

:clock: I am still using LV7.0 & 6.1 - I can't open your vi. Do you mind saving it as 7.0? File>Save with Options> Click radio button on left "Save for Previous", then specify LabView Version 7.0 or 6.1.

Skywalkerxp, Right click on y-axis, and select "Duplicate Scale" - this gives you two scales on the left of the graph. Now right click one scale and select "Swap Sides" - this moves one scale to right side of the graph. Next, right click on any series in the legend, then select "Y-Scale", then specify the scale to which you want to map this data. See attached - two series, on two scales. Cheers, James Download File:post-365-1091890145.vi

I am not sure if I understand your problem correctly. It appears to me that your user interface is too large for the screen? If this is the case, you may want to try using tab controls to show only relevant portions of your UI at the desired times. (Tab controls are located under the "Array and Cluster" pallet).

Right click on the button, select "Mechanical Action", and specify "Switch until released"

It doesn't look like you will get faster than the 45 ms delay you are seeing from the 6060B. In addition, if you are looking for features in the 60Hz bandwidth from the fuel cell, you will need to sample at >=120Hz to avoid aliasing. One solution might be to use either a NI DMM (http://sine.ni.com/apps/we/nioc.vp?cid=12683〈=US) or a DAQ card to probe your circuit. I use DAQs, but haven't used their DMMs yet. However, from the NI website, NI PCI-4070 FlexDMM is specified to sample 6

I took a look at the programming guide and product manual from your link... Unfortunately, it doesn't look like there is any way to buffer the data. However, there may be another way around it. -Can you describe your application? -What is it you are trying to capture at 60Hz? -Can you use a DAQ card to measure your parameter elsewhere in the system? (e.g. voltage drop at the DUT etc).

Does the instrument have the ability to log a series of measurements and then transfer the lot periodically over the GPIB bus (log 50 readings and tx these 50 every sec)? Alternatively, does the instrument have an analogue out? Can you control it using the GPIB bus, but grab the output over the analogue port in real time? (I don't mean to offend you with obvious questions - these are just some ways we have overcome slow GPIB readings with Keithley and Agilent equipment).

Oh. But what he is using must be some legacy wrapper(?) - you still can't pop-up on a terminal and create an enum constant. I don't like remembering if COM1 is port 0 or port 1. Yeah, my best code will probably always be the next bit I write -especially if it is after an Ontario LAVA user group meeting... :worship: Do you have any suggestions for handling timing at the serial port - is there a way to generate an interrupt for data received etc?

Quixote, Your code works if you have identical settings for each port (and you have followed Didier's advice on cabling). Make sure you hit enter at the end of your "String to Write" - your serial read wants this \n as a termination. If I can make some suggestions: 1. Consider using the VISA Serial routines as they have the following benefits: -VISA routines provide a common interface to serial, GPIB, and VXI, so learning one helps if you use one of the other buses. -VISA routines give you enum inputs so you can select "COM1", "COM2" instead of 0,1. 2. Consider using a state machine approach to your design to better control the flow of data through the serial port - without hardware flow control, the data can arrive at the destination port in a nondeterministic way. As a result, you may "miss" the data at the buffer. Using timing delays may work, but can fall apart if you upgrade to a faster PC etc. I have attached my crack at it - the machine initiates itself when it is first launched. Then is sits doing nothing until you hit the GO button. At which time it writes to the serial port you specify, and then reads from the destination serial port. Then, it sits "Doing nothing" unless more data shows up at the destination serial port or you hit go or stop. If you like this style, consider getting Conway and Watts, "A Software Engineering Approach to LabVIEW". (further influence from that Michael Aivaliotis guy...) 3. If you are looking for other examples, check out those that come with LabVIEW - click, HELP, FIND EXAMPLES, and the search through the resulting dialogue. Cheers, James Download File:post-365-1090505063.vi

You should find LabVIEW well suited to your application. We use LavVIEW in our factory for many things from parts testing, to monitoring the pH from our water treatment plant. I like its flexibility and tight integration with NI hardware. Further, NI has done a good job of keeping their code backward compatible. We have some code that was originally written for LV2.0 on a Mac, now running on a PC, LV 6.0 (we had to upgrade through different versions along the way, but it was fairly straight forward). That is, in my opinion, LabVIEW is a good choice for systems that will have a long life cycle with the possibility of upgrades.

Padma, You require the application builder for LabView to compile code. What you have is the run time engine - this is what you install on machines that are to run your compiled code. Cheers, James