crelf

Nicely done Stephen - thourough, and I especially appreciate your parallel to the gang of four patterns This document should definately become part of the LabVIEW documentation in the future. Now it's our job to further define the patterns that you've listed, and maybe come up with new ones where appropriate... I also like (and agree with) the "whole new flavor of

Oops - I gotta get better at reading my requirements / functional specification documents

Try this out: Download File:post-181-1156544139.vi

I think I can see what's happening - LabVIEW is what's called a dataflow language - the data flows from one node to another. I can't run you code (still a whole of stuff missing, and I don't have the hardware anyway), but it looks like at least your lock-in amplifier is running, but then doesn't output the data (that's why you're not seeing any data). It's not really set up to be a subVI (like a subroutine) that does some work and returns some data, but rather a top level VI where you do everything (the hint is that it needs user interaction to work). Your top level vi (2in1) calls the lock-in amp vi as a subVI and waits for it to finish to get the data out. That's one very important facet of dataflow programming: the express vi that sets up your x-y graph won't operate until it has data at all of its inputs. You might want to spend a little time checking this out...

Crikey! I agree with Philippe and Dave - you gotta get someone in to help you out on those - they're a mess, and you'll spend more time trying to sort them out than it's worth. You can use some of the prototypes in the existing driver, but I'd be talking to someone to help you with a brand new driver...

Ouch! Looks like you're in a real bind. To try to answer you questions, there are a number of standard dirver models used in LabVIEW, and there are even more non-standard models, so without seeing the code, I'm really at a loos to be able to help out. The other big problem is that you're not a LabVIEW programmer - it's like giving a handful of phrases written in Italian to someone who has never spoken Italian before and expecting them to be able to carry on a conversation - it's not impossible, but it's much easier to hire a translator Maybe you could upload the drivers with a description of what you're trying to do - depending on the driver's state and the extent of your requirements, we might be able to help you further...

You VI couldn't be simpler, but you didn't include the 2 subVIs (modbus021.vi or lock-in amplifier.vi) or any of their sub VIs. My guess (and it's only a guess since I can't see the data) is that either of those VIs isn't returning anything. Put a probe on the wires coming out of those and let us know what the values are. Also, an XY graph is a graph of X values against Y values - the wires suggest that the subVIs give out only one number each and not 1 dimension arrays of values...

Please show us what you've tried and we'll try to help out.

The new edition now comes in volumes I'm waiting for NI to integrate the design drivers for one of these puppies: (reminds me of a great Mel Brooks movie (what am I talkin' about? They are all great!) I've edited my post to reflect the change (I can't beleive we missed this one before it went to print!)

From the G (LabVIEW) Software Engineering chapter of the Engineering Handbook 2nd Edition by Christopher G. Relf and Peter Badcock:

Link updated (again!!!)

From the blog:

:thumbup: I do! If you're not using it, take the one week challenge: read more here.

Geez Jim - can you make it anymore obvious?!? "What you talkin' about, fool?" with a Phd...

Sure - that may be so within a company or a particular engineering department, but applying a code naming convention across the industry is completely different. Apples and Oragnes - you're talking about a software useability feature at the user level, I'm talking about a programming nomeclature at the programmer level - completely different. I sure do, but only in a smaller context, as described above. For example, I don't think it's a good idea that we name all strictly type-def'd controls as "STDEF - name.ctl" - that might be fine in a particular project, or paritcular team, or particulay company, but I find it far too limiting to try to apply that to an industry.

Bugger - the forum added a http:// to the front of my mms:// I've fixed it now...

I don't agree - although several models for naming have been suggested in the past (eg: the VIE naming model), all of them have been met with luke warm acceptance. Are you suggesting the we all just get together and use a convention, or that LabVIEW forces you to use a convention. Either way, I'm against it. If you want to implement a standard anming convention in your own company then go for it, but I don't think it's appropriate to try to force others to use it.

On a similar note - gues where they're filming a whole bunch of movies these days since it's cheap? That's right: Australia and New Zealand. eg: The Matrix movies, the new StarWars movies, the new Superman movie, The Mission Impossible movies, the Lord of the Rings movies, etc... I guess it's a whole lot cheaper and that those countries don't have an "established" movie union so it can give the creative teams a bit more freedom? (and, of course, the wonderful natural backdrops that Australia and New Zealand provide )

It's not the rugged good looks, the unassuming smile, nor is it the deep voice or the fawn trousers - this is why the ladies The Captain!

Once you guys have got something up and running, don't forget to get it out there by using OpenG or the LAVAcr...

I've got to agree - I found that it was Windows searching and searching and searching, so the pinging was the best solution. It's actually pretty elegant - you can't get much lower down than a ping, so it's a neat and efficient method to see if a remote PC is accessable before really trying to do any work with it.

That's what I like to see - a little honesty on the list! Welcome to LAVA - as long as you follow the rules and ask questions in a smart way I'm sure we'll help you out the best we can

Nice find ned!

Which is hopefully going to be soon, right squashmeister99?

*shudder* A job I worked at a few years ago had 6 or 7 engineering staff write a test execution engine a lot like TestStand, but with *far* less functionality (c'mon - who can say they've never been tempted?) Sure, I learned a lot from the experience, but management's justification was that they'd already got the $ to employ us and could justify the $ to buy TestStand. Talk about short short sighted: it took us about 9 - 10 months, and the final product, although functional, was never really used: the office I was in closed and they laid all of us off I certainly hope that isn't the way your company is going That said, I think your best bet is to write it yourself. If you remember your high school math (integration and differentiation) it shouldn't be toooo hard. There a good explination here. Has anyone else here already done it and has an example to share?