NI IC-3173 Industrial Controller parallel ethernet communication with PC and other devices (LMI3D Gocator)

[Twinsy]

I'm using an NI-IC-3173 industrial controller with a Gocator 3D scanner.
The main technical task was to connect the Gocator with the NI IC. Scanning with PC was possible, but only for a certain phase with low performance. The PC was unable to receive the amount of data from the Gocator and for further precision scanning I want to use the Gocator on 100% performance. To solve the issue, I wanted to setup the system, showed at 1. Figure, where the Gocator streams the data with 1-1500Hz frequency, what the NI IC RIO stores in a FIFO buffer then pass it to the FPGA for process. The processed data is saved later in the Data storage.

The company who made the Gocator LMI3, provides an SDK for further development. From the SDK, they compiled .dll-s and in Labview they use the Call Library Function module to call the compiled functions in the libraries written in the SDK.

The first problem was, that if I wanted to deploy the Labview project to the IC, obviously the .dll-s haven’t worked, because the operation system is Linux. To recompile the SDK to NI Real-Time Linux Shared Libraries (.so file extension), National Instruments provides a solution and a tutorial also, which I was aware with. However, that solution is only possible with Eclipse projects and our SDK was in Visual Studio solutions. I found the solution where I deployed the SDK to the IC and recompiled everything there, because I had a .mk file in the SDK for linux useage. The deployment of these libraries is necessary, due to the fact, when we deploy a Labview project, the .dll-s and .so-s are transparent. The deployment of the shared libraries was done through SSL into a specified directory, where they are loading automatically during IC boot (/usr/local/lib/).
I had to modify and rewrite all the functions given by LMI3 in the SDK, because of the change of the shared libraries path. As you can see in 2. Figure, every CallLibraryFunction module must be set to call the relative path of the shared libraries.
I arrived at the last phase before the actual scanning. I set up the communication protocols and when I run the VI, I lose connection with the IC.

So, simplified summarization:

• The shared libraries (.so) compiled in the right way
• The shared libraries (.so) on the IC are on the right place and can be reached
• The shared libraries (.so) are called correctly during the process
• The connection with the Gocator and NI IC is good, because I receive the setup information of the Gocator at the start
• I can turn on and off the scanning sensors of the Gocator from the NI IC
• There is a problem, when I start receiving the Scanned profile information (receive blank information then disconnect)
• There is no overload of the NI IC

I also applied some tricks, that the Camera is plugged in to the primary ethernet port (eth0) and the PC is in the eth1 port. The camera (192.168.1.10/24) and the IC-eth0(192.168.1.9/24) port are in a different sub-net then the PC (192.168.0.10/24) and the IC-eth1 port (192.168.0.9/24).

I only loose connection when I connect to the device (it is done) and the next function I should recieve data-stream from the Gocator.

I want to make it clear, that it works on PC on 100%!

I tested almost everything, that the shared libraries are good, the functions are good. This issue is a NI Industrial Controller issue, because of the communication.
We had the same issue with another device (a phantom arm for a Comaou robotic arm), however in this phase it works (with alot of glitch), but with this device doesn't.
I'm using Windows 10 64x with Labview2016 32x.

Any idea? We have no error in the logs.

[LiciaP]

Hi,

just to confirm I've correctly understood: when you address the scanner from the RT application running on the IC, connection to IC from the host computer is lost.

You connected the host computer to the secondary ethernet port (eth1).

Do you obtain the same behaviour if connecting the computer to port eth0? Consider this.

Bye

Licia

[Twinsy]

Hi,

Thank you for your answer and link. Yes, you understand it right.
I was aware about that, what you linked. I tried both ways (switched off the eth ports) and the same happens all the time.
However, I can send orders (start, stop function arrives) to the device, but cannot recieve data. I thought about some port or stream blocking in the IC.

See ya
Tamás

[666mille]

Hi Twinsy,

I know this thread is over 4 years old......

I want to do exactly the same thing. Can you told me how do you have compiled the framework? Which tools do you have used?

Thank you very much!