ShaunR

Allright I voted, however I think that NI should not only implement the easy ideas from the Idea Exchange.

Basically all the ideas implemented are 'low hanging fruit', I would be ashamed to name those new 'changes' as the major upgrade feature (as NI is currently doing).

Ton

Oh, I don't know. I think some of the changes are really useful (like clusters as control-type icons). But they all seem to be cosmetic changes. So whilst I like the idea of a cleaner diagram, I would (as I think you are suggesting) prefer to see the more meaty ones implemented that enhance the program rather than the prettiness of the diagram.

Or maybe that's a sign in itself. That we are having to spend too much time making diagrams "look" good instead of making functional code.

But I think Aristos' suggestion is an excellent one (and long overdue). I use it a lot and it would save be bags of time.

I'm in the same boat as jgcode so I'll have to create 3 more accounts and hire a medium

Having slept on it (after all wise words from NI are never to be taken lightly). I thought I'd better to refresh my memory.

Unfortunately I seem to have remembered correctly (what? No crying emoticon?) as this works as I would expect

However, Plot color isn't available, yet it is still common to all plots.

Which brings me back to the summation that you have really highlighted a problem of inconsistency of the property node for waveform types since this also works.

So. You don't have to create a case for every class and subclass. Only the parent (if at all). Apart from some properties of waveforms (there maybe others but waveforms are the only one I've come across).

I think NI should offer a discount to female attendees.

Naaaah. I think they should supply them

Functionally I don't think it's any different, but there's a HUGE difference in readability.

Really? Its easier to read 0,1,2,3... than WaveFormGraph, WaveformChart, XYGraph... ?

(Personally I really dislike nested case structures. The logic is too hard to understand at a glance. If I can I'll usually execute all the logic tests, put the results in a boolean array, convert it to a number, and wire that into the case structure. Then I drop a comment explaining the logic. It's much easier for me to check the code that way.)

I find nested case structures abhorrent. I must admit I didn't even consider the nested error example a solution Even a case structure with many cases causes me to look for an for an alternative. Its the same argument as Sequence Structures. If the case number is small (<6), I'd much rather use a select so its all out in the open. For more then I will try for strings unless its numerical in nature in which case I will do the same as you.

Oh, and without going back and watching the videos again, what was the first word Norm said on all four of the videos?

ummmm. "So"?

You did not see what happened with the XY graph did you?

Thought I did

You would have to account for EVERY possible child string.

EVERY CLASS NAME.

If you had some VI that had a GObject come into it's terminal,

you would need to manually enter the 'Class Name' for EVERY Class Name of EVERY child class that you wanted to handle.

You mean the difference is that instead typing in the class name you wanted to handle you, would just "Copy Case" and change the cast constant instead?

If GObject was the input and you wanted to do a bunch of operations on all, or even a subset, of numerics types,

you would have to figure out every class name possible,

and then type it in perfectly in the case selector,

and then hope and pray that NI doesn't release another item in the GObject tree that now your code won't work with.

Not really. Because unlike graphs the a property node accepts all the numeric classes for the common properties.

It's all about Scalability, robustness & re-usability. You do not get that w/ the string

Certainly waveformchart,waveformgraph and xygraph don't have child classes. Neither do boolean, cluster etc

Numeric types are consistent (whether they be a U16, DBL, slider, knob,gauge or whatever) since all the common properties can be wired to the same property node. The graphs, however (I think) are the exception and it is only because the property node doesn't allow it (which it should) means that you have to handle them differently. I found that out when writing PassaMak.

Hmmm.

I don't really see he difference between your using the class name "problem" example and using an iterative apart from the class name has a descriptive case name and the iterative "trial and error" just has 0,1,2 etc. You still have to have a case to handle the particular type to do the correct cast but with the iterative approach you have to try all the previous ones first before deciding its not supported. With the class name its either supported or not.

Is there another benefit I'm missing?

So all we're talking about here is having the hooks added and possibly Darren's code or ours should we choose, right?

If you code monkeys force me to 4224 instead of 5335 and tag .ctl or .lvclass on the end of all of my controls more than you already do, I'm going to take my pikachu down to the 3rd floor and demonstrate some hand to hand knife fighting moves on him.

http://twitpic.com/2c6s2s

Don't forget all the documentation

Add this line to the labview.ini file in your labview folder:

disableMenuEffects=True

Or if an entry already exists; change it to True.

Then restart labview

Hi Shaun,

It was definitely financial reasons that I chose the 12v dc pump (I bought it on ebay for 20euro:P)! Otherwise I probably would have tried to get a 3 phase or something like that.

Anyways, as it turns out I'm finished - I had my project presentation Wedsnesday afternoon. It went very well - I got the PID & PWM working, thanks to the help of my project supervisor during the presentation (it was a pretty informal affair!). I wasn't far off, thanks to all the information from you and this site but it was just putting it all together in labview where I fell down. We ended up using a simulate signal block for the PWM. We installed this 1st into my basic program with just the input driving the output, and put a control on the duty cycle to set our pulses, and also set the samples per second, offset, frequency. We then managed to wire in the simple PID subvi, and it was just a matter of trial and error with the PID values. In the end, when a setpoint was entered it held very well going by the double needle meter, and the PID response was quite good. This could have probably been bettered but I was happy enough to get as far as I did with this. You probably think that I have a softie for a supervisor;) but I think he saw that I had all the pieces of the puzzle, just not in the right order!! Thanks again anyways Shaun - I have posted the working vi just in case you were intrigued how I got on. I'm sure it's pretty simple to you:worshippy:.

P.s - Taking a break from Labview for a while. My results are out Monday. That will be level 7 complete(pass degree or diploma), but I will probably be back to this site when I attempt level 8 of the course...

Take it easy,

Rich

Glad to hear it. Congrats. Always easier when someone is sitting in front of you (that knows the exam answers )

I noticed wired up the duty cycle to the simulator

So then what is reinterpretation? And why does reinterpreting require a temp buffer, and transformations do not?

Well. I would tentatively suggest the others are reinterpretation (dbl to uint64 is reinterpreting the bits to form an equivalent value).

Why does it need a buffer? Don't know Implementation specifics that I'm glad I don't have to worry about. But I would guess a temporary buffer may be required as an intermediate step in the conversion process since the new type cannot be represented by a union (c terminology) of the memory locations unlike a transformation..

And before you ask I still have no idea no idea what 4.x data is either other than a vague recollection that it was something to do with a change in internal representation between LV versions some time ago..

where's Rolf when ya need him

I would classify this as a transformation.

Dude - where were you yesterday when I spent all day mangling c# code to produce a .net assembly that would set timeadjustment priviledges.

Nice, library though...thanks for sharing.

Probably posting on here

Glad there was something useful.

Good question.

The Player is (was) actually more complicated than I need. I don't have to be able to run the code, just look at it.

Because it is all about me, after all.

Well, you were the OP.

Just remember. "There's no I in team". But there is a "ME" and no U

Name: Windows API

Submitter: ShaunR

Submitted: 09 Sep 2010

File Updated: 03 Jan 2011

Category: General

LabVIEW Version: 2009

License Type: Other (included with download)

Windows API Utilities.

An eclectic set of wrapper VIs around some windows API functions.

I wrote these many years ago (1998? wow!) but have used them to some extent in virtually all my windows programs.

I've included all the original functions (accidentally re-compiled under LV 9.0) and just wrapped them up in a project and added the LAVA required stuff so your getting them "warts 'n all".

Many functions have been superseded by LabView functions and I expect many people already have their own.

But there are still some gems I couldn't do without and maybe someone will find them useful.

Installation:

Unzip to a directory of your choice.

Required Packages:

Labview 9.0 or greater

Windows XP or greater (may work on earlier versions)

Known Issues.

None.

Versioning:

Current version 1.0.

Contact: PM ShaunR on lavag.org (http://www.lavag.org)

Click here to download this file

I wonder why NI pulled the LabView Player? That would have solved Cats code review problems at least.

Fantastic.

Very talented guy. But a very expensive way to record a song

Once again in the minority. Its good to be back

Sorry Shaun, but I also totally disagree with you on this. The Scripting Tools are something that will be of use to ALL LabVIEW developers and I strongly encourage all developers to play with them and not be afraid of them.

Afraid? Hardly (that's almost funny ).

Surly we ALL develop "Tools", in some way, they are the things that on a daily basis make our job of developing a "Product" easier, quicker and in many cases more reliable.

Can't argue with that

When I programmed in C and Perl on Unix I used things like 'grep' and 'awk' and other stuff all the time, I wrote my own scripts that used these basic Unix commands to do things for me that (as I said above) were quicker and more reliable than I could do by hand. Most people who write in text based languages are totally familiar with the concept of knocking up a little script to do some regular task in an automated manor, that is what being a programmer is about.

I think you mean most people that program in Linux or Unix. When I write text programs in windows and I need a quick "tool" I write something in LabView On the rare occasions I am required to do something in Linux, I probaly still wouldn't use those utilities for task automation unless there was no other way. On windows the analogy would be using the cmd.exe do tasks which I think (personally) is a bit icky, But I recognise it is a standard method on Linux/Unix.. Now pearl I would use to write a script to automate a task after all it is a "scripting" language (if only i could understand my own code 3 weeks later ).

I use LabVIEW to create Production Test Software that we use in manufacturing to test our products. However I use scripting in a number of different ways, I using scripting to help so that I can automatically create LabVIEW executable builds,

I find the project manager is sufficient. Although perhaps you could elaborate?

I use scripting to help auto-generate and populate a LabVIEW function Global we use. This reads some specification files our product engineers generate. I could use scripting to help auto-generate some documentation of our system,

Hmmm. One of the areas I definitely wouldn't use scripting is data population. I would prefer a run-time solution so that I only have to replace the document not re-hash/re-compile my code every time there is a spec change..

We have a similar implementation where the design engineers create a spec, which I deploy as part of the distribution and is parsed by the software. The document comes under document control and i've offloaded the responsibility of keeping it up to date onto a technician.

As for system documentation. Shouldn't this be generated from the requirements spec?

the list of possible uses is endless.

Maybe so. But my time and budget aren't. There has to be a very strong reason for doing something that is not easily equatable to tangible benefit (damned accountants ). Should I spend 2 days writing a script that can only be used to make my life as a programmer easier? Or should I spend that time to write a piece of code, that I can deposit on the clients site,and means I save travelling expenses, board/logging and corporate face?. If it was deployable I could do both Tool developers don't have this dilemma since they can monetise scripting directly.

The LabVIEW IDE can not be deployed but I still find it very useful

Dannyt

Perhaps we should start another thread since we are now way off topic. Or maybe we're getting to the point where there we just admit there are 2 camps (ok one of them isn't really a camp, more of a sole resident )

Hi,

I know what you mean with the shift register. However, I couldnt realize it that way.

But I have found another solution for this problem, which is attached below.

If you have time you could edit my VI with your solution and post it crossrulz.

Thank you for your reply!

What crossrulz. means (I think) is that events are more efficient for user selection than a state machine. Assuming that the goal is to make a selection based on user input.

Although it is not a state machine in the classical sense, since the the next state is not dictated by the previous one.

Note that I have changed the mechanical action of the booleans too.

I have to disagree with this. I only create product and have used scripting to do things I could not otherwise do. For example, in LV2010, you can now run a VI before and after you do a build (of anything). Well, since NI decided to not include a version number in a built LabVIEW Web Service, I added a function to my web service that returns my own version number. And, I created a VI that will (using scripting) increment the value that function returns. I then call this VI everytime I build the web service. Thus, I have used scripting to create an auto incrementing version number in something that had no version information at all before. This is very important in LV2010, since you can create a project that does not build any EXE but instead builds a web service and an installer to deploy it on a target.

I am sure that over time we will find even more ways to add a little scripting into our code to help us build better deployable product. Just need to think a little outside the box (or sequence structure, in LV terms ).

-John

I'm sure (as we've seen) people that create product will use scripting (the same way that a programmer will use more memory if more is available). But as it cannot be deployed it remains a feature that I (not being a tool developer) could have, quite happily, lived without . Tool developers, however, love it to death because it is the only way they can exist. It has opened up a 3rd party business where previously there was none and, previously, non-NI add-ons and tools were petty much free (this being a cultural change rather than a technological one) .I just find it really hard to get excited about scripting:P

I can't comment on your LV 2010 (or indeed web-services) only to say that in LV2009 an executable, DLL, and .NETs build number is included and indexable and maybe the lack of one on a web service is an oversight that should have been reported. But you didn't need scripting to do that,. The useful feature (and I do think this is really useful AND in benefits all of us) is the additionof the pre and post vi's without wihich, even scripting couldn't help and you would have had to use your previous method (which was probably a vi you run after the build, manually)

But it just seems to me like this is a common enough UI issue that there should be a universal way to deal with it.

I think that depends on your point of view. I have used "lazy" instruments before.But generally my design philosophy involves hardware several layers below the user interface, modularised and loosely coupled. This enables me (amongst other things) to bolt on different user interfaces to the same back-end Peculiarities of a device are handled by the modules and/or driver. I re-use many of the modules and wouldn't want to keep putting instrument specific code in to the user interface.

I'm in the midst of writing code to use scripting to crawl thru huge C header files and create LabVIEW clusters out of all the structures. (If I ever get time to finish it) This will save me loads of time every time those C header files get changed.

Why do you need to do that? Are you porting to LV?

Aussies: Believe you should look out for your mates.

Brits: Believe that you should look out for those people who belong to your club.

Americans: Believe that people should look out for and take care of themselves.

Canadians: Believe that that is the government's job.

Aussies: Dislike being mistaken for Pommies (Brits) when abroad.

Canadians: Are rather indignant about being mistaken for Americans when abroad.

Americans: Encourage being mistaken for Canadians when abroad.

Brits: Can't possibly be mistaken for anyone else when abroad.

Canadians: Endure bitterly cold winters and are proud of it.

Brits: Endure oppressively wet and dreary winters and are proud of it.

Americans: Don't have to do either, and couldn't care less.

Aussies: Don't understand what inclement weather means.

Americans: Drink weak, pissy-tasting beer.

Canadians: Drink strong, pissy-tasting beer.

Brits: Drink warm, beery-tasting piss.

Aussies: Drink anything with alcohol in it.

Americans: Seem to think that poverty and failure are morally suspect.

Canadians: Seem to believe that wealth and success are morally suspect.

Brits: Seem to believe that wealth, poverty, success, and failure are inherited.

Aussies: Seem to think that none of this matters after several beers.

Brits: Have produced many great comedians, celebrated by Canadians, ignored by Americans, and therefore not rich.

Aussies: Have produced comedians like Paul Hogan and Yahoo Serious.

Canadians: Have produced many great comedians such as John Candy, Martin Short, Jim Carrey, Dan Akroyd, and all the rest at SCTV.

Americans: Think that these people are American!

Americans: Spend most of their lives glued to the idiot box.

Canadians: Don't, but only because they can't get more American channels.

Brits: Pay a tax just so they can watch 4 channels.

Aussies: Export all their crappy programs, which no one there watches, to Britain, where everybody loves them.

Americans: Will jabber on incessantly about football, baseball and basketball.

Brits: Will jabber on incessantly about cricket, soccer and rugby.

Canadians: Will jabber on incessantly about hockey, hockey, hockey, and how they beat the Americans twice, playing baseball.

Aussies: Will jabber on incessantly about how they beat the Poms in every sport they played them in.

Aussies: Are extremely patriotic about their beer.

Americans: Are flag-waving, anthem-singing, and obsessively patriotic to the point of blindness.

Canadians: Can't agree on the words to their anthem, in either language, when they can be bothered to sing them.

Brits: Do not sing at all but prefer a large brass band to perform the anthem.

Brits: Are justifiably proud of the accomplishments of their past citizens.

Americans: Are justifiably proud of the accomplishments of their present citizens.

Canadians: Prattle on about how some of those great Americans were once Canadian.

Aussies: Waffle on about how some of their past citizens were once Outlaw Pommies, but none of that matters after several beers.

Personally, I think that XNodes could be the next big thing we push NI to release officially. I mean, look what we did for scripting. We could start by creating more examples that use XNodes, and maybe clean up the documentation a little on the LabVIEWwiki. Anyone with me?

What did it do for scripting? Scripting is only useful for tool developers.

Those of us that create product have zero use for scripting. Except perhaps the occasional need to automate a few tedious tasks if we find ourselves in a lax minute or 2..

OK just re-read you post...lol. Missed the "we" bit . Yes "you" (as in tool developers) did get it published by NI, but my original point still stands.

In fact. thinking about it..... You don't even need the replace element.

In this case, it would only be a matter of time before a user changes the control, then forgets to push the go button. Then I'm getting a late night phone call wondering why the furnace was set to 210C is only running at 200C.

And your reply is that they shouldn't be using un-trained operators

But I see what your after.

I think you will just have to filter the changes. Although I had a quick look at the slider example you referenced and I certainly wouldn't have done it that way

One thing you could do is build an array of the controls that are clicked and the latest value for that control and put that in the on change event case (the same on-change would be used for all controls). You would need to look up the control reference on each click and if it doesn't exist, add it. This is fairly trivial. Then, in the time-out case (set it to a few seconds for example) unwind the array using a for loop and read the control(s) that have changed and send the value to the the instrument(s). If nothing has been clicked, then the for loop won't execute when the time out expires. If some controls have been clicked (the timeout will be reset every click automagicaly) , then they will have an entry and the for loop will iterate through them.

Well. That's one way at least.

You could also use Cats previous method and start a timer when the user clicks on a control. Then, if the timer times-out,, activate a really annoying sounder (add flashing lights too) and a dialogue box saying "Press The GO Button Idiot". Finally, send an e-mail to the logged in users supervisor telling him that the operator needs scheduling for re-training as he cannot follow simple on screen instructions.

I guarantee you will only be called out once late at night

It's a bit like asking "what's a LabView Wire" equivalent in C/C++