LabVIEW
Unable to load shared library 'EposCmd.dll' on sbRIO 9267
@antje668 wrote:
I am referring to this: https://www.yottavolt.com/shop/stratom-can-adapter-for-myrio/
Alright, do you have any suggestions on where I should start? So my aim is to make the shaft of the DC-motor to rotate with help of the VIs from EPOS and myRIO where as I mentioned earlier the myRIO and the controller for the DC-motor communicates via CAN and the obstacle right now that I have is that the library needs to be on the myRIO in Linux format 🙂
Well, things are now clearer but definitely not easier. 😀
You have a custom hardware interface with its own API. There is NO way you can make the standard Epos driver use this hardware interface. None, nada, niente!
A library needs to be written to interface to a specific API. The Epos driver that you can download from Maxon uses its own private FTDI library to talk to the controller over its USB interface and most likely also through the standard OS tty device interface when you connect the EPOS4 controller through an RS-232 port.
You have two options really.
1) Looking at the CAN protocol documentation for your EPOS4 controller, implement the necessary CAN messages using the VIs that came with your Stratom CAN adapter.
2) Use the USB (or RS-232) port to connect your EPOS4 device, and hope that the Maxon EPOS driver software works. It may not as there are several possible problems. First NI Linux RT which runs on the myRIO is not just some Ubuntu or RedHat Linux but a more streamlined version for embedded operation. The Maxon library may inherently not be compatible with that.
Even if it is in principle compatible, the myRIO uses an ARM CPU and although Maxon provides an ARM version of their shared library, ARM is unfortunately not just ARM. There are many different versions as can be seen in the driver download which has different versions for ARM v6, v7, and v8.
The ARM CPU on the myRIO is a Cortex A9 variant which uses the ARMv7a microarchitecture. So far so good. But that is not enough. The myRIO (and all other NI RIO ARM based hardware uses the so called SoftFP (software floating point emulation) ABI (application programmer interface). Only a shared library compiled both for ARMv7 and softfp mode will be possible to be loaded on the myRIO. Any attempt to load a differently compiled shared library will either fail to load or possibly crash your myRIO.
So you would need to inquire from Maxon if their ARMv7 version is actually compiled with the gcc switches -mfpu=vfpv3 -mfloat-abi=softfp. If it isn't you can't load it on the myRIO. And it may very well not be because such a shared library could not load on an ARM hardware controller whose Linux kernel is compiled to make use of the often present (but in the ARM specification optional) floating point hardware unit.
@antje668 wrote:
If I get access to a driver from Straton that supports the above standard and can communicate in the SDO format, I can send a CANframe to my BUS and control the EPOS 4 controller in this way. However, the information at Straton is a bit limited so I don't know if they have such a driver or not.
No! The EPOS library is programmed to interface to specific APIs. This is the FTDI interface library and most likely the OS tty interface. You can't just push a different driver under this library like that. The only way it would work THEORETICALLY is if Straton would provide a driver that makes their hardware look like a tty interface tot the Linux OS but that is wrought with so many problems that the chance to make that work approach pretty much 0%.
However, the library is supported for Kvaser and I have access to hardware from Kvaser, more specifically this one: https://www.elfa.se/Web/Downloads/_m/an/KVASER%20LEAF%20LIGHT%20V2_eng_man.pdf.
Do you think my life will be easier if I use a Kvaser hardware instead or is myRIO also an obstacle to realize what I want? That is, to control my EPOS4 motor using just myRIO via CANopen.
You still haven't confirmed that the EPOS4 driver from Maxon is actually not only ARMv7a compatible but also compiled with the softfp switch, and it most likely isn't. The decision from NI to use a softfp implementation for their NI Linux RT for ARM OS is not entirely clear to me, but they definitely did so and any shared library you want to be able to use on that is required to be compiled accordingly or it will simply not work.
And that applies to any other library you want to use including the drivers for your Kvaser interface. Unless Kvaser can confirm that they have a driver for the NI Linux RT for ARM platform, you can always try to plug that into your myRIO but it remains a useless piece of hardware on it.
And that Maxon or Kvaser would not know about myRIO or the other RIO hardwares such as cRIO or sbRIO from NI is not surprising. It is a niche platform outside of the NI ecosphere, and supporting all the myriads of embedded controller platforms with its various CPU architectures and OSes is a nightmare that most manufacturers only really are willing to tackle if a large client specifically requires a specific support. And since you are very unlikely to be able to guarantee 10000 to 100000 units per year to be sold, their marketing or support department won't even forward your request to any internal engineering channel.
If you really dare you could always try to download the Kvaser SDK for Linux sources and try to compile your own version on the myRIO to interface to their hardware. It's likely not that difficult if you know about how to use gcc and may be as simple as entering the command line on the myRIO using putty or similar, making sure with opkg that the gcc development libraries and some other dependencies are properly installed on the myRIO and then moving into the top directory of the unpacked software source and calling "./configure", "make" and "make install" on the command line. But this is just a very rough suggestion and unless you feel comfortable to use the Unix command line and have done some compilation before already, almost certainly more pain than you are willing to handle.
I still think it would be actually easier to read the CAN protocol documentation for the EPOS4 and implement that protocol yourself on top of the VIs that Stratum provides. But easier than the other options doesn't mean it is easy. Implementing Open CAN on top of a basic CAN API is not trivial and implementing a device specific protocol on top of that also some real work. But trying to get a click and run ready solution in any other way is even less simple.
The EPOS driver is according to this documentation (See also picture):
Compatible with arm v7, I'm not really sure if that means that it also is compatible with arm v7a I did not get any confirmation that it also is compiled using softlp, I have not found any information regarding that information aswell. However I tried to transfer the library in (.SO format) for EPOS to myRIO via Filezilla and it still not seem to find the shared library but according to what you wrote earlier the reason for this is because the operative system that myRIO is using is hard to work with using external devices which are not from NI (Such as EPOS controllers)
According to Maxon I also need to find out if the X-CAN interface from Stratom supports the aformentioned CAN standards, if the answer is yes then it seems I maybe can have some hope to communicate via CAN.
Since I'm a bit new to both embedded systems and CAN communication maybe the SDK solution can be a bit tricky for me. Are there any tutorilas for this available somewhere.
Regarding the last paragraph that you wrote. I have found some basic Stratom VIs for X-CAN which is used for reading and sending messages from and to the X-CAN interface. Did you basically mean to then put the hexadecimal messages which EPOS studio is using for moving the DC-motor into the read/write VIs for the X-CAN interface?
Apologies in advance if I express myself a bit too simply, I am inexperienced both when it comes to embedded devices, CAN communication and LabVIEW.
@antje668 wrote:
Regarding the last paragraph that you wrote. I have found some basic Stratom VIs for X-CAN which is used for reading and sending messages from and to the X-CAN interface. Did you basically mean to then put the hexadecimal messages which EPOS studio is using for moving the DC-motor into the read/write VIs for the X-CAN interface?
Apologies in advance if I express myself a bit too simply, I am inexperienced both when it comes to embedded devices, CAN communication and LabVIEW.
That's exactly what I mean. Yes it is some serious work and yes you need to understand what CAN is about and how to format the bits and bytes into a CAN frame to make the messages be as the device expects them but that is going to be easier than trying to get the EPOS4 library to load on the myRIO AND connect it to your CAN interface. As far as your Stratom device goes, I would bet that it does not and never will support a device interface that EPOS4 can interface too. The other CAN interfaces that Maxon documents all aren't going to be exactly standard solutions either although at least the Kvaser interface comes with source code drivers so there is a tiny chance that it could be made to work for the myRIO. Still it's not going to be easy even if EPOS4 could be made to load on the myRIO.
Alternatively you could also use NI-VISA to communicate to the RS-232 interface of the EPOS4 controller. The USB access again will be tricky as you would need to be able to get both the EPOS4 shared library as its contained FTDI shared library interface to run on the myRIO, which as already stated repeatedly I have very little hope to be made to work without getting a specifically compiled version from Maxon, and that is a very unlikely option.
Well the Maxongroup VIs only would work if you can get the shared library to load on the myRIO. Since that seems to not be an option according to your own tests (maybe I'll try myself over the weekend) they are as useful as toothache.
This leaves only a few other approaches. The first would be to use the RS-232 interface of the EPOS4 to communicate with it. It allows to send it commands and even to have it relay commands to other EPOS4 drivers that you connect through the CAN bus with the first.
The other option is to use your Stratum CAN interface and use it's VIs to send the CAN messages over it. The advantage of both of these approaches is that you do not have to care about interfacing to shared libraries nor having to deal with the intricacies that this can cause. Eventhough the VIs from Maxongroup are already there, I'm 100% sure they never were tested with the non-Windows shared libraries. It may be as little trouble as changing the library name from <something>.dll to <something-else>.so but unless the shared library was specifically designed with such binary compatibility in mind, it never is that easy. And getting that right is a pain if you are not pretty well versed in C programming. The problem here is if you do something wrong it simply will crash.
With the other two options, NI-VISA over RS-232 and Stratum X-CAN API you have that part fully tested. It might not work if you do something wrong in your LabVIEW diagram but it won't crash.
No! If you use an RS-232 interface you will use the VISA nodes to send your messages to the controller and receive the responses.
CanOpen is a specific protocol on top of the raw CAN frames that specifies a model for CAN devices. Rather than sending raw byte streams that each device defines on their own which bit and byte means what, in CanOpen you have PDOs and other things and CanOpen simply defines where these elements are placed in the byte stream. The product you mention from NI uses their own CAN API called NI XNet to talk to the actual NI CAn hardware. It won’t be able to work with iXXat, Kvaser or any other interface hardware since their drivers each use their own API. And of course NI never had any incentive to make it work with other hardware. NI was in the past a hardware interface manufacturer that sold hardware interfaces and provided the according driver software mostly for free. Additional software drivers were often sold for a few but not to earn money with it but as a service to users of their hardware. The real profit came from selling the hardware.
