Skip to content

Trouble with TCP and UDP socket

bigstuckbigstuck
edited April 2021 in PLCnext Technology & PLCnext Controls
I want to receive data from different devices to my TCP or UDP port of AXC F 2152.
Try to use TLS_Socket_2 with TLS_Receive_2, or UDP_Socket_2 with UDP_Receive_2.
Try to use them both simultaneously and separately, the result is the same.
[attachment]Socket.png[/attachment]
The socket status is good (TCP configured for server and listening all IP's, Status - 8001 Server is listening for a client. UDP Status - 0000 Situation is normal (no error)).
But the TLS_Receive_2 and UDP_Receive_2 have the same error (C210 - The application tried to send or receive data, and the socket is not connected.)
Bind_IP - is my plc AXC F 2152 IP address.
Try to sent TCP and UDP packets from my PC, nothing changes (the same error C210).

AXC F HW: 02 FW: 2021.0.3 LTS
PLCnext Engineer 2021.3 (Build 4.9.232.0)

Comments

  • Martin [PLCnext Technology Team]Martin [PLCnext Technology Team]
    Can you please try connecting the EN_R input of the Receive blocks to the Active output of the corresponding Socket blocks?
    From memory, the Active output should go True when a client is connected, for TCP at least. I thought UDP was connectionless, so I am not sure why it is giving that error.
  • bigstuckbigstuck

    Socket Output Busy is always True, Active - False.
    Maybe client software is wrong? But I've tried several clients, and nothing changes.
  • bigstuckbigstuck
    Reconfigure to use PC as a server and PLC as client.
    On PC side I run TCP server and even see client connection from PLC.
    But the situation is the same. Socket Output Busy is always True, Active - False.
    So can't send data to server.

  • Martin [PLCnext Technology Team]Martin [PLCnext Technology Team]
    I have reproduced the server problem here, at least. It should be possible to connect any TCP client (e.g. telnet, or another TLS_SOCKET instance) to the TCP server in PLCnext Engineer, but I also never see the ACTIVE output go true (PLCnext Engineer 2021.3 with AXC F 2152 FW 2021.0.3).
    I have passed this to the PLCnext Engineer support team, and I will let you know when I have more information.
    ~ Martin.
    (ref: #211435)
  • Martin [PLCnext Technology Team]Martin [PLCnext Technology Team]
    OK, I finally have some answers.

    In the PLCnext Engineer help system, it mentions that the TLS_*_2 FBs (and the UDP_*_2 FBs) cannot be used on PLCs with firmware versions earlier than 2021.3.
    Since firmware version 2021.3 has not yet been released for most devices, that explains why these FBs do not work properly on most current PLCs.
    I have asked for future versions of these FBs to return an error when they are being used on a PLC with an incompatible firmware version.

    That leaves the question - since the "old" TCP and UDP function blocks no longer appear in PLCnext Engineer 2021.3, what is the solution for cases like ours?
    Answer: If you click on a code worksheet, and type TCP_SOCKET, then press Enter, an instance of the "old" TCP_SOCKET FB will be created. The same method can be used for the other TCP FBs, and for the "old" UDP FBs. You need to type the complete FB name - they do not appear in the auto-complete menu.
    I have also asked that this work-around be documented in the PLCnext Engineer help system, so that users have a chance to find this information in future.

    I hope this helps.
  • bigstuckbigstuck
    Some kind of progress in this task.
    Used old blocks.

    Can't receive first 4 symbols, and a lot of trash after sent packet.
  • Martin [PLCnext Technology Team]Martin [PLCnext Technology Team]
    It looks like you're using a variable of type STRING as the DATA In/Out parameter on the RECEIVE FB.
    That won't work unless the first 4 bytes of your TCP message are the header bytes of an IEC STRING variable, as described in the PLCnext Engineer help:


    The alternative is to pass an array of bytes as the DATA parameter, and then use a BUF_TO_STRING function block instance to convert the byte stream to an IEC STRING, which automatically takes care of the header bytes.
  • bigstuckbigstuck
    Thx a lot. You are doing great PLC with many possibilities. A little bit more examples with simple things will help us great.
  • Martin [PLCnext Technology Team]Martin [PLCnext Technology Team]
    Thanks for the feedback.
    Apart from the many e-learning modules and examples developed by Phoenix Contact, the wider PLCnext Community has also contributed quite a few examples of how to use features of PLCnext Technology. If you think that a simple example showing how to use TCP and/or UDP function blocks (or any other feature) would be useful for others, then perhaps you will consider creating a short Makers Blog post:
    https://www.plcnext-community.net/en/hn-makers-blog.html
    ~ Martin.
  • ingfuingfu
    https://forum.plcnext-community.net/discussion/comment/8316#Comment_8316

    Hi,

    although it's an old thread, my question fits here. Can the old TCP_SOCKET FB still be used or am I supposed to exchange them for the new TLS_*_2 FB? What was the reason for the deprication?

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

    I think the reason that the old FB was replaced was because TLS sockets were required, and since the function of TCP and TLS sockets share so many features, it made sense to implement them both as one FB.

    If you have an old project that uses the TCP FBs, and if that still works OK, then you should be able to continue using it. All new projects should use the TLS FBs, even if you use TCP and not TLS sockets.

Sign In or Register to comment.