I saw there was some interest in communicating with the OK boards using LabVIEW so I used the import wizard (making sure to add _WIN32 to Preprocessor Definitions). There were some errors that I had to go through and manually fix like pointer sizes and I had to change some parameters so they passed by value instead of pointer. The forum limits my upload to 1 MB so I had to leave out the DLL. I think LV should be able to find it automatically if you copy the dll from C:\Program Files\Opal Kelly\FrontPanelUSB\API\lib to the folder with all the Opal Kelly subVIs: okFrontPanel.
After wrapping all the required DLL functions, I manually converted the source code for the DES example from the other programming languages.
DES Example2.zip (112.6 KB)
This was intended as a proof of concept. If I was being more thorough, I’d probably make typedefs for the handles, make more inputs required, clean up some diagrams and panels, connect up more of the DLL returns and convert them to errors.
2 Likes
This could be a very handy time-saver for engineers using LabView. Thank you for posting.
Also thank you for not including the DLL here because that would be a violation of our redistribution policy. 
Thank you so much for uploading this! I there any chance you save it for 2019 version? Or it is okay if I request the same on LabVIEW forum?
I backed it to 2012
DES Example 2012.zip (118.0 KB)
1 Like
Thank you so much! I think this is what I needed. You are a savior!
No prob. The ideal situation would be to develop in LabVIEW FPGA to generate the VHDL and then run that code on an OpalKelly board. It looks like there’s an OK equivalent for FIFOs (OK Pipes) and the FPGA Read/Write nodes (OK Wires). Maybe some scripting could make the transition a little easier. OpalKelly is an incredible value proposition compared to something like FlexRIO.
I agree. I have explored a little bit to see how LabVIEW prepares VHDL files, I studied VHDL files that it temporarily creates for a job and it has a lot in it that did not seem like a plug and play option. Maybe the paid VHDL exporter option by NI will provide something of this nature.
I can say that I started real FPGA programming using VHDL when I started working on Opal Kelly boards. This has so much possibilities!
Hi bitsandbytes,
I could run your VI and I can read Board Model after some trial and error. For some reason LabVIEW lost information on Functions for each VI so had manually update them to run. But I am getting error 5000 ‘no response from FPGA’ after update triggers out.vi, no other LabVIEW error. I believe I might have to adjust data type in some of the VIs.
Since there are so many inputs and data types I am not sure how to proceed. This is my first time using a dll library.
Where can I get the information on Function Prototype’s data types used and information about different parameter’s default values e.g. val, mask or epAddr?
When using the import library with LabVIEW, VIs get created on its own but their data type is wrong.
Are you using 32 bit? Yes, for some reason the 32 bit functions are names slightly differently. Maybe I can use a conditional disable to handle the switch in the future. How confident are you that you’re loading the correct bitfile? Can you run the exe/python version of the DES Example? If you’re asking what epAddr is , you can get that from the API doc:
https://library.opalkelly.com/library/FrontPanelAPI/classokCFrontPanel.html#a74f8b4b37ccc57dd72b5b739bbc45766
But specific to this DES Example, I got the epAddr from the cpp example. Ultimately, they are set in the VHDL.
Yes, I am using 32 bit.
I do not think I am loading a correct bitfile. I am loading a bit file that I created. I think this assumption was wrong. I am thinking it would be an example bitfile somewhere on Opal Kelly website, right?
Unfortunately, my knowledge is limited to LabVIEW and VHDL only. I am not familiar with any other language/ tool.
My aim is to deploy a bitfile of choice, I am in early stages exploring dll realm.
Thank you for the link I feel a bit less lost looking at the information it has.
Yes, you can get the DES Example bitfile for your board here:
https://pins.opalkelly.com/downloads
Then check out destop.vhdl and DESTester.cpp at C:\Program Files\Opal Kelly\FrontPanelUSB\Samples\DES
You’ll see the addresses down at the bottom. The address for this line in the cpp/labview code
xem->ActivateTriggerIn(0x40, 0);
corresponds to where we define the input for the DES module in
ep40 : okTriggerIn port map (okHE=>okHE, ep_addr=>x"40", ep_clk=>sys_clk, ep_trigger=>TrigIn40);
Once you confirm all that is working as expected, you can then write your own modules and use any address you want (instead of 0x40 above)
1 Like
Woah! Everything works and worked after you corrected me. Thank you so much you genius and generous human!
I could write the DES bit file and even one that I have written.
I cannot thank you enough!
I wish to be at your level of knowledge one day.
For someone with 32 bit LabVIEW like me, I am attaching the bitsandbyte’'s slightly modified VIs in a zip folder. @bitsandbytes its a beautiful (2048 bit) string!
DES_LV32bit.zip (148.4 KB)
Thank you very much, bitsandbytes and nishant for the DLL use in LabVIEW. I tried your VIs and had some success - the board gets recognized, the serial number is read out OK, the board type is OK too. However, I can’t get the ConfigureFPGA to work. The VI hangs (and its output error code doesn’t appear) and I have to kill LabVIEW after this. I suspect the function can’t find the bitfile, despite having copies in the working directory and where the DLL is. Can you tell me where is the bitfile located in your systems?
Note to future developers, add some sanity checking to ensure the bitfile exists before attempting to load.
My bit file is in C:\Users\{username}\Downloads\20220711-FP527-XEM8350-KU060\20220711-FP527-XEM8350-KU060\des.bit The directory is totally unreleated to the DLL path which happens to be C:\shared\DES Example\builds\data\okFrontPanel.dll