ShaunR

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++

ActiveX is a monster ....... why settle for such a crippled beast?

Amen!

HI Cat. Hows tricks?

Let's say the value is 10, and the user clicks the increment button 30 times. I'd like the user to see the control change to 11,12, 13.... so there is visual feedback that the clicks are working. However, only when the user stops clicking at 40, and doesn't click the control again for 1 second or so, then an event is generated that sends the value of 40 to an instrument.

If I understand correctly (which is quite rare) could you use the "mouse leave"event case so that your "send to instrument" function only fires when they move outside the control (i.e stopped clicking and gone elsewhere).

The advantage of that is you can attach all your controls to a single event case and use the events control ref to wheedle out the control and value.

Hi Shaun,

I'm sorry, my submission deadline is soon enough, so I've been a bit naive with this expecting everything to fall into place in a short space of time... That's not going happen...

My pump is just on-off, 12v dc. An analogue controlled pump would probably have been a sounder option, at least when working with labview. I realize that now...

I have the PID toolkit, so I'll have a look at the 'PID simulator' and the other examples like you said. I have attached the main program & sub vi's. I've also attached the basic program that I started off with(minus PID & PWM) & a manual PWM program that I was also trying to use... Thanks for all the help and I apologize if you thought that I'm trying to get you to do my project for me!! I'm just hoping to pass it when it comes down to the crunch...

Thanks again,

Rich

Sorry for the delay. Had my own projects that weren't falling and needed kicking into place

No need to apologise. I was just trying to let you know that you need to understand what you are doing

OK. So you have a 12 digitally controlled motor. That's your design decision Nothing wrong with that, after all we need to keep within budget don't we?

I'm assuming you have seen the NI PID Examples and seen that they get a lovely smooth control curve. Right?. Just change the sampling time from 50m to, say 500 m.

Does it still look like a nice well controlled curve? What do you see? Remember we haven't changed any PID parameters, or the load we are controlling. Just how often we sample the PV.

What do you think is happening here?

Hi Shaun,

Thanks a mil for all the help - I'd be lost without it:worshippy:! I've attached my vi with the PID & PWM subvi's added in. I'm sure that it'll be wrong somewhere but I'm going to try and tune the PID controller tomorrow and see can I get some sort of response... When it comes to the PID tuning, I spoke to my project supervisor from the college & he said that I would need to work out my values by the 'plant response' method...?

Leaving Ki & Kd at zero, he said to 1st get; Kc = % change in voltage shift of my output

% change in voltage shift of my input

He said that I then calculate the rise time of the slope Kr and the lag Kl. These values are then used in the ziegler nicolls formula to calculate my P, I & D... It sounds like an awfully complicated way of calculating the gains to me, but then again so does most associated with PID...! The 0-500 values on my front panel is just the range of response I got from my cistern arm(pot) from empty to full... Thanks again,

Richie

Hmmm.

I think maybe I have failed miserably to explain the key concepts.

The previous example was to show how you can add a very simple PWM (there is more than 1 type) to an on/off controller that controls a single digital output Cutting and pasting my example and wiring up controls with the same name won't cut it since you want to use a PID controller and not an on/off controller. I'm not doing your project for you, merely trying to show, with he use of examples, how to go about it. The example demonstrates how you can vary a digital output to react a a certain stimulus and since it was available, I used Neds on/off controller .

You could, for example, replace the PID VI in the NI example "PID simulator" with the vi I supplied, but you would still have to figure out a method of calculating the duty-cycle on each iteration in relation to the input (which you haven't). You could, however, replace it with Neds example (no mods needed) and see what the difference is to the PID one.

I would suggest taking the time to view all the PID examples shipped with the PID toolkit (assuming you have it) and understand the theory.

I would even be tempted to rip out the process simulator into another vi and use it to create the step response graph and log the results. Then do my ZN analysis on it to see if I came close to the ones in the example. Then change the process values and repeat.

From your project supervisors comment, I think he is expecting an analogue output (or a PWM simulation of an analogue voltage which isn't the type of PWM I used). Is the pump analogue controlled? If it is. What is the reason for using a digital output when your USB device has analogue outputs (And there are many tutorials on Youtube of PID with an analogue output. using LabView)

One further point. If your posting VIs that uses sub-vis. Can you put the all vis into a single directory and zip up the entire directory so that all the sub-vis are included. I don't have "On-Off Controller-PWM.vi" or "Simple PID- ViFormyproject.vi". I can guess at what they probably are but its always best to be looking at the same code.

Oppps.

Just noticed a feature (bug..it is the wee hours is my excuse) The over set-point check is inverted (sorry about that).

This is what it should be

Thanks everybody for all the help and advise:rolleyes:! I'm going to focus on trying to make my process work with one of two programs;

1 - My initial program with the on-off controller added in(cheers anon),

2 - An edited version of the FPGA PID PWM program(thanks for pointing that out Shaun).

I've run into a bit of a snag with wiring my DAQ assistant Ai/p and Do/p into the FPGA program... My analog input subbed in nicely into the PID loop, but in the PWM generation loop there are 2 terminals to wire into my digital output(direction bit & PWM output), where as I only have one digital output to generate on my DAQ assistant. Also, when I did try to wire up the DAQ assistant to one of the terminals it gives the error;

'2 terminals connected of different types. Type of source is boolean(T or F). Type of sink is 1-D array of boolean(T or F)'.

I understad that one is a scaler type and one is array type, but even by clearing the error I can't be sure that I'd wire it up correctly... Am I on the right track? I've attached the FPGA program. Thanks again guys,

Richie (Labview & PID rookie)!!

Unfortunately. You have the software, but not the hardware. You need FPGA hardware to run the FPGA stuff on. I only mentioned it to illustrate that NI also have a digital solution.

But all is not lost.

If you remember back to my example, I said we just need a way to open the valve for a period the PID algo tells us. This seems to be the bit you are having problems with.

For the digital output. You already Have an on/off controller example supplied by Ned. But what we really want is a PWM On/Off Controller then it would give us the opportunity to vary the on/off outside the dead-band. PWM always sounds complicated. It really isn't and to demonstrate I've modified Neds example.

The bottom half of the loop is Neds on/off controller. I've just modified it a bit so it isn't reliant on the previous iteration of the loop. It's functionally identical.

The top half is a timed gate which allows the signal from the on/off controller through for a specified period of time. So now we have an on off controller that we can vary the pulse width in the time domain. And that's PWM. Generally we wouldn't have it all in the same VI and the PWM would run asynchronously to the controller. But for our purposes its actually a bonus.

If we set the duty cycle to 100% (note I've used duty cycle and made it a percentage) then it will behave as Neds On/Off controller) then we have our on/off controller back again.

If only we could figure out a way to turn the error between the setpoint and the process value into a percentage......

It's unfortunate your hardware doesn't have a configurable counter/timer output otherwise you could have used that.

Thanks.Do you have a sample to send me?

There are several examples shipped with labview . Use the NI example finder and you will find them under:

>Building User Interfaces

> Listboxes and Tables

Shaun,

The fellow I work with is taking a controls class from the same prof I did 20 years ago (so I know he is worth listening to). He was reported to have made a provocative statement to the effect:

People are always trying to come up with some special algorithm for control, but after screwing around, and around, and around, they always find out the PID would do it better.

Who? The Prof? Or your colleague?

(my words again)

He believe meant that to cover even the asymmetrical case (that should be defined in more detail probably).

What I meant was that there are certain processes that on/off controllers simply cannot control. They become unstable and oscillate.

As an example of an asymmetric system (just to clarify after all.....aren't they all?). I once had an environmental chamber that was convection heated but nitrogen cooled. So. To ramp up (say) 5 °C would take 15 mins at 100% output, but with a 2 second injection of liquid nitrogen the temp would drop by 5°C in about 10 seconds. Especially since some dork had designed the thing with the temperature probe near the injector.

I suspect he is very good at ferreting out the P, the I , and the D. But that is a weighty statement. I will probably keep it in mind and not give up too soon.

Mike

What you have to bear in mind is that PID isn't 1 algorithm. Its 3 algorithms cascaded. And you can choose which benefits from the 3 you want to include. You could (for example) use only the P and I terms or the P and D or just the P. Its the flexibility that makes it attractive since there is no "one size fits all" solution for every system.

If maths is your forte then I would suggest reading P, PI, PID Control.

If (like me) you only want the bullet points and prefer practical examples then try PID Tutorial is

Yes, I'd love to see that idea implemented. Usually though, I take the situation as a hint I ought to put the loops in their own VIs. Not always convenient, but helps a lot for when you need to do stepping or execution highlighting.

It also gives you the option of running them in different priorities and execution systems.

We should have a jokes/humour section

Right, but if they're hooked up to a PID loop, they're using a PWM driver to convert the PID's continuous signal (duty cycle) into the device's discrete output (on or off). PID is meaningless in a digital system; if you can't change the magnitude of your output based on the magnitude of the error,

Ahhh. But you can.

Consider the lilly a tank that requires 10 litres to fill completely and all we have is a valve that only has 2 positions (open and closed i.e. digital control). Our hypothetical tank is (say) being drained at a rate of 1 litre per minute however, our valve, when fully opened, is capable of supplying 2 litres per minute. If we open that valve for 10 minutes then we will fill the tank to the brim and it all gets rather messy, what with the overspill and everything. However, if we open the valve for 30 seconds, we will supply the tank at the same rate as it is being emptied (on a minute by minute basis).

Now. the problem is, in all probability there will be times when there is nothing in the tank (due to timing differences, magic and the law of jam-butty) . So its desirable to open the valve for (say) 40 seconds so there is always more than is being consumed. Ultimately the tank will fill so as we approach the a pre-determined limit we want to switch back to 30 second "pulses".

We haven't changed the magnitude of the output (the valve can only be on or off). But what we have done is opened it for more or less time. We have "pulsed" the valve and by changing (or "modulating") how long we keep in open for ( "width" of the pulse), controlled the system and we can all go home .

For the above, PID control is simply a calculation (derived from the current level in the tank) that continuously calculates how long we leave the valve open for to achieve and maintain a desired steady state (a level in the tank).. What it gives us is a continuously varying duty PWM signal (which is varying at the sampling rate) , where the period is 1 minute and has a steady state at 50% duty cycle (30 seconds).

It doesn't really matter what interface we use to control the valve itself (analogue, digital, a hammer or telekinesis). Just as long as we can open and close it for an amount of time the PID algorithm tells us to.