CONFIGURING WINDOWS SDK FUNTIONS IN LABVIEW

[mattdl68]

QUOTE (normandinf @ Jan 6 2009, 08:59 AM)

Probably here...

GUID Structure

http://forums.ni.com/ni/board/message?boar...ding&page=1

Thanks rolfk the link above will give you some history to my nightmare.......lol. What is confusing to me,is how to find the order of the dll's and functions to get what I need.

There has to be some documentation out there that would give you some idea of the order in which to call functions.........one would think....lol

I would think when trying to find USB devices using C++ they would need the order as well.

[mattdl68]

QUOTE (normandinf @ Jan 6 2009, 08:59 AM)

Probably here...

GUID Structure

http://forums.ni.com/ni/board/message?boar...ding&page=1

Thanks rolfk the link above will give you some history to my nightmare.......lol. What is confusing to me,is how to find the order of the dll's and functions to get what I need.

There has to be some documentation out there that would give you some idea of the order in which to call functions.........one would think....lol

I would think when trying to find USB devices using C++ they would need the order as well.

[mattdl68]

QUOTE (normandinf @ Jan 6 2009, 08:59 AM)

Probably here...

GUID Structure

http://forums.ni.com/ni/board/message?boar...ding&page=1

Thanks rolfk the link above will give you some history to my nightmare.......lol. What is confusing to me,is how to find the order of the dll's and functions to get what I need.

There has to be some documentation out there that would give you some idea of the order in which to call functions.........one would think....lol

I would think when trying to find USB devices using C++ they would need the order as well.

[mattdl68]

QUOTE (normandinf @ Jan 6 2009, 08:59 AM)

Probably here...

GUID Structure

http://forums.ni.com/ni/board/message?boar...ding&page=1

Thanks rolfk the link above will give you some history to my nightmare.......lol. What is confusing to me,is how to find the order of the dll's and functions to get what I need.

There has to be some documentation out there that would give you some idea of the order in which to call functions.........one would think....lol

I would think when trying to find USB devices using C++ they would need the order as well.

[Irene_he]

QUOTE (mattdl68 @ Jan 7 2009, 08:44 PM)

http://forums.ni.com/ni/board/message?boar...ding&page=1

Thanks rolfk the link above will give you some history to my nightmare.......lol. What is confusing to me,is how to find the order of the dll's and functions to get what I need.

There has to be some documentation out there that would give you some idea of the order in which to call functions.........one would think....lol

I would think when trying to find USB devices using C++ they would need the order as well.

....

There will be no obvious document for telling you what the order is...from my past experiences dealing with directshow or other msdn libraries. I would suggest to look at some existing C/C++ examples or even dot net example, you can either find it from the SDK or DDK download that uses the dll that is involved or you can always search at google. Maybe other people can tell you their own experiences about finding the order or logic of msdn, they are just not as easy and visible as LabVIEW.

Irene

[mattdl68]

QUOTE (Irene_he @ Jan 7 2009, 09:37 PM)

There will be no obvious document for telling you what the order is...from my past experiences dealing with directshow or other msdn libraries. I would suggest to look at some existing C/C++ examples or even dot net example, you can either find it from the SDK or DDK download that uses the dll that is involved or you can always search at google. Maybe other people can tell you their own experiences about finding the order or logic of msdn, they are just not as easy and visible as LabVIEW.

Irene

http://www.delcom-eng.com/downloads/USBPRGMNL.pdf

I found this document and i'm going to try a few things.I'll let you know how I make out.

[Val Brown]

Yes, actually I have but that was probably something like 24 years ago. And, yes, what's impressive about the failures of that Wizard is not so that they occur -- of course they do! -- it's really that the code is apparently officially supported etc. How it got to be officially supported and have that much challenge remaining in its deployed form is what is really impressive. And, yes, it's a definitely difficult challenge to craft such a Wizard. And knowing all of that made it that much more interesting to have it released.

[Irene_he]

QUOTE (rolfk @ Jan 7 2009, 05:53 AM)

Ever written a C compiler? Try and you will understand!

I admire the courage of the person not only attempting the task of creating the DLL Wizard (I've written a somewhat less exhaustive C header parser in LabVIEW for another project) but also adding it to the released version of LabVIEW. How it got past the release manager I'm not sure but that person probably had no idea about how difficult a good C parser is, so he or she believed it to work fine after being shown some successful imports from not to complicated APIs .

Rolf Kalbermatter

Haven't you heard about that a person knows 20% is more couragable than a person knows 80%? I have a high school classmate, he makes multimedia chips, those used in MP4 etc. I kept asking him how did he get started and dare to try out. He said because he knew nothing. And he is quite successful. Best time to do things is when you think you know 20%. Am I wrong?

Irene

[Rolf Kalbermatter]

QUOTE (Irene_he @ Jan 8 2009, 12:07 AM)

Haven't you heard about that a person knows 20% is more couragable than a person knows 80%? I have a high school classmate, he makes multimedia chips, those used in MP4 etc. I kept asking him how did he get started and dare to try out. He said because he knew nothing. And he is quite successful. Best time to do things is when you think you know 20%. Am I wrong?

No I think you are right. Except the person knowing 20% does not know that percentage . That person likely thinks to know almost anything he or she would need to do the task only to find out later that there was about 4 to 5 times as much to learn before they could actually succeed. The problem is that some people get discouraged half way through it and then abandon the idea. I have some of those projects too.

Another quite common thing is that the last 10% of the work require 90% of the time. That is where most people stop.

Rolf Kalbermatter

QUOTE (mattdl68 @ Jan 7 2009, 08:44 PM)

Thanks

rolfk

the link above will give you some history to my nightmare.......lol. What is confusing to me,is how to find the order of the dll's and functions to get what I need.

There has to be some documentation out there that would give you some idea of the order in which to call functions.........one would think....lol

I would think when trying to find USB devices using C++ they would need the order as well.

Of course! And except from examples in the SDKs (and DDKs) and sometimes from Open Source projects you can investigate how certain things are done, that is where the creative art of programming starts. With trial and error, combinatorial logic, experience with certain types of APIs (if you have programmed WINAPI application, writing a MacOS X application can seem a really unlogical way of doing things and vice versa) and some sort of magic (I have often tinkered one or more days about how to get something to work, only to wake up one morning and having suddenly an idea that turned out to be the start of a solution), you go step by step about programming something.

Programming in LabVIEW itself is not that much different but its on a much higher and more abstract level than tinkering with system APIs. And there is really no magic LabVIEW could employ to make working on system API level as easy as working on LabVIEW diagram level besides of having people like the NI elves and other third party developers write impressive intermediate level software such as DAQmx to make the work for the LabVIEW programmer more bearable. It's about the way your brain cells work and have been trained.

On the same level, I've seen several brilliant system programmers cringe and falter at an attempt to produce a more than trivial LabVIEW application.

Rolf Kalbermatter

[mattdl68]

QUOTE (rolfk @ Jan 8 2009, 02:52 AM)

No I think you are right. Except the person knowing 20% does not know that percentage . That person likely thinks to know almost anything he or she would need to do the task only to find out later that there was about 4 to 5 times as much to learn before they could actually succeed. The problem is that some people get discouraged half way through it and then abandon the idea. I have some of those projects too.

Another quite common thing is that the last 10% of the work require 90% of the time. That is where most people stop.

Rolf Kalbermatter

Of course! And except from examples in the SDKs (and DDKs) and sometimes from Open Source projects you can investigate how certain things are done, that is where the creative art of programming starts. With trial and error, combinatorial logic, experience with certain types of APIs (if you have programmed WINAPI application, writing a MacOS X application can seem a really unlogical way of doing things and vice versa) and some sort of magic (I have often tinkered one or more days about how to get something to work, only to wake up one morning and having suddenly an idea that turned out to be the start of a solution), you go step by step about programming something.

Programming in LabVIEW itself is not that much different but its on a much higher and more abstract level than tinkering with system APIs. And there is really no magic LabVIEW could employ to make working on system API level as easy as working on LabVIEW diagram level besides of having people like the NI elves and other third party developers write impressive intermediate level software such as DAQmx to make the work for the LabVIEW programmer more bearable. It's about the way your brain cells work and have been trained.

On the same level, I've seen several brilliant system programmers cringe and falter at an attempt to produce a more than trivial LabVIEW application.

Rolf Kalbermatter

http://zone.ni.com/reference/en-XX/help/37...g_the_clf_node/

I think this will help,But its for 8.6

[Rolf Kalbermatter]

QUOTE (mattdl68 @ Jan 8 2009, 05:39 PM)

http://zone.ni.com/reference/en-XX/help/37...g_the_clf_node/

I think this will help,But its for 8.6

This is in the installed online help of LabVIEW for quite some time at least since 8.0 although with some small modifications in each version to adapt to changes and new features of the Call Library Node configuration.

LabVIEW Help Menu->Search the LabVIEW Help: Index Tab: enter call library

This will eventually get you to a topic under: Fundamentals->Calling Code Written in Text Based Languages->Concepts->Calling Shared Libraries (DLLs)

It is about the meaning of the options in the configuration of the Call Library Node. But it won't help you with your previous question, how to find out in which order and with what parameters to call a particular API. Of course it is actually about calling an API that is typically written in C and the whole shared library concept is based on C too, so understanding at least the basic principles of C datatypes and their handling is really a prerequisite to be able to even understand what all those options and things mean.

But that is not LabVIEW's fault, other than that it does not require you to know much about those things for programming some simple LabVIEW only VIs. For complexer programming it is even in LabVIEW more or less doomed, if you do not have some good basic programming knowledge, although the more C specific things you don't really need to know unless you want to venture into the Call Library Node or God forbid the Code Interface Node.

Rolf Kalbermatter

[mattdl68]

QUOTE (rolfk @ Jan 9 2009, 01:56 AM)

This is in the installed online help of LabVIEW for quite some time at least since 8.0 although with some small modifications in each version to adapt to changes and new features of the Call Library Node configuration.

LabVIEW Help Menu->Search the LabVIEW Help: Index Tab: enter call library

This will eventually get you to a topic under: Fundamentals->Calling Code Written in Text Based Languages->Concepts->Calling Shared Libraries (DLLs)

It is about the meaning of the options in the configuration of the Call Library Node. But it won't help you with your previous question, how to find out in which order and with what parameters to call a particular API. Of course it is actually about calling an API that is typically written in C and the whole shared library concept is based on C too, so understanding at least the basic principles of C datatypes and their handling is really a prerequisite to be able to even understand what all those options and things mean.

But that is not LabVIEW's fault, other than that it does not require you to know much about those things for programming some simple LabVIEW only VIs. For complexer programming it is even in LabVIEW more or less doomed, if you do not have some good basic programming knowledge, although the more C specific things you don't really need to know unless you want to venture into the Call Library Node or God forbid the Code Interface Node.

Rolf Kalbermatter

Hi all jlk posted 62628 post a vi HID_Get_GUID.vi see Post #15.

I did a little digging into the result .

I used the guide from the HID get Guid to setup the SetupDiGetClassDevs with no luck see attached.

Thanks

[denisetucker]

QUOTE (mattdl68 @ Jan 3 2009, 11:42 PM)

I'm not either. I've not succeded in retreiving a handle the the proper DeviceInfo (and I won't have time to play with it since it's back to work tomorrow...) but here is a little tip: Use the GetLastError and FormatMessage functions from kernel32.dll. This way, you'll know what sort of problem you have.

It seems I've misled you with the datatypes I showed on my screenshot but I thought it was not important since those parameters are optional. The LPGUID typedef is a pointer to a GUID structure. Think of "struct" as a cluster in LabVIEW terminology. Hence, the datatype for GUID is something like this:

typedef struct _GUID {DWORD Data1; WORD Data2; WORD Data3; BYTE Data4[8]; } GUID; where for example this GUID: eeaf37d0-1963-47c4-aa48-72476db7cf49 would be represented by:DATA1 = EEAF37D0DATA2 = 1963DATA3 = 47C4DATA4 = {AA, 48, 72, 47, 6D, B7, CF, 49}

It is not trivial to get these to work in LabVIEW... The trick is to match the types and I personally find that frustrating sometimes!

In this case, I'm returned ERROR_INVALID_DATA. I'll leave it up to you to find a solution... But here's my Windows Error Extraction class if that can be of help. (Just input the error code from GetLastError() and Merge it to LV error cluster.

Download File:post-10515-1231128408.zip (LV 8.6)

Is this code available? The link does not work. Please?

[Francois Normandin]

Is this code available? The link does not work. Please?

I couldn't find the old code. That was prior to me learning to use SCC ;-)

Here's something equivalent to what you're looking for. It's in LV2009. Launch the test VI to get an idea of the functions.

WinError_class.zip (LV 2009)

[denisetucker]

I couldn't find the old code. That was prior to me learning to use SCC ;-)

Here's something equivalent to what you're looking for. It's in LV2009. Launch the test VI to get an idea of the functions.

WinError_class.zip (LV 2009)

Thanks, Francois. I am actually interested in the HID specifically, but I appreciate you attaching the code. Looks like no one really got it working anyway. Bummer!

[Rolf Kalbermatter]

Is this code available? The link does not work. Please?[/left]

The code as posted in the diagram won't work at all. You can not emulate an embedded fixed size array in a cluster with a LabVIEW variable sized array at all. Instead you have to use a cluster which contains the same amount of elements of the same datatype, to match the fixed size array.

So a GUID is really a cluster of type { uint32,uint16,uint16, {uint8,uint8,uint8,uint8,uint8,uint8,uint8,uint8}}

[Lucas]

First: Thank you all for sharing your information!

 

Without it I would have had more headaches with getting to work the setupapi functions in LabView.

That's why I uploaded a lbb for debug and a working USB-Devices_SetupApi_Properties.vi (LabView2014).

So others can have advantage of it and having less headaches for using setupapi in LabView.

 

Best regards...

 

Update: Added disable and enable device in USB-Devices_SetupApi_Properties2.vi

USB-Devices_SetupApi_Properties.vi

SetupApi_Debug.llb

USB-Devices_SetupApi_Properties2.vi

Edited September 24, 2015 by Lucas