tomstickland

I just found this discussion I'd started via Google! My opinions haven't changed much. We can bandy words around, but nothing really compensates for imagination and ability by the developers. Our system is very modular, because I tend to develop things in blocks. This is so changes can be made in the future with ease. I tend to break VI's up once they threaten to take up more than a screen, or maybe 1.5 screens at max. I had an interesting conversation with another Labview user at work last week. He'd taken a look at a program developed by a "proper software engineer" type and found that h

This is interesting. I'm a mechanical engineer who's spent the best part of 10 years working on software. First with Matlab and Pascal, then Excel Visual Basic, then proper Visual Basic , then Labview and some C for DSP chips. In that time I've made countless working applications that do what they're supposed to do, eradicated bugs and generally worked with other end users to make systems that are fast and easy to use. Most of the code has evolved or I've thought about how to do things on the drive to work or lying in bed at night. Some of it has been pretty involving, what with development w

I'd set an array of acceptable patterns and a for loop with a "match reg expression" search function in it, with a boolean shift register and an OR gate.

Hi, first time post here. I've been using Labview for around 6 years now for production and test machine automation and think it's pretty good. I've recently made a vi that turns opens Excel and makes an identical copy of a Labview xy chart so I can print it out or save it etc. I've got it all working after a lot of trial and error, courtesy of the rather random Excel VBA structures. My last problem is in making the Excel window the front window. I've tried every variation I can think of in terms of minimising/hiding the Labview window and making the Excel window/chart/application activated/