Black Pearl

I would go for TCP as well. Did a good job for me in the past. All you miss is a good determinism (but what's 2 ms for a human?). You can catch a lot of errors generated by the OS (?) and even get a great stack for free (handled by the OS as well). And that's tested every time you go over and visit LAVA, that TCP is doing a good job. Seems like waterproof. Felix

Some tests I'd do: * Switch of the TM and look at your measurement signal. * Power on (line frequency!) the TM but keep it halted. And always a good thing: Proper grounding! Mainly I think that one of the inputs of the preamp should be tied to ground... Felix

Me: But the warning above really sounds important to me: Don't start OOPing your reusable library. I was refering to post above. Focus is on OOP beginner. I do (will do/should do) my reusable.lib with 'stable'(I know how to design) stuff. Well, now that the original poster is not needing this thread any more (and ist Lava Lounge), I hijack it and tell you my story of insight. I am stuck at LV 7.1. so no OOP for ages. Got some student version, so I could do some in my private life, but why? So what I could do is to look at the abstract ideas of OOP (I did some amateur OOP with Java and delphi), read the Go4 book (ages ago) and went to wikipedia (for the Go4 patterns). And then took a time what to do without OOP, no, definitfely how to get their benifits to go into a non-OOP world. It actually is an amazing insight on the complete idea, because you are stuck or blessed with beiing able to not OOP. As I said above, the biggest issue of reproducing OOP code (yes, I unsuccessfully tried coding) is that you miss inheritance. (This is very focused on the enum of an AE). And OOP languages are still not decided on how to finish this issue: multiple inheritance, interfaces. Next point (solvable): text languages treat objects by ref (and LVOOP by val). I can do some of it by plain (non-OOP) LV. But it is not native of our wire logic (by val!). And that in case make it difficult to understand e.g. the Go4 Patterns of eg. Abstract Factory. And now comes the big important point: When/if I do OOP, hopw many Patterns I need? Felix

I don't think it is essential. The thing that is essential (for large app's) is encapsulation. We can achieve this by other design concepts, such as Action Engines. The most important concept of OOP that I don't see a solution without OOP is inhertance. And this concept gives you a whole new way of creating reusable code (There was a great reply by Ben on NI forum about it). And this would be my path of learning OOP, treat it as the glorified cluster and try to get a more reusable code from it. But the warning above really sounds important to me: Don't start OOPing your reusable library. Felix

All these must read books lead me to think, that OOP gives your software a lot of overhead. Not the code, but the design. Felix

Thanks Darren. It seems to be released in 8.0 and I was using 7.1 Felix

I have some code that has terminals with 'View as icon' set. I tried to find a property indicating that, so I could hunt them down. Ideally, I would like to write a small scripting tool that unchecks the 'View as Icon' property on every terminal. Felix

Name: Switch of Autoplay Submitter: Black Pearl Submitted: 03 Sep 2009 File Updated: 03 Jan 2011 Category: *Uncertified* LabVIEW Version: 7.1 License Type: Creative Commons Attribution 3.0 This VI accesses the registry and changes the Key that is responsible for Autoplay (WinXP). This should help against those worms/viruses that spread via USB Disks. Click here to download this file

There is an optin: 'Do not save automatic changes'. That might help. Felix

Scripting and wine, that is fine... Well, when I have some spare time (or just want to code G and no other work), I work on my reusable lib or some tools (which sometimes need private properties, not real scripting for now). Felix

You use some of your own time? Then do scripting. It's cool and geeky. Own some reputation for writing some JKI RCF plugin. Go for the self replicating code challenge. LVOOP is just a 'glorified cluster'. But how many 'Application Instance' are there? Non-pw protected vi's in the vi.lib? If you can take some time off, then 'waste' it for the crazy stuff. Someone will sone enough ask you to do the OOP. Get the geek bonus by writing your scripting VI to UML-draft the accessor VIs. Felix

People did so in the past on the NI forum. They got comments. You might want to search for these debates. My opinion: If you want to get precise and short answers, post on LAVA. If you want to debate everything more into detail, head to NI. The folks here are mostly on NI as well... Felix

In LV 7.1 I have an invoke node for the VI called 'Get Panel Image'. Felix

No way. If you need to botch (correct english?), at least nobody should see it at first. Spray paint it in RAL 7035 (this is a german standard for colors and 'lichtgrau' is widely used for machines) -> german wikipedia. Much nerdier even: Get some LEDs that blink from time-to-time like everyone knows from a network hub. Of course only the green LEDs blink, never the red ones. Felix

Once I had to deliver a machine really 'in-time' because it was a prototype for an expo. The machine was shipped before I could completly access and test the functionality, so I was travelling alongside. Overworked, of course! That night I woke up about almost every two hours with some nightmares about what could happend during transportation that completly would wreck the show. And then I had to get it running the next day... Felix

My thinking on that: When using a state machine, that particular VI should show everything that is related to the state machine bahaviour. Other code might be shown (inlined) if it is easy to catch (otherwise, a SubVI Icon might be better to document the code). Here is my way of coding state machines: * (Next)State has a distinct wire. The selection of the next state might come from a SubVI, but the actual selection is done in the state machine VI. For example a SubVi might have a boolean output 'Abort'. * Error has a distinct wire. Most of the time I check each iteration of the while loop for an error and go to the error handling case. * Data is 1 or 2 clusters. Most of the time I distiquish between 'Parameters' for Scalar Data and 'Data' for Array Data * Other values that are constant inside this VI ('Recipe', 'Measurement Settings', References of various kind like File, Instruments) -> they don't need the shift register. I'm for sure in one of those chaotic/'agile' environments where nobody pays you for doing any internal documentation of your code AND the requirements are changed any and every time you talk with customers. But I always document state machines if they go beyond a basic set of about 5 states (that's what I use for a simple dialog that saves settings when the user presses o.k. and else terminates without saving). For the documentaion I'm fine with simple 'Bubble-and-arrow' (Check the NI infomercials/'webcasts' on their state-something tools if you're infamiliar with it) using Powerpoint or OpenOffice Draw. If I'm in a good mind, I will copy-paste it on the BD. Seldom, I use the uml syntax where the 'decisions' have their own diamond representation. This is mainly done when I need to deal with external/non-LV software engineers. They main issue about documenting it, whenever the wind of change comes whirling, I exactly see which transitions I need to alter. Just to repeat, I'd put everything that makes the SM a SM in that top level SM.vi. All state tranisitions and the overall picture of which states might lead to which states. Felix

I do it with mantis (there is not much of a difference) and if you just need to track who is going to take care about it and who did implement/fix it, then a bug tracker is doing the job. For mantis, I have a SQL database behind that takes note of every change, so preserving the history of each 'bug'. I propably was the virtual person (vp) that braught it up on the NI forum, but it was introduced to me on LAVA on this thread Felix

Hey Jim, that is brilliant. If you would publish it for the community and in a version I could use, I would start using it and doing my part of improving it. Well, as soon as I find time... Felix

Although that guy is not knowing about LV at all, I would vote for him http://www.tesladownunder.com/ or anyone that scripts wires to trash cans with 40 kA? Felix

Just some more for the wish list: Remove Bugs, Remove boss, remove customers, pay bill, let me go on holidays... Felix

A project (LV project window)= a project (eg. getting that ATE running). That is more than a bunch of files. If it is just for organizing files, then please call it file organizer. Felix

Sort of. I really like the defect tracker because it allows you to generate a pile of paper for the next meeting in a few minutes. Give's you more time coding - ehm - defect trackers

I usually just fill a report in my defect tracker. Later on I will close the 'bug' with status 'will not be solved'. Felix

Wouldn't it possible to automate this by scripting? Create a new vi and place the vi from vi.lib on the BD. Get the copane of the vi.lib.vi and assigne the same for the wrapper vi. Then Create all Controls/Indicators, wire them and place them on the copane. Copy the Icon and documantation. ... Do this with evrey vi in vi.lib The next morning your PC will be done with it and you just need to look through what you got. Felix As a side note: Once I was in a hackers mood and did a scan for all non-password protected vi's in the LabVIEW dir (so not only vi.lib). Took some hours and the list is still lurking around somewhere (I didn't find the time to evaluate what treasurs I might have found)...