AG_RCV on a TCP connection with a Scanner (S7400 + Zebra)

[userxyz]

Hi all,

I have PCS7 project where I need to link Zebra scanners. The Zebra scanners are equiped with serial->ethernet converters also from the brand Zebra. The Zebra adapters can only connect via TCP. First I wanted to use the T blocks, but after I while I tried to make a TCP connection in Netpro. And when checking online I can see Established in Netpro on the connection. Then I placed a AG_RCV block in OB1 and tested to receive data. The bahaviour is odd... after scanning several times I have data in de receive DB. But the data is messed up versus the real barcode I have scanned. Some data is missing and it is shifted as we. I have to scan more then 4 times before I receive something also... Something is wrong... donno what yet...

Here is a screenshot:

 

[Thomas_v2]

That behaviour is because TCP is stream based.
If your scanner sends some data, it fills the internal buffer of the CP. If the number of bytes you have given at the RECV parameter are in the buffer, the AG_RECV copies the internal buffer to your data at the RECV parameter and sets NDR to true.

If your printer send for example 20 bytes fixed length, and the RECV parameter is 50 bytes size, then the AG_RECV says NDR=true when min 50 bytes are in the buffer. This will result in 2 and a half scans in your data at RECV. The next half will enter after 2 new scans and so on.

An easy solution is, when your scannercan send telegrams of fixed length of 20 bytes for example. Then reduce the array at RECV to 20 bytes and you are done. If the scanner send only once a telegram smaller or bigger than 20 bytes, then you are "out of sync".

Another solution is when the scanner send a fixed length header of 2 bytes for example. Then you read the first 2 bytes, and then call the AG_RECV to read exactly this number of bytes.

Or when you have a end delimiter, you also can read a single byte with AG_RECV, copy it into a buffer inside your plc program until you read the end delimiter, and then process the buffer. This may be slow when you only read one char every cycle.

 

[userxyz]

Hmm

Hi Thomas,

Thank you for your reply.
I know that the codes that I must read are allways 7 chars. But indeed, when they scan someting different, I will be out of sync. Therefor I am wondering, isnt there a flush buffer or clear buffer memory function ? Then I could scan, and readout the code and after the readout flush/clear the memory.

If no flush/clear exsists, could a AG_CNTRL men anything to connect on moments we need the scanner... ?

About the idea of reading every character,... How big is the buffer in the background, is this 254 bytes ? Could I make a loop to read every char with AG_RCV until we don't have the NDR anymore or until we have an error or until we have no data anymore ?

Thanks for your help,
Combo

 

[Thomas_v2]

The AG_RECV finishes reading when the same number of bytes as your any-pointer at the RECV parameter are received. This is the same when you are using sockets in PC programming, TCP does look easy but making it robust is not so easy.

The only solution to reset the communication when you are out of sync is to reset the complete TCP connection via AG_CNTRL your case.

If the length from the scanner is not fixed, I'd read with AG_RECV one single byte and copy this into an internal buffer until any kind of end delimiter occurs. To make it faster you could try to read one byte as long as there is a byte in the buffer in one cycle. With this you have full control, and you can flush your internal buffer whenever you want.

I haven't used the Zebra scanners, but I've used some other scanners which I've configured to allow scanning of only a specific type of barcode.

 

[userxyz]

It works !!!

Hi Thomas,

It works...
When I do a reset with AG_CNTRL and I look in NetPro the connection is Closed while the bit ACT is True. When I reset this bit, then I have Established in NetPro. After each scan I set this ACT on 1. When I need to scan I set this bit on False. Then the scan is allways okay when I scan a barcode of 7 chars in my pointer with length 7. Is this okay todo this way ?

 

[Thomas_v2]

For me it's a little hard to kill the TCP connection every time as it takes a small moment to re-establish the connection. But if you don't need the data too fast or at least someone does a second scan when the first fails, maybe it's ok.

I'd definitively try out some cases:
- What happens if someone scans a barcode with more or less than 7 bytes
- What happens if someone scans fast many barcodes (small ones)
- Try what happens if you disconnect the network cable. A best test is when you disconnect at a location where the endpoints don't see a loss of link. For example: Scanner - Switch-1 - Switch-2 - S7. Then disconnect the cable between Switch-1 and Switch-2.

 

[userxyz]

Hi

Hi Thomas,

Yes I will do these stresstests tomorow.

Actually the Scanner is connected to a CP443-1 and is used in a PCS7 SFC program. So I will need to put does both blocks into a block that can be used in CFC and that we can control from SFC steps. The scanner is used for checking that the products that the operator needs to add matches with the Batch recipe product. So in a certain step the product needs to be added and in that step I would establish a connection. The operator scans and then needs to confirm also with a button that he scanned the product, after pressing that button the comparison must be equal, otherwise we jump to a disconnect step for 3s, then we go back to the scanstep where we establish a connection and prompt the operator to scan. So the moment of scanning and the length of scanning is known. The scanner does not need to be active all the time. When the connection is closed, and we take a scan, you can hear a different beep with a red light, wich is pretty good to inform that the scanner is not needed in that moment.

I also asked SIemens if its okay to establish a connection when needed and only when needed. To me this is a simple way. Byte by byte is difficult way.

BTW, Siemens gave me the support number: 8707570, wich shows a block for reading variable length data, but it also works with byte by byte processing I think.

Thanks,

Kind regards,
Combo

For me it's a little hard to kill the TCP connection every time as it takes a small moment to re-establish the connection. But if you don't need the data too fast or at least someone does a second scan when the first fails, maybe it's ok.

I'd definitively try out some cases:
- What happens if someone scans a barcode with more or less than 7 bytes
- What happens if someone scans fast many barcodes (small ones)
- Try what happens if you disconnect the network cable. A best test is when you disconnect at a location where the endpoints don't see a loss of link. For example: Scanner - Switch-1 - Switch-2 - S7. Then disconnect the cable between Switch-1 and Switch-2.

 

[userxyz]

Siemens response

Siemens response