Question about developing an sbRIO-9608 in LabVIEW

[syoshinsya]

Hello.
I am currently working in LabVIEW.
I am developing an sbRIO that calls a device driver and communicates with an FPGA.
At this point, I have reached the point of deploying a VI to run on sbRIO, but I get the message "Communication Error occurred" and the connection is disconnected. The device driver has been tested with other tools, so it is probably not the problem.
It is possible that the software installed on sbRIO is not appropriate, but are there any other possible causes for the problem?

Translated with www.DeepL.com/Translator (free version)

[rolfk]

What sort of device driver are you talking about? Where has this device driver been tested? On the sbRIO or some other system? If on the sbRIO, how was this testing performed?

[syoshinsya]

Thanks for the reply.
The device driver is mounted on the sbRIO along with the VIs and mediates the reading and writing to the FPGA that connects to the sbRIO.
The device driver alone is tested on a separately prepared Ubuntu PC with a separate program for testing.
For testing on sbRIO, we call the device driver (.so) created in C language from VI using "Call Library Function Node". However, when I try to call the open method of the device driver to start communication with the FPGA, a communication error occurs and communication is cut off.

I am not confident in my English, so I am using machine translation.
I'm sorry if I didn't get the meaning of your reply.

[rolfk · Accepted solution]

You can't simply take a shared library compiled for Ubuntu and copy it to the sbRIO. Ubuntu is a desktop OS and it is the question if your shared library is a 64-bit binary. The sbRIO runs NI Linux RT which is in several ways different to your Ubuntu desktop, including but not limited to a different kernel, different libc and a lot of other different libraries.

Even if your shared library is compiled for 386_x64, it doesn't mean that it will be loadable on NI Linux RT. You might have to recompile the sources on the NI Linux RT system or with the Eclipse based cross compilation toolchain that you can download from NI. 

[syoshinsya]

I had already tried to recompile the sources on the NI Linux RT. But It wasn't right run. So I understand that need to try with the Eclipse. I will try!

Thank you!

[rolfk]

---

@syoshinsya wrote:

I had already tried to recompile the sources on the NI Linux RT. But It wasn't right run. So I understand that need to try with the Eclipse. I will try!

Thank you!

---

No, if it doesn't run when recompiled on the sbRIO with the full gcc develop package installed, then the Eclipse built is very unlikely to make it better. Cross compilation is always an extra potential problem, so if possible compiling directly on the target is always more likely to produce a correct working binary.

But if you did that you may have to check the compile results. Just because the compile went all through and actually did create a binary, doesn't mean that it did not find potential problems. Every compiler warning is something you need to check and judge if it is just a harmless warning or something indicating potential problems.