Skip to content

PLCnext TCP/TLS connection to Arcus TITAN-SVC-ETH issues

hgoodrichgoodric
edited September 2019 in PLCnext Technology & PLCnext Controls

Issue: I can’t get the TCP or TLS ladder components to connect to Arcus TITAN-SVC-ETH motor controller.

 

Setup:

Laptop: 192.168.1.2

Planet AXc F 2152: 192.168.1.10

Ethernet motor controller Arcus TITAN-SVC-ETH :192.168.1.100, port 5000

Arcus  Stepper motor

PLCnextEngineer

Wireshark Software

Labview (for verifying)

 

See uploaded files for ladder logic

 

  1. TITAN-SVC-ETH uses plain ascii commands via TCP/IP (not Ethernet/IP) to communicate. The wrapper for the commands is “@01:cmd” + CR/LF where cmd is any number of TITAN commands.
  2. Using Wireshark to capture TCP/IP packets between PLCnext and TITAN
  3. Using Labview to verify ascii structure to be sent to TITAN.

 

 

I’m using the TLS components with the security features turned off for now. I was using the TCP components, but that wasn’t working either.

 

My process is to make two TCP port connections to the TITAN from the PLCnext. One is for sending and the other is listening. I activate the two connections, then I activate the TLS_Send to send the command “@01:SAC=40$L$R” which should tell the TITAN to run program #1 which is in the TITAN’s memory. This will cause the motor to rotate 90 degrees.

 

I wrote a simple program in Labview to verify programmatic TCP communications with the TITAN. This worked fine.

When I run the ladder logic program on the  PLCnext, 99% of the time the [SYN] packet does not seem to be sent out by the PLCnext (doesn’t show up in Wireshark). Occasionally, the [SYN] packet from the PLCnext will be sent out, but usually after the program is run after a reboot and then only once. Subsequent deactivation and reactivation of the TLS_SOCKET will not cause a [FIN] or a [SYN] packet to be Otherwise the [SYN] packet is never seen. In addition, when I deactivate the TLS_SOCKET component (even after it has miraculously sent out a [SYN] packet), the [FIN] packet is rarely sent. I never have been able to successfully send the packet with the ascii command.

 

Uploaded are Wireshark files and a screen clip of the PLCnext code. Any help is appreciated.

 

 

Comments

  • Martin [PLCnext Technology Team]Martin [PLCnext Technology Team]

    Hello,

    Can you please check if you can successfully send commands from the command-line of the PLC, using openssl s_client ?

    To do this, you can use PuTTY (on Windows) or ssh (on Linux) to open a secure shell session on the PLC, and then issue the relevant command. (you can get help on the openssl command by typing openssl s_client --help)

    If messages from the command-line work OK, then we can narrow down the problem to the PLCnext Engineer library and/or project.

    ==================

    Looking at the PLCnext Engineer project, there may be a problem with the SOCKET instances. How you set these up depends on how the TITAN unit works. I am guessing it it something like the following:

    • TITAN unit listens for TLS connections on Port 5000.
    • When a TLS client (PLC) establishes a connection, the client can send messages using that connection, and can also receive messages on the same connection.

    If this is the case, then you should only create one TLS_SOCKET instance, with IS_SRV=FALSE and the BIND_PORT parameter left unconnected. Once this socket is connected (ACTIVE=TRUE), you can use the same HANDLE for both the TLS_SEND and TLS_RECEIVE blocks.

    Also, on the TLS_SEND block, you currently have the DATA_CNT set to zero. This parameter indicates the number of bytes of the DATA parameter that will be sent to the server. If this is set to zero, then zero bytes will be sent. You need to set this parameter to the number of bytes that should be sent.

    For the DATA parameter itself, you will need to do this differently. If you pass a STRING variable directly into the DATA parameter, it will convert this to a byte array before transmitting the first DATA_CNT bytes. The problem with this is that every STRING variable contains two header bytes, which will be counted as the first two bytes, and transmitted to the TITAN unit (where they will not understood). You will need to define a new variable as an array of BYTEs of whatever maximum length you want, and then use the TO_BUF function to copy the STRING into that array without the two header bytes. Then, it is this array of bytes that you need to pass as the DATA parameter in your SEND block.

    Hope this helps!

    Martin.

     

  • hgoodrichgoodric

    I found the problem. Is not the PLCnext, it’s the TITAN.

     

    When I ping from a Windows PC, all good. When I ping from ANY Linux based device, the TITAN does not respond to the ping right and sometimes not at all. I have a support email into Arcus.

     

    BTW, I did remove the second TLS_SOCKET function block and added the TLS_READ to the first one. Didn't make a difference.....but now we know why

  • Martin [PLCnext Technology Team]Martin [PLCnext Technology Team]

    That is weird. Best of luck with the project, and let us know if you need any more help with the PLC.

    Martin.

Sign In or Register to comment.