anas9011
USA
Asked
— Edited
Resolved by thetechguru!
Hey,
So I've been working with the EZB SDK with VB C and C++. I got the hang of it and know most of the functions/how to set up. I'm working with some fellow colleagues on integrating the EZB with a feature extraction algorithm written in labview. However, for some reason I cannot reference the EZB.DLL into labview and get started! I know its a .NET type but something tells me it has to do with 32/64-bit compatibility issues. Could this be the case? We do have some labview code that controls an EZ-Rover and it references the dll properly, but that was written in LabVIEW 2013. Do we need to downgrade or change compatibility?
Thanks in advance!
EZ-B is definitely 32-bit, so that could be an issue. Could also be your .NET version. I haven't done anything in LabVIEW in many many years, so can't provide much assistance there, but I do know their customer service is excellent, so you might want to also ask the question in their user forum or even call their tech support.
Alan
I see. While on the topic of compatibility, can you tell me what .NET version EZ-B uses? Since I'm running 64-bit systems, I'm guess I need to start running programs in 32-bit compatibility now. Also, if I may digress, can I access the DLL file in some way to make some sort of 64-bit wrapper DLL? As of now, whenever I open EZ_B.dll in VS2015, I only get a strange Icon and Version dropdown (See Image).
Hopefully DJ will jump in. I believe it is now .NET 4.5. That is certainly the framework he recommends users install or re-install when things go wonky, but I know it is backwards compatible, so the DLL may be compiled in something lower. I haven't read the SDK readme file in a while, it might be in there.
I can't answer the wrapper question. Still learning the basics of .NET myself. Not nearly ready to take on that complexity. I only answered at all because I have a passing familiarity with LabView, but really only from playing around with it when National Instruments was one of my customers and I spent some time in their customer service center in Japan. Had some time on my hands, so played with their toys...... (Did you know NI developed Mindstorms for Lego?).
Alan
Yes I do know! But thanks for answering the question, helps clarify a good deal.
Thanks!
Have you seen this? http://digital.ni.com/public.nsf/allkb/DCB90714981A1F148625731E00797C33
Also, @anas9011 you should not need a 64bit wrapper because all 32bit binaries are upwards compatible from 64bit runtimes. That being said, if labview (for some strange reason) doesn't like 32bit libraries, i can compile the sdk in 64bit for you
The reason the ez-b is 32 bit is because there is no 64 bit variables used - which would provide no performance improvements. There are execution optimizations with 32 bit executable on a 64 bit system, because the other bits (in some instances) can be used at the same time. So in some cases, a 32 bit runtime is faster (or more optimized) than a 64 bit
Yep, I saw that post, first one I went to Actually, I just opened up LabView 2015 32-bit and I keep getting this error (see image), same with 64-bit. I'm downloading LV2013 to see if its some version issue; since we have some LabView VI's written to work with the rover and they reference the EZ_B.dll properly, but they were written in LV2013. I've looked around and tried stuff like this: http://digital.ni.com/public.nsf/allkb/4742EB60B64BE22186257BCE0053B8FD
@DJSures if you could send me a 64-bit library that would be very, very much appreciated.
Mini-solution:
Alright, so I did two things to make this somewhat work:
Do not create a new thread on the same topic. Here is the content of the duplicate thread, which has been deleted.
Hi,
I recently posted a thread regarding the usage of the EZB SDK in Labview 2015, however, I'm still having issues using it in my code. I'm using LabView 2015 - 32 bit on a windows 7 -64 bit system. I have the latest .NET distributables downloaded. I have also tested the dll on a C++ program in VS2015 and it works fine. Whenever I create a .NET reference constructor in Labview to reference EZ_B.dll I get the following error: "An error occurred trying to load the assembly" (See image)
However, referencing other files, like aForge.dll and EZ-QRCode.dll work fine (See second image). When working with LV2015-64 bit, all the dll's had the same error, as expected.
Is this an issue that should be put up with National Instruments or is there something I could do from this end?
Thanks!
@anas9011:
What EZB's features you will need/use with LabView ?
I recommend the OP uses the mono dll instead of the sdk. Considering they're so similar.
The sdk only has vision stuff that you're probably going to do in labview anyway. If needing the sdk for vision as well, I guess the question is why is labview being used and not visual studio?
Visual studio is much faster
@DJ,
That was my direction, if they say no video, Mono version will work.
I suspect LabView is doing .net reflection on the EZ_B.dll to provide a "Wizard" view of the dll, and that's not possible with the EZ_B windows version.
@ptp I will be using very basic commands that involve servo movement. Basically moving the robot around. @djsures One of our lab members wrote a very robust feature extraction algorithm in LabView and converting it to C++ or the like would be very complicated and time consuming. I personally prefer VS over LabView. Let me go over the mono and see how that works out.
@anas9011,
regarding your setup:
are you using analog servos or digital (dynamixel) servos ? do you have a EZR kit (JD, etc) or is a custom setup ? do you need the EZB camera feed ?
@ptp @djsures I just solved it....I really hate it when I do stuff like this. The LabView VI and the SDK folder were in the same folder, but the DLL's weren't. For some reason I just decided to put all the DLLs and the VI in the same folder now. Now I got all the functions to load.
FYI I really appreciate you guys taking the time out to help me. Big Kudos. My LabView programming logic got a bit better now Thank you guys VERY much.
ah! that maekse sense great to hear it's working! I feel silly for not suggesting it - guess we all overlook the simple solutions sometimes