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 he'd duplicated code in his program. We both agreed that as soon as we found ourselves duplicating then we'd make a subvi and use in it in both places. I actually advocate evolutionary design as a powerful process.

Anyway, I think all I'm saying is that talented developers can probably make good systems regardless of background/job title.

My overall opinion of Labview is that it's very good for rapid development and interfacing with hardware, but we've run into problems with handling large amounts of data. We've discovered some of the weaknesses of the platform. That said, I rate it over Visual Basic for the work I do by a large margin.

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 work being quite unpredictable.

Over the last few years I've developed an automated production and test machine that involves motion control, hardware interafces, USB connections, serial ports, user interface, data processing, logic, a database, configuration options etc. It's pretty involving and there's still more ideas to implement.

I recently had some conversations with fully paid up "software engineers" who had been tasked with converting the system to Csharp and was quite amused by their narrow minded take on our situation. They seemed to have no interest in how one of our machines worked or a desire to take an overall look to see how complex it might be. They also used the following words which I have never used myself: core system architecture, class diagram, use case model.

Do you think that Labview users would tend to be more hardware/practical system solution orientated?

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/maximised etc but I'm still not there.

I've read about windows z lists and "bringwindowtofront".

Is there some way I can get an automation reference to the windows z list or whatever? I can't find anything in the Excel application ActiveX options to force Excel to the front.