Unable to load shared library 'EposCmd.dll' on sbRIO 9267

[antje668]

But I dont think my CAN hardware (X-CAN) is created by NI, I think it is a standalone product from Stratom. Stratom do seems to be a reseller for NI though, so it may be can be as you stated that X-CAN uses the NI XNet APi, but I'm not really sure. I have contacted Stratom but haven't got any response yet.

[rolfk]

---

@antje668 wrote:

But I dont think my CAN hardware (X-CAN) is created by NI, I think it is a standalone product from Stratom. Stratom do seems to be a reseller for NI though, so it may be can be as you stated that X-CAN uses the NI XNet APi, but I'm not really sure. I have contacted Stratom but haven't got any response yet.

---

I don't think they were able to convince NI to support their hardware with the NI XNet API. 😁 I would never even have considered that option.

The somewhat similar naming of their hardware with the NI API is more likely caused by some amateuristic marketing from Stratom. on the other hand:

https://fccid.io/MSIP-REM-NAT-MYRIOCAN

The FCC record seems to indicate that it is actually manufactured by NI but under the name of Stratom. Things start to look strange. Still if they didn't intend to sell it under their own name, they probably also didn't even consider making it a supported product of their standard drivers.

[antje668]

Yes, it looks strange indeed.

But if X-CAN doesn't use NI's API (NIXnet) and instead uses the API that the EPOS4 controller uses, then I actually have a way to communicate with my controller through SDO read and SDO write. X-CAN not using NIXnet would therefore be good news for me.

Otherwise, if X-CAN uses NIXnet, shouldn't that be impossible? The reason I am speculating is because I have not yet received any confirmation whether X-CAN follows the CiA (CAN in Automation) standards.

[rolfk]

The X-Can hardware most likely only supports its own API, the VIs that you get with it. 

But I can't verify it. The Yotta page says "Includes software API (see Resources tab)" but by the Gods I can't find such a tab anywhere.

[antje668]

Yes, this is indeed a mystery.

I managed to find this in LabVIEW:

Can I conclude with what I have underlined in yellow that X-CAN actually uses its own API and thus not NI Xnet?

If so, I can't be quite sure if I can even use X-CAN to communicate with EPOS4 controllers?

[rolfk]

---

@antje668 wrote:

Yes, this is indeed a mystery.

I managed to find this in LabVIEW:

Can I conclude with what I have underlined in yellow that X-CAN actually uses its own API and thus not NI Xnet?

If so, I can't be quite sure if I can even use X-CAN to communicate with EPOS4 controllers?

---

Actually you put it completely upside down. This API uses underneath the SPI functions to communicate with the hardware (since the interface is using an SPI link). That is independent of NI-Xnet or whatever.

And that has nothing to do with if you can communicate with a CAN device. This X-CAN API provides you with functions to open a session to the hardware and write CAN frames to it and read CAN frames from it. This is the low level API of every CAN hardware but in order for another higher level driver to be able to use it, that driver needs to be written to use that specific API. Since the X-CAN API is specific to this hardware there is no other software that will know about this hardware. Only these LabVIEW VIs let you communicate through it.

And since an OpenCAN frame is in principle also just a CAN frame you can of course use the X-CAN API to communicate to your EPOS4. You just need to figure out how to construct proper CAN message frames that the EPOS4 does understand and to parse its responds correctly. If I would have to do it I would do a two layer approach, first a more generic OpenCAN layer and on top of that a specific EPOS4 layer.