LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TCP/IP access to Siemens S7 from RT (no OPC)

Solved!
Go to solution

Hello,

 

We try to develop a client driver (for PXI RT OS) in LabVIEW using TCP/IP in order to read data (later also send back some) from a Siemens S7 PLC. We do not wanna use the OPC approach.

 

I try to use some example codes from the link https://decibel.ni.com/content/docs/DOC-5467#/ . The problem is that, I always get a "The network connection was refused by the server", code 63. (see 1st snapshot below). So I cannot test any Read/Write functionality since the simple "TCP Open Connection" command is already failing. The IP of the Siemens server is 192.168.4.1, and the PC is set to 192.168.4.2 fixed. The port number for the S7 is set to 2000, and also enabled in the Windows firewall.

 

As a counter-check, I succesfully connected to S7 using LabVIEW example from here (see the second snapshot below):

http://snap7.sourceforge.net/

The only problem with this LV driver set it uses a DLL, and I need to use simple TCP/IP functions since I wanna access the S7 system from a Real-Time OS, so no go for the DLL approach...

 

How it can be that the Snap7 example code works using TCP/IP, but a very simple connection attempt from LabVIEW by the "TCP Open Connection" fails??

Maybe someone could give me a hint or idea what else to try, or what I am doing wrong...?

Thanks very much,

Regards,

 

snapshots:

 

S7Com_OPEN(SubVI).png

 

PlcInfo.png

 

 

0 Kudos
Message 1 of 21
(16,944 Views)

Hello,

 

I made some progress, it looks like the port number was actually not 2000 at the S7 side, I tried port number 102 (found info as it is the default value somewhere), and now at least no error after the TCP Open Connection! 🙂 I go on and try to make more progress with the given examples...

 

S7Com_OPEN(SubVI)new1.png

0 Kudos
Message 2 of 21
(16,932 Views)
Another hint (maybe) it has been a while but I seem to remember that the S7 can use Modbus over TCP/IP. The default port for that service is I think 502.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 3 of 21
(16,911 Views)

I am back because I have -well, at least partly- some progress with the project.

We came to a decision to abandon for now the above LabVIEW community example because we do not understand many aspects of that approach, and we did not have too much success with those example VIs.

 

I do not program the PLC, so I cannot give too detailed info about the Siemens side configuration (hmm, if someone here in the LV forum familiar with S7 PLC programming, would be great... 🙂 ), but a few points:

 

  • There was a "function" (no idea how it is called actually) created on the Siemens PLC side which was configured as a "server" with IP address 192.168.4.1, and set up a "partner" as IP 192.168.4.2 . After this we set the PC to the static IP: 192.168.4.2 .
  • The PLC side was configured that it listens on port number "319". The "partner" port was set as "320".
  • The PLC function was setup to send a data block (DB) via TCP/IP (4 bytes in total, the first 2 bytes represents a number with value "4" meaning the total size of the data block in bytes, and the last 2 bytes is the actual DATA ("9" in the snippet below) for testing, whether we get the right data on the PC or not)
  • So the PLC is sending the above DB (4 bytes total size) with a rate of 2 Hz (always running)
  • The PLC function was configured to have an "input" variable too, to receive incoming data from the PC side (same data structure as the above DB).
  • The while loop executes in 1500 msec (iteration time), I guess there is a meaning it is a integer multiple of the PLC's speed of 500 msec?

After some "playing", we succesfully managed to receive data from the PLC, see the first snippet below.

 

However, we see some issues with the communication in the other direction, from PC to PLC. See the second snippet below. The problem is that, it seems we need to send lots of packages (data blocks) in order to make the DB value at the PLC side updated. What is very interesting, it seems the TCP/IP Send rate has also an effect: if we run the While loop with a high rate of 5 msec for example, the PLC will not react at all for the new value. Edit here: actually if the rate was too high, we started to see some "garbage" bytes apearing at the PLC side, like the data blocks were not properly processed?

 

If we send it too slow, then we do not have enough "trials", so takes too much time to update the PLC variable (DB). After some trial and error, we figured out a rate of 50 msec seems to work. But we need to send like 100 Data Blocks (same value 100 times), meaning like 100 iterations of the while loop needed! It means like it takes like 5 seconds to change the value at the PLC side. It looks like many data blocks are lost, or something...? I feel we are very close to a final solution, the PLC-to-LabVIEW part is already working...

 

Anyone has an idea what we do wrong? Even some hints could be useful... Thanks very much!

Plus info: we ran the two VIs below at different times, not in parallel.

 

TCP_Listen_Read_bytes_version1.png

 

Sending data to the PLC:

 

TCP_Listen_Send_v1.png

 

0 Kudos
Message 4 of 21
(16,856 Views)

Another thing we will try, to have two "functions" instead of one on the PLC side: one exclusively for outgoing connections, and another for incoming ones (and separate port numbers as well). No idea though if it will help...

0 Kudos
Message 5 of 21
(16,841 Views)

I am back since we finished the project everything works as we planned, except some problems with the key part, the interface between the Siemens S7 PLC and the master PXI unit.

 

Just a little info about the used network: local network using the same subnet via a Siemens industrial grade network switch. We have the following components on the switch:

  1. Siemens S7 PLC network card (IP: 192.168.4.1)
  2. PXI master unit (192.168.4.3)
  3. PXI slave unit (192.168.4.4)
  4. Laptop with LV2015 32 bit plus RT for dev and deployment (192.168.4.58)

Up to 14 Keithley picoamp meters can be connected to each of the PXI units via a GPIB card. The two PXI units communicate via LabVIEW Network Streams, very reliable, never seen any problem (the communication programmed in the way it can auto-recover after any network problem or even if a PXI needs a reboot/power out; same for the Keithley units: any device can be added/removed from the network "on the fly", the code handles these scenarios).

 

The LabVIEW RT code on the master PXI communicates via simple TCP/IP protocol with the Siemens PLC. It should every second send the collected measurement data plus some status flags (error info for each Keithley units, alive GPIB ports, communication status between the two PXI, etc.) to the PLC. Before every TCP Write function we have a Read function too, and we monitor for rising edge of some flag bits, meaning for example a zero-correction request toward a picoamp meter, or Voltage output setting value, etc...So every second the PLC sends this data block to the master PXI, and when a command needed to execute, it flips the corresponding status bit to true for a few seconds, which "rising edge" we can capture at the PXI side even if there are lost data packs on the network (such commands will not be frequent, so we do not need fast reaction here).

 

Ok, now about our problem (sorry if I gave maybe too much details above, but it might help you to help me 🙂 😞

we did not do exact statistics yet, but at certain times when the master PXI reboots, we cannot get proper TCP data at the Siemens side. We see at the first/second iteration that the data coming into the PLC is OK, and after it is just garbage. No TCP error at all, simply garbage data appears at the PLC side. After PXI rebooting it might just start to work fine, but after another reboot of the PXI we get garbage again, etc... (The data coming from the PLC to the PXI looks ok, but first we want to investigate the PXI_to_Siemens comm).

 

I just do not understand why this comm is not deterministic, sometimes just works and other times just not. I understand the above info is probably not enough, since the problem easily can be at the PLC side, but I might be able to provide info regarding to the PLC program side if someone is familiar with Siemens S7...? A colleague programmed that part, I could ask for the code to show it here...I wonder if someone might give me hints how to investigate this problem, since we do not have error at the LabVIEW side, it is just the data what "can become" garbage sometimes arriving to the PLC side, and no idea why it works or other times why not...? I provide some snippets, sorry about the looking, but I just had to cut out the non relevant code parts, and showing mainly the TCP loop running on the master PXI RT unit:

 

EDIT: another "symptom": the loop time of the TCP while loop is about 1500 msec, also strange why it cannot keep inside the required 1 sec...might also indicate TCP comm problems on this network???

 

PXI_to_S7_TCP_IP.png

 

Error case:

TCPIP_error_case.png

SubVI:

Combine TCP-Feedback_BD.png

0 Kudos
Message 6 of 21
(16,616 Views)

First I have to point out a Rube Goldberg in your code.  Specifically, where you turn your PXI status into a number.  You can just use a simple Boolean To 0,1 to do all of the work of the creating an array, replacing an element, and changing back into a number.

 

As far as figuring out your issue, I recommend bringing in another computer with WireShark.  WireShark is a network monitor application, so it can tell you who sent what with what errors.  It can at least tell you if the PXI is still sending good data or not and you can figure out where to look from there.  Or perhaps there is extra traffic happening somewhere else messing things up.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 7 of 21
(16,608 Views)

@crossrulz wrote:

First I have to point out a Rube Goldberg in your code.  Specifically, where you turn your PXI status into a number.  You can just use a simple Boolean To 0,1 to do all of the work of the creating an array, replacing an element, and changing back into a number.

 

Yes, you are right about this, but later this code part will be modified, and other bits of the Word will be modified too, that is why we already put there the replace element in array function.

 

As far as figuring out your issue, I recommend bringing in another computer with WireShark.  WireShark is a network monitor application, so it can tell you who sent what with what errors.  It can at least tell you if the PXI is still sending good data or not and you can figure out where to look from there.  Or perhaps there is extra traffic happening somewhere else messing things up.

Yes, we will try this way, if LabVIEW sends correct msgs, then the problem must be on the PLC side...Is there someone familiar with S7 PLC prgramming? If so pls reply, and I can provide the PLC code part too...

About the extra traffic: we have also LV Network Stream data com between the two PXIs, but we already had problems with the TCP/IP even before implementing the NS code in our system...No other communication is ongoing in the network.


 Edit: and about the 1500 msec iteration time: I guess it is also to do something with the rates at the two sides. Since we do not have tight sync, and the PLC send data packs at every seconds, we cannot Read/Write the data from/toward the PLC from the LV side at the same rate...? Hmm, I am not sure about this...We could try to speed up the PLC code side, maybe to iterate it at 4 Hz...

0 Kudos
Message 8 of 21
(16,603 Views)

It looks like the problem is on the PLC side... We always write 122 bytes properly from LV via TCP/IP, and read 32 bytes coming from the PLC. What is very interesting, sometimes we start the system, and everything works. Other times we only get valid data (32 bytes) coming from the PLC, but we see garbage on the PLC side (122 bytes). What is interesting, if we re-initialize the TCP/IP communication, it starts to be OK again...We try investigate this strange problem further...

0 Kudos
Message 9 of 21
(16,575 Views)

I have been working on some code recently to directly communicate with an S7 through their TCP/IP ISO protocol. It isn't officially documented by Siemens, but there exist several open source C libraries that do a more or (often) less good job about communicating through that protocol. Your initial library from the community also does use that protocol, which the S7 PLC is listening on port 102.

I would also like to mention that there is actually a library from Data Ahead on the Tools Network SP7 Toolkit which implements that protocol and seems to work as advertized.

This allows to directly setup DataBlocks (DB) to communicate between the PLC program and your application.

You seem to have abandoned that approach and instead the PLC programmer used a custom function block which implements its own TCP/IP server interface. Why that would show these strange problems I'm not really sure, but after having written many TCP/IP related libraries in LabVIEW, I'm pretty positive that it is not something inherently wrong in the LabVIEW TCP/IP functions.

Rolf Kalbermatter
My Blog
Message 10 of 21
(16,566 Views)