Issues when Using Ethernet/IP and Network Streams together

[jrayeske]

Hello to all you brilliant people on the forums.

I am working on a project that involves a cRIO which will eventually be installed into a test cell with a PLC and a PC.  The cRIO uses a TCPModbus Slave to allow single points of data to be communicated between itself and the PLC and/or PC.  I also included a Network Stream to pass waveforms to a diagnostics application that will run on the PC.  All of this works very well, so if it's not broke it needs more features, right?

I decided to also include Ethernet/IP communication to the cRIO.  This would simply be another option for the PLC to pass data to/from the cRIO using explicit messaging.  I created the modules and ran them on a test VI and all was well.  After adding the Ethernet/IP modules to the main RT application the PLC returned a connection error.  The Modbus communication was still working.  After some head scratching I found that if I removed (not just diagram disable) the VI that included the Network Stream, the Ethernet/IP communication would work.

My question is, should Ethernet/IP and Network Streams coexist on the same target without issue, or was the issue I'm seeing expected?  I would love to get your thoughts and thank you for your time.

LabVIEW 2018 (Software Platform Bundle)

NI-Industrial Communications for EtherNet/IP 18.0

NI-9068 cRIO

TCPModbus API is part of the DSC Module

Kind regards,

Josh

[bseguin]

Just a little thought... did you set different TCP-IP port for different protocol?

Benoit

[jrayeske]

Benoit,

I did not specify the ports for each communication type.

Modbus is on port 502 (default).  I do not see how to set a port number for Ethernet/IP and changing the port for Network Streams requires changing/creating an ini file on the target.  I did some quick searches which states Ethernet/IP uses port 44818 for explicit messaging (TCP) and Network Streams use TCP ports 59110 and up.  From this site (http://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/createditlogosxt/) it states by default the Linux RT should check ports 59110 thru 59210.

Josh

[rolfk]

Definitely an interesting observation that Benoit brings up, except that the Ethernet/IP client functions should not require a specific port itself. Ethernet/IP communicates to a specific port number 0xAF12 on the server but the server is here the PLC and you cannot use the Ethernet/IP VIs to act as server at least when using the Tag based VIs. So are you only using those or are you setting up an Ethernet/IP assembly instead, because in that case things could be indeed different, but I have no experience with that part of Ethernet/IP.

[jrayeske]

The application is using the I/O Data EthernetIP VIs.  EthernetIP Add Assembly Instance (Instance 100, Producing, 10 bytes) and EthernetIP Set Assembly Instance Data.

[rolfk]

---

@jrayeske wrote:

The application is using the I/O Data EthernetIP VIs.  EthernetIP Add Assembly Instance (Instance 100, Producing, 10 bytes) and EthernetIP Set Assembly Instance Data.

---

That might be a handle. In that way I do believe it is setting itself up as server too. Not sure if that will happen on the well kown Ethernet/IP port, but it seems reasonable to assume that that is the case.

[jrayeske]

An update with a resolution.

I had time to revisit this project and I'm happy to report that everything is working now.  This is what I found...

The conflict was not entirely related to using Network Streams.  One change I did make was to have a short (500ms) timeout on the "Create Endpoint" followed by a 4s dwell before looping back to the "Create Endpoint" again.  This change allowed for everything to work when I ran the Main.vi on the cRIO from the project.

After building the RT application and deploying it to the cRIO, I again lost the Ethernet/IP communication.  The more frustrating part of this was neither the PLC nor the cRIO were showing errors, which would lead one to believe they were communicating, however, all the values were 0.  Starting over with very basic VIs and deploying built RT applications with each additional feature, the communication loss came when I included the FPGA reference and related calls.  The cRIO was in FPGA  Interface programming mode.  The fix, or work-around, was to add a "dummy" module to the "Real-Time Scan Resources" while keeping the programming mode set to FPGA Interface, Deploying (right-click Chassis (cRIO-9068) and select deploy), re-compile the FPGA code since the chassis settings have changed, rebuild the RT application and re-deploy that.  A quick chassis restart and viola!

Now, I do not understand why running the FPGA in Hybrid mode allowed for the functionality in a RT application that I had when running the VI from the project with the FPGA running FPGA Interface Mode only, but the fact that it works now is one less WTF that will keep me up at night.