1756 Socket Communication - Transfer Time

belph

Member
Join Date
Jan 2014
Location
Prague
Posts
27
Hello everyone,

Recently I am dealing with one challenge. It is all about Transfer Time in Socket communication.

AOI from RA library is used for DATA Exchange PLC 1756 L71 and Inkjet Printer.
What is crucial in this application is transfer time, which has to be as short as possible.
In very fast period approx 30-40 boxes per minute Scale has to do update of new data which receives over socket comm.
Date Exchange sequence is working correctly but it has got one serious issue.

Transfer time I mean time from open socket to write and read action varies from 500ms - 2 seconds.

Setup for this application :
special 1756-EN2T is used only between PLC and Printer connected by one eth cable.
Task is running in period 20ms.

Does anyone have ideas how can it be improved or what might cause this variation ?
Is it something that I missed in it so far ?
I am running out of ideas.

Every advice appreciated!

Cheers!

Robert
 
Can you point to the exact code sample that you are using or post your code?

Did you try to do a wireshark to see if delays are on the PLC side issuing the messages or this is a printer delayed to respond to read/write requests?
 
- Are you using this AOI in a periodic task and if so what is the task rate?
- You need to do Wireshark because I suspect that delays may be on the printer side.
 
Task rate is : 25 ms,
Scan time max 7,6ms
Interval times :
Max 32ms
Min 17ms,

There was older project where this printer was running over TCP/IP I havent heard they were struggling with Printer response.
But I will try it, but I need unmanag. switch to connect to that network cause now is just one wire PLC - Printer.
 
25ms rate is Ok, if printer responds fast, then it will take 50ms per message (needs at least 2 scans). you can do a quick test and set rate to 15ms to see if any performance improvements. I would not go any faster since I don't know what else is in the program.
I also assume that you don't have Continuous task at all.

To do wireshark, you actually MUST have a managed switch with port mirror enabled. Unmanaged switch will isolate PLC-printer traffic.
You can use 1783-ETAP in debug mode too.
 
:( that would be a problem to find managed switch or etap in factory.
I will also try to contact printer supplier.
If someone has experience with transfer time or been investigating in some application I would be very grateful :) .
 
One way transfer time on the wire in within the microseconds. You should not worry about it. So your delay is within the application or in the printer.

I am very familiar with this application code AOI, that is why I am trying to help.

If you did not change the default application then you can get much faster performance than you seen.
Without your full program I can't say what is wrong.

But before digging into the code, you need to see if delay is actually there, not at the printer.

Wireshark must be done.
 
So I got answer from printer support by saying "Printer is able to print 20 labels per second in TCP\IP Data exchange mode". There is no chance to avoid Wireshark.
I will also try one more test. I just download into Line PLC only Task of Printer exchange and everything else will be erased. I want to see if result is the same or better.
To get ETAP, wait when production on line is done, place ETAP and do wireshark is a bit time consuming. Frankly I did not test too much in Wireshark so far, I have to also spend some time in improving myself in it.
I will let you know after. Anyway , thank you for you help so far.
 
Few days have passed I have done several tests, but delay is still present :/ .

I got Stratix 8000, Printer , EN2T and Laptop connected to Stratix.

On Port 1 where laptop is I set Mirroring of Printer Port. Then I did wireshark, but I am quite novice in it and I am not able to set it right properly.
Are my settings correct to catch up TCP IP conversation now ?
What do I have to do in Wireshark just run it and do filter on TCP connection ?
What should I trace there ?
Heres my wireshark file
http://uloz.to/xzfBozpc/communicationtest-pcapng

I have tested many scenarios EWEB Module, EN2T Module, Standalone L73 just for this task DATA Exchange. I had straight cable from Module to the printer.
Also tested several different port from 7,10032,21000 nothing works better, still slow responses 2seconds.
Printer vendor says they are able to do 20ms, Rockwell says 250read/write per second.
There should be no more problem in ideal world.
 
I forgot to Add .

PLC has IP 192.168.1.240, Printer 192.168.1.4 . I can see it there now.

As a novice but I can see clearly transmitted data from PLC around 37,7 seconds and Printer response in 40.004 . Which is exactly what I am catching on my TON in Control Logix.

Do I get it right ?
 
Last edited:
I can't get your files from here, but I will get them tonight from home.
When you are running Wireshark, make sure you have unfiltered capture, filters can be added later

To see direct conversation you can set your view filters to ip.addr==192.168.1.4
This will show all data coming in and out of printer
 
Last edited:
This is definitely something in PLC program because capture is very consistent and printer responds without any delays.

PLC sends data at very repeatable intervals:
6.28 seconds,
2.16 seconds
6.28 seconds,
2.16 seconds and so on
Can you post your that was in PLC when you did the capture?

printer.JPG
 
Last edited:
First of all I set timer by every 5 seconds to send command for filling printer buffer up.
To start exchanging data with printer, plc has to pass sequence of commands which I did not log. After I started this trigger to have less data in log.

As far as I know PLC opens read message channel and waits for printer response. After 6 seconds it looks to me PLC sends command in write message which is very short interval and then opens read message and waits two seconds to recieve answer from Printer ? So my opinion 6,2 seconds is opened Reading message on PLC side as a waiting for response, when Printer executes command it responds very quick indeed.

When I use AOI Client socket I just enable instruction once and then I have constantly opened socket connection.
When I need write message just WD is latched with string in message buffer.
Otherwise in AOI Read message is opened to start reading even blank string from printer on this port.
What do you think about it ?
I have contacted Printer supplier and attached my log file. I asked him to come up with some suggestion.
 
I don't think, this has anything to do with printer, this is your application and let me explain why:

frame 351 - PLC sends 46 bytes
frame 356 - in 12msec printer responds back
frame 357 - EN2T ACK that

Now PLC is sitting for 6.28 seconds before sending frame 907
911 - Printer responding in 140ms
912 - EN2T ACK this

Now PLC is sitting for 2.06 sec doing nothing until frame 1066
And sequence repeats again.

AOI is constantly reading the buffer, so this is your application that has a delay.
May be you are expecting more than 10 bytes from the printer? If so, then it will not sent it.
It may be Read timeout that should be adjusted to a smaller value - this is a part of Read UDT tag, I am guessing here.
If printer always sends 10 bytes, you may need to reduce Read MSG expected buffer size.
Again, to get help you should post your code.

There is no reason to contact printer vendor.

printer2.jpg
 
Last edited:

Similar Topics

Hello, I need to establish a UDP socket communication between a ControlLogix L72 PLC and a Linux-PC on the other side with a 1756-EN2T network...
Replies
9
Views
6,605
I'm using a 1756-ENBT network card to communicate via socket communication (UDP) with a PC. Now the signal runtime until the PC sends a bit, the...
Replies
3
Views
2,171
Extended Error Code : 16#0000_0204 "Error Processing connection related service" After Deletesocket or DeleteAllSocket, this error always...
Replies
8
Views
2,458
Here is a private message I got: I thought this might be interesting for everyone: With EWEB firmware ver 3.x (currently 3.6) Rockwell...
Replies
17
Views
23,635
Hey Guys, I thought I knew the answer to this, but after some looking I am starting to doubt myself. I thought the 1756-EN2TR would allow you to...
Replies
2
Views
79
Back
Top Bottom