Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Sending and receiving data from PIC18F4550

Solved!
Go to solution

ok some success, now im using void  HidD_GetHidGuid(int32_t *arg1); function in call library function node,

 

and i could get the Device Interface GUID into the numeric indicator...

 

now what about other functions... for example, HidD_GetAttributes .. in order to use it, i must supply the IN HANDLE HidDeviceObject, as stated by the MSDN help..

 

however, i cannot find any example code where it could be extracted from... i have a driver code, but there they use another functions like HidD_GetAttributes = (PHidD_GetAttributes)GetProcAddress(hHID, "HidD_GetAttributes"); 

 

so... now i really need some example or explanation from someone who used to work with HID.DLL from LabView... though i understand already the overall process.. 

 

ok i will research more for now and wait for any replies

0 Kudos
Message 11 of 25
(5,192 Views)
Solution
Accepted by topic author cyrax

Ok, i was experimenting with all this stuff and now could make it run. So here is what i decided to use, when you install Microchip Solutions, in its install folder there is a folder USB Device - MCHPUSB - Generic Driver Demo, u should just compile it with MPLAB, and load the HEX file to the PIC18F4550. Then, im attaching my VI, u should put mpusbapi.dll in the same folder with this VI, and run it, also, dont forget to point all the Call Library Function Nodes in the VI to point to this DLL (cuz i think i had it in another folder).

 

mpusbapi.dll is a custom USB driver...it is i think even better solution than making it work with HID.DLL, also another good thing is that u can have another custom windows application work with this DLL, and the LabView VI is just talking to mpusbapi.dll

 

it is better than installing and messing with VISA... one driver - two applications (LabView, custom app).

 

the VI is working, i did not implement all the functions, but it works, it reads data from potentiometer and displays on meter.

 

p.s. there is also same example in the internet, but it was done with CIN, however, i think its easier and better to do it with Call Function Library node and DLL. I wish to find such an example before...but now i hope it would help someone.

 

thanx for replies and advices here!

0 Kudos
Message 12 of 25
(5,147 Views)

forgot to say... u should also not forget to install the driver, it is located in that same install folder of Microchip Solutions..

 

thanx

0 Kudos
Message 13 of 25
(5,144 Views)

Hello,

 

I'm trying to open your file but it was created with LV 8.6 and i didn't got this version of LV.

It's possible to convert it on the version combatible with LV 8.5?

 

Thanks for replies

0 Kudos
Message 14 of 25
(3,937 Views)

Mr. Bar,

 

There is a downconvert request thread here: 

http://forums.ni.com/t5/LabVIEW/Downconvert-VI-Requests/m-p/1067229?requireLogin=False

 

Regards,

 

Kyle Mozdzyn

Applications Engineering

National Instruments

Regards,

Kyle M.
Applications Engineering
National Instruments
0 Kudos
Message 15 of 25
(3,919 Views)

Hello

 

Thank for the replies!

0 Kudos
Message 16 of 25
(3,901 Views)

Im glad it worked for you. When i did this it was my first and last experiment with LabView. Im not working with it anymore, and it is pretty much worthless software. When i need to perform some data acquisition or control, i just use the USB driver, design my hardware with USB functionality, and write APP level software myself. It does not take much time, however; gives full control over your project, it is a way better rather than using buggy black box like LabView...also it is free.

 

And so many times i'v received negative opinions from professional engineers about LabView, about its bugs popping out in a wrong moment, and that a user does not actually have a control over its code. When you write your software, or at least use USB driver libraries you always know whats going on, and creating interface on App level is really not that hard and time consuming.

 

So im pretty much done with LabView, its a fail. Some companies use it and consider it something what employees must know, but i think its really silly. Especially paying for it that much money.

 

Maybe for non EE people it might be kind of helpful for simple projects though. good luck.

0 Kudos
Message 17 of 25
(3,898 Views)

Cyrax,

 

Im sorry that you havent had more luck with labview. Its a very powerful programming environment, but going to a graphical, dataflow language does come with a significant learning curve when coming from a traditional text based background. I think much of our userbase would have a different opinion on the amount of control you can exert with labview though 😉  

 

Regards,

 

Kyle Mozdzyn

Applications Engineering

National Instruments 

Regards,

Kyle M.
Applications Engineering
National Instruments
0 Kudos
Message 18 of 25
(3,888 Views)

"control and LabView" - are you sure? Smiley Very Happy

 

you have idea of internals of code while working with it? Most of users enjoy it because it looks "neat" and gives opportunity to play around with nice gui etc. But technically its pretty much worthless. I do not need that graphical dataflow, im ok with a code, and its much more easier to share the code if all people within project are good at it.

 

I do not need to waste time on that significant learning curve to play around with graphics. gcc + your own libraries + some worked out templates, and i can do any job pretty faster 🙂 and most of all...i have control... real control 🙂

 

ok im not going to argue. you have fun with that. 🙂

0 Kudos
Message 19 of 25
(3,886 Views)

Hello

 

Thanks for advises, and I found a solution for creating a communication between Labview and Pic.

I use an emulating com rs232 over USB! and that's work!

 

Thanks a lot for you attention to my post!

0 Kudos
Message 20 of 25
(3,882 Views)