API's and LabVIEW

[Joseph@EM32]

Hello,

I have an application where i need to monitor and log values of certain parameters in a Bosch-Rexroth drive. the drive's only connection is through it's built-in serial (RS-232) port. i have found a window's API has dll's that has functions written to communicate with a Bosch-Rexroth drive, i have downloaded it and followed the instructions to to build a variant for LabVIEW but i keep getting errors that i do not know how to fix.

Has anyone ever done this before? if so could you help me?

[GerdW]

Hi Joseph,

why do you need that DLL when you can communicate with the drive using VISA functions on the serial port?

[Joseph@EM32]

Communications with the drive have to use the Rexroth “SIS” protocol over the serial port. I’m having trouble implementing the “SIS” protocol in my vi’s. since the API was written using the SIS protocol, I thought that it would be a great solution to my problem if i could use the functions in the .dll.

i have tried importing the .dll but i only get one function, "close()"

[Mark_Yedinak]

I poked around their web site but couldn't find the documentation for their protocol. Do you have the API document? I can't image it would be too difficult to implement.

[Joseph@EM32]

i have a copy of Rexroth document Titled "Supplement A: Serial Communications SGP 01VRS"

the API, i found on GitHub: https://github.com/Maschina/BoschRexroth-Indradrive-API

the documentation here discusses downloading and installing Visual Studio, opening a solutions file included in the API download, selecting "ReleaseLabview" configuration and performing a build. unfortunately the solution file also includes other code, Python and C#, which may be part of the problem. 

[Mark_Yedinak]

Well, they do have a protocol document in the repository. Unfortunately I don't know German so it is fairly useless for me.

[Joseph@EM32]

please review this document

[Mark_Yedinak]

Based on that document there is an ASCII protocol for communicating with the device. This means you could use basic VISA VIs in your application. The bad news is that this is not the best API specification that I have seen. It is a bit light. It doesn't even include a full list of available commands. It also describes the SIS protocol. Again, it doesn't list the complete set of commands. If I were doing this I would first see if I could build their DLL. You never mentioned what errors you were getting. If that was not successful, I would try to go with the ASCII protocol. Not sure where you can get the complete API specification though.

[Joseph@EM32]

have you had a chance to review the document and page at https://github.com/Maschina/BoschRexroth-Indradrive-API?

 Look at the section on "Building".

the build instructions that came with the API tell you that you need to download and install Visual Studio 2017 or later, or Visual Studio 2015 Express. i could only find and download/install Visual Studio 2019 community. i started at Step 5 which is for LabVIEW. it says to " adjust the cintools folder to your LabVIEW version and...". that confused me because a cintools folder comes with LabVIEW. then it tells you to modify a file called "IndadriveAPIDefaults.props. this was easy to do. using their example i made modificaitons for my LabVIEW version, 2020.

then it tells you to open the Visual Studio solution file Indradrive.sln and choose "ReleaseLabVIEW" configuration. then build.

it is the build that i get errors. one error is MSB3703. don't know how to fix that. the other error has no code it just say that "the reference assemblies for .NETFramework, Version=v4.6.1 were not found". i think that i may be to find that and install it so that error may go away. but the MSB3703 keeps coming back.

you should review the "Build" section and the "Installation" section of the API documentation.

[rolfk]

Well since you have the source code of that driver and it uses plain ASCII over a VISA supported interface, it is usually much easier to write a driver in pure LabVIEW than getting this compiled and wrapped in LabVIEW VIs if your not doing this type of work almost every day.

Getting a C compiler properly configured for a particular project just from step by step tutorials without understanding fully what each step does is about as successful as playing roulette, sometimes you hit the jackpot but the next day it won’t work and even if succeeds you can’t be sure all is correct. 
Then comes the LabVIEW wrapper: in spite of its name, the Import Library Wizard can not do magic and creating automatically fully correct import libraries from a C header file would be true magic! The Wizard should only be seen as a tool to do the tedious work of creating (ugly) VIs that provide a starting point for you. Once it is finished the real work starts!!! You have to review and often rework the VIs to make sure Pointers, buffers and variables are properly sized and preallocated and to be more in line of what a LabVIEW library should work like. Bothering the LabVIEW user of your library with such details is wrong, bad practice and a sure way into disaster

Generally more than half of the source code of C(++) source code drivers is auxiliary helper stuff that is already taken care of by NI ViSA,, LabVIEW functions and 3rd party libraries like OpenG. The porting process is mostly limited to locating where the commands are formatted, and the responses are parsed and reimplementing that in LabVIEW. Together with a manual describing the protocol, this is almost always easier to do than trying to get such a driver compiled and imported if your daily work is not C programming!

And-there are many advantages:

- native LabVIEW drivers can be debugged directly in LabVIEW. 
- They work on every LabVIEW supported platform without needing to install a usually different C compiler and figuring out how to configure it for your target system and library.

- Easier to understand if you’re not a text language programmer as your main job.

- No chance for buffer overrun, protection faults and memory violation errors. Remember just because your DLL wrapping VIs do not crash your system anymore doesn’t mean all is fine, but just that you didn’t run into any protection fault. This could change anytimve if you change LabVIEW or OS version, use different commands and parameters or just because of good luck! Yes I consider a crash during debugging good luck here, as it helps you get rid of these nasties.By long not every memory error will cause an (immediate) crash!
- MUCH easier to make multithreading safe. 

I would dare to say that if you need youtobe videos telling you how to configure the C(++) compiler to compile your open source library you are very likely setting yourself up for a failure, If this is not an exercise to try to learn to fully understand how to do it for other libraries. If your main aim is to just get this library to work in LabVIEW and be done with it, you will be waking up from a nightmare.