Problem calling UDK1.3 function CeEnumerate from LabView

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Problem calling UDK1.3 function CeEnumerate from LabView

      I made a decision to update my design in order to use the new version of the UDK (move from UDK2 to UDK3). Normally I use LabView to develop my applications, the process to call functions from a dll in LabView is well known and easy to use. In fact the new versions of LabView implement a tool that from a C include file is possible to generate all the VIs of the functions exported in a dll.
      I am able to use my old code written in LabView if I mix the two version of UDK, this mean if I install the new driver from UDK3 (udk3-usb-driver-windows-1.1.exe) and continue to using the old version of the dll (udkapic_vc10_x86.dll , this dll came from the UDK2.0.0) I do not have any problem.
      This is a solution but is not the optimal solution. I want to use only the UDK 3 libraries.
      My problem began when I call the function CeEnumerate (I already call the CeInit) this function return the number of devices connected but in my case when I call it always get 0 devices. In the UDK2 to obtain the number of devices is necessary to call two functions Enumerate and GetDeviceCount , doing this I get, in the same condition, the correct number of connected devices.

      1- Equivalent sequence in c to UDK2

      CE_RESULT CE_EXPORT Init();
      CE_RESULT CE_EXPORT Enumerate(unsigned int DeviceType);
      CE_RESULT CE_EXPORT GetDeviceCount(unsigned int *puiCount);

      2- Equivalent sequence in c to UDK3

      CE_RESULT CE_EXPORT CeInit();
      CE_RESULT CE_EXPORT CeEnumerate(int deviceType, int *count);

      Where the problem can be.

      The post was edited 3 times, last by artechedi ().

    • I assume the modules can't be found in your case. Be sure that udk3mod-1.3-winusb-[arch].dll is either in the startup path of your application (I'm not sure how this works in LabVIEW) or use CeInitEx() instead. Using CeInitEx(), you can specify the path where the modules can be found.
      Thomas
      Software development
      Cesys GmbH
    • Thoppe first thank you for your advice. I tried to do what you suggested but with the same result. After some attempts I made a decision to look where the driver installation put the two dll needed to access to the FPGA. As result of my search I get the path C:\Windows\cesys\udk3\svc and for my surprise I found the dll udk3-1.0-x86.dll and udk3mod-1.0-winusb-x86.dll. I am trying to use the last versions of the UDK3 (1.3 this means udk3-1.3-x86.dll and udk3mod-1.3-winusb-x86.dll). At this point I continued trying to solve my problem with LabView and the solution to get the correct answer of the function CeEnumerate was move the two dlls to the \window\system32\ path. With my initial problem solved I moved forward. I call the function CeEnumerateInfo in order to detect my exact device ( I have more than one connected). At this point I get one exception in LabView but if I use the library udk3-1.0-x86.dll I bypass the problem and I finish my software.

      Is possible to get the info of what differences are between the versions of the dlls?

      As I set before my applications work with the old dll but I suppose that it do not support the usb3.0 for the new module EFM02. This last sentence is one of my motivation for the update of my codes, a part of the necessity of move to windows 8. Maybe in the future I have the opportunity to work with new board EFM02 and I want to be prepare for that.

      Raúl Arteche Díaz
      Physic Department,
      CEADEN

      The post was edited 1 time, last by artechedi ().

    • I have idea why 1.0 works and 1.3 not. There were no changes in the order that one works and the other version not. Do you have tried to run an example in an official supported language (Java and Python examples can simply be started, you just need the respective framework installed. Do our tools work on your system (UDKPerfMon/UDKBoardMan) ?

      Besides that, I have no idea about the options that LabVIEW offers to diagnose the problem.
      Thomas
      Software development
      Cesys GmbH
    • Yes I already check the tools of the UDK3. I put the result of the payton test, how you can see my device was programed using UDKBoardMan (check the UserId).

      Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600 32 bit (Intel)] on win32
      Type "copyright", "credits" or "license()" for more information.
      >>> ================================ RESTART ================================
      >>>
      UDK3 version : 1.3
      Device found:
      Name : EFM01
      Bus : 2
      Vid : 10f8
      Pid : c482
      UserId : LF02-0001
      SerialNumber : unavailable
      FirmwareVersion : 2.0
      MaxTransferSize : 16777216 bytes
      DerivateInfo : XC3S500E-4CPG132C
      DerivateId : 0x00000000
      EFM01 specific test
      ---------------------------------------------
      LED: #-#-#-#-#-#-#-#-#-#-
      Write/read block RAM
      Read and save flash
      >>>

      By the way. I digging dipper in your driver installation and I am sure that is possible to modify it in order to get that the dll libraries be installed in the windows\system32 path ( I already done this modification to the inf file and today I will modify the installation of the cuuds.exe service for the loading stage procedure). The cuuds.exe look like that use the version 1.0 of the dlls, I assume this because dose dlls are in the path of the service. I run the payton test with all the version that I have in my machine (1.0, 1.1and 1.3) all of them are installed by different tools in the package downloaded from this forum (Cesys UDK3 Download (1.3)).

      You can use the fallowing procedure in order to certify your driver ( doing something similar)

      Inf2Cat.exe /driver:"C:\tmp\driver" /v /os:XP_X86,XP_X64,7_X86,7_X64

      makecert.exe -r -pe "C:\tmp\driver\ceaden_certificate\ceaden.cer" -n CN="CEADEN" -sv "C:\tmp\driver\ceaden_certificate\ceaden.pvk" -len 2048

      pvk2pfx.exe -pvk "C:\tmp\driver\ceaden_certificate\ceaden.pvk" -spc "C:\tmp\driver\ceaden_certificate\ceaden.cer" -pfx "C:\tmp\driver\ceaden_certificate\ceaden.pfx" -pi "ceaden" -po "ceaden" -f

      signtool.exe sign /f "C:\tmp\driver\ceaden_certificate\ceaden.pfx" /p ceaden /t timestamp.verisign.com/scripts/timstamp.dll "C:\tmp\driver\cdc_srn1c_02_usb.cat"

      The tools are part of the DDK and the SDK of microsoft.

      I will try to contact national Instruments in order to see my problem with the Exception. If I have any good result I will share it.

      My best regard,
      Arteche
    • Many thanks for your extensive information.
      -> We use different versions for drivers and API, as there's no need to always use the latest version for our service. This service is just responsible to program the firmware to the FX2 after plugging the device and doesn't use any API feature.
      -> Putting the DLL's to systems library path (system32 / syswow64) has it's downsides: If multiple applications install the same DLL's, none of these applications should remove them on uninstall, so they may remain dead after the last application that uses it is removed. Thats why we (especially I) always prefer a portable installation. Remove directory -> System cleaned. This works on all major platforms (Windows, Linux and Mac), thats why we do it to hold our application consitant on these platforms. But if you write your own installer for your application, you are free to handle it this way.
      -> I always thought that our driver is signed in a similar fashion, otherwise it won't install on Windows 8+ (without a special boot procedure). I will take a look into this (If I get some free time from my other projects :) ).

      best regards,
      Thomas
      Software development
      Cesys GmbH