Black Pearl

My favorite comment about Joel was: "never take software advice from a bug tracking system salesman".

BDD - Bug Driven Developement

Felix

As mentioned before, the use of the property node is slower because of the 'thread swapping'. For some reasons, the UI thread is a single thread (no multicore/hyperthreading here) and thus poses a bottle neck. So you should always rarly use local variables and far less frequently the property nodes.

There are some cases where you need the property nodes though. If you are working with a cluster, you can read/write the value of a single (and even random) element of the cluster with the property node.

Also if you use other properties as well, you can assign the value, as the thread swapping already needs to take place.

Felix

Probably nothing in terms of functionality. In text languages using Interfaces is a lot like using classes and objects. Wrapping your Interface methods in a class would help give the user a consistent experience.

My idea would be to use a facade design pattern to allow the user to cast a class to an interface. So all classes would inherite from the interfacable class, which have a method CastAsInterface (and maybe more like GetInterfaces and the like, some of them private...). The cast interface would then return the facade vi (just encapsulating the calls on the class that are part of the interface declaration), which holds the the object in its private data (this allows per value designs, I hope).

I don't know if that really works, as I'm not yet into LVOOP.

Felix

Taking into account the general theory of relativity, the speed of software developement is reduced by the mass of hardware?

Felix

(Inital design effort) + (Inital developement effort) + (Code Maintanance costs) - (Time Saved by reusing)

Felix

I also go with Industrial Computers - apart from PCI - I rely on good old RS232. I would say, that is a bit the professional way of dealing with that issue (industrial computers have other advantages as well, but cost more I guess).

For hobby/low budget I would head for the USB devices (I think they also safe you some cabeling costs).

And another solution for the geeks: use an old PC with PCI, connect it via Ethernet to a modern PC. Have the DAQ part running on the old PC and fetch the Data from these small VIs via VI Server and do the analysis on the new one.

Felix

Well, your info that you do EMG is worth a lot. I just talked to a domain expert, so filtering is the standard way; but on debate (you loose information).

I think there is enough knownledge if you can disclose your information (give us data, give us shematics, photos...), otherwise you're stuckwith the book tip.

Between to 60 uV you give (I get 700uV on wikipedia about EMG) and the 180 mV TM disturbance are magnitudes to bridge.

Felix

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

A word of caution: Expect to make lots of mistakes designing your first several object models. They will be design mistakes, not implementation mistakes, so it will take more time to fix them. Be sure to give yourself extra time to deal with them. And try to resist the temptation to immediately rewrite your reuse library as classes.

Me: But the warning above really sounds important to me: Don't start OOPing your reusable library.

See, and now you lost me We have a bunch of OO stuff in our reuse library. What about OO means you shouldn't use it in a reuse 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

A true engineer would use duct tape!!!

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