TCP/IP server/client Comms

[zed]

Hello fellow UL fans,

I'm looking for some help or an example for using the TCP Rx ladder function.  I have a sense of how to trigger COM Rx for a serial connection by looking for an ASCII  control character such as CR or LF but not sure how to do this for a TCP Rx since the system struct for TCP client is different (snip below) than the USB serial struct.  The help file contains very little on the subject and I was not able to find anything on the forum and my comms experience is rather limited.

I'm also wondering how the TCP Connect ladder function should be executed.  Should that be triggered only once (edge trigger or set in/reset out) and await connection or should it be triggered continuously until a connection is established?

In my application the PLC is the TCP Client and the TCP server is a checker weigher which will send individual pack weights as they pass over its load cell in the form of <STX>341.6<ETX><cr><lf> where 341.6 is weight in grams. Packs are weighed at various speeds from 30 to 120 per minute.

Kind regards,

 

[Joe Tauser]

Let's start with your second question first.

Don't trigger the TCP Connect Continuously.  Each time you call the block it will spool a new Connect.  If there was already a Connect in progress you will destroy that effort with the new call.  You just have to wait a little bit.

Using my State Machine method in my Modbus TCP Reads subroutine (Step #10),  first I tap the Connect block with a pulse every 100 ms, which is a long time in Ethernet land.  When the socket's .IsConnected bit comes on I move onto the next step - 

 

In my Modbus subroutine, there's a lot of blah, blah, blah in-between connecting the socket and listening for the response, which occurs in Step #40 -

 

You don't trigger the TCP Client Rx block, you enable it.  It will sit and listen until something comes in at which time it will set the Response Received bit (Output D).  At that point the listening stops.  Whatever comes in will be in the buffer, it's actual contents are irrelevant.  That's up to you to decode them elsewhere. 

In my program I move onto the next step and deal with the buffer contents.  Then I clear it out and reset the response received bit. 

If you're only dealing with one device you can leave the socket connected and re-enable the Rx block.  In my case I'm talking to multiple slaves so I disconnect and start the process over with a different slave ID.

Joe T.

 

[zed]

Perfect! Thanks Joe!

[hotwires]

A related question. I have constructed a working AB Compact Logix Ethernet IP CIP PCCC driver usingTCP CLIENT connect, message composer, build message, copy to buffer, TCP TX, TCP RX,  etc. It polls and receives two REALS from CPX and brings them into Unistream REAL’s. I use FSM pointer in decade steps. QUESTION is: does the program scan make a second pass before updating and executing the next finite state machine block? Example: rung “pointer” UINT8 = 10 (true) -> TCP TX -> STORE #20 to tag “pointer” UINT8. So the TCP TX happens in that scan. Next rung is:

EQUAL tag “pointer” to #20 (true) -> TCP RX -> STORE #30 to tag “pointer” 8UINT

Point is if a ladder scan advances the FSM pointer thru each rung in one scan, no waiting for data received bits or the like… does the scan only execute the first true FSM rung OR does it instantly update the pointer register (accumulator) and execute the next rung in the same scan. I am running a TCP error checking region at the top of a unilogic function, will it make a pass at the top and detect link lost between executing sequential subsequent rungs? Or does error checking logic need rungs between each FSM rung? Let’s say in this TCP communication driver. 
 

[Joe Tauser]

The pointer register is updated immediately.  The equal block in the next rung will solve TRUE if the condition is met.  Sometimes my State Machines run too fast and will zip through all the steps before the communication blocks (which are separate threads) update.  Interlocking the State scan with "done" bits is crucial.  Even so, every now and then I add a short (50 ms) timer between steps to slow things down and allow a couple of scans to happen so other parts of the program have time to react to the data I've received.

Joe T.