Event-based sending of data from Q-Series via TCP/IP

[Skye 0]

Dear experts, we are running a project in Japan to interface Mitsubishi PLCs (Q-Series) via TCP/IP to a material flow system. For that we are using multiple modules of QJ71E71 attached to the Q-Series CPU. The material flow system can deal with telegrams of up to 512 bytes. We want to send the data event-triggered, so every time something changes on the conveyor system which is relevant the telegram sending should be triggered. From the Siemens and e.g. Daifuku systems I know of telegram structures which are basically like that: <ID# of telegram><Sender ID><Receiver ID><Type of telegram><Data of telegram><Check sum>. Basically we are flexible from the MFS side to adapt to the structure. My expertise is on the MFS side, so here is where I need help: The local Mitsubishi PLC experts tell me the following: An event-triggering is not usual. We are the first company in Japan to do that. Normally the MFS should constantly poll the PLCs for changes. This I find very strange, as it adds a lot of traffic to the network and besides our MFS is not fast enough to capture every change reliably (e.g. there are 2 changes within 0.1 second we want 2 telegrams and not miss the first change). They tell us, that every barcode reader attached to the PLC should "speak" with a different TCP-port through the QJ71E71 (which is ridiculous, we just need an ID in the telegram of the barcode reader but not on the TCP protocol level). Also they want to split the data words with every 10 words into separate messages again going via separate TCP-ports. This sounds so strange to me that I wonder if the idea to get telegrams more or less in the structure of <ID# of telegram><Sender ID><Receiver ID><Type of telegram><Data of telegram><Check sum> (as mentioned above) is impossible with Mitsubishi controls or if this is more related to our "experts"? Any comment on that? I'm happy to explain more details in case I missed important information.

[kaare_t 155]

No, your "experts" aren't experts!! Event triggers are not the most used solution, but indeed not a problem. There's even interrupt handling in the CPU/E71 for this purpose so that you can fire the telegram directly from a program rung instead of waiting to the END instruction in the PLC program. When it comes to handling multiple devices on the same port(s) this is of course possible, but it depends on the application. Please describe the system itself a bit better so that we can understand the "data-flow", and how the devices are connected, and the equipment you will be using. Please describe in detail so that we don't miss anything or go any wrong ways.... But all in all, this doesn't sound very complicated at all. In essence you want to receive data from some barcode readers (polled or pushed?), process them in the Q, then push them to the MFS system from the Q on interrupt. Is this correct?

[Skye 0]

Dear kaare_t, thank you so much for your reply , so I will try my best to explain properly. Very roughly this is the setup: The barcode readers are TCP/IP. The barcode readers are attached to each Q-Series which basically at the time of a barcode-read should then send the data to the system called EWM in the picture which is the material flow system. So as you described. For that we would like a telegram. We bought Q71E71 (TCP/IP modules) attached to each Q-Series CPU which I also wonder if that was really necessary but anyway it's there. And I would prefer to handle each Q-Series (described as CP-<x> in the picture) to the EWM only via one TCP port and not a new port for each barcode reader. In addition, there are some measurement results etc. also coming from one of the CPs (CP1 and CP2) which need to go with a different telegram to the EWM. And we are sending commands to the CP1 and CP2 to e.g. let some boxes on the conveyor go left or right or... So: EWM --> CP1/2 and PLT: Telegrams to send commands to the conveyor system. CP1/2 --> EWM: Measurement data of a carton size and weight CP-<all> --> EWM: Barcode reader data (each CP has multiple BCRs attached) And all coming for CP-<x> should be event triggered. And I wouldn't want to communicate via different TCP ports to one Q71E71 however, we can have one different port for each Q71E71, that's fine. I hope I was able to explain better. Are there any buzz-words I should use to set the guys on the right track? So "interrupt handling" I understand and can mention it. Any command or manual they could study?

[kaare_t 155]

Everything you are describing is fine except from the fact that there is several barcode readers attached to each E71 card. The biggest drawback with E71 (and built-in Eth ports on the CPU) is that one port is dedicated to one socket. Hence you cannot create several TCP sockets on the same port, which in turn means that you: 1. Have limited TCP connections (16 connections which in turn is 8 sockets since one TCP socket requires a local and remote port -> 2 connections) 2. Cannot do socket multiplexing in the card, which means you are still limited to the 16 connections/8 TCP sockets The biggest "problem" (allthough the limitation is stupid in my opinion) is that you are running TCP for the barcode readers. If they were running UDP the connection would not require to be connected all the time, hence demanding the socket, and the barcode readers would simply send the telegram when ready. So the problem isn't that you cannot differentiate the address in the PLC, it's "simply" that one socket will occupate the ports at any given time when using TCP. Some more questions: 1. How many barcode readers are attached to the same E71 card? 2. Is it possible to run UDP on the barcode readers? When it comes to the EWM system everything is fine, just create sockets for each direction for performance, or one socket if performance is not a big issue. I will find some docs, but right now I'm a bit occupied. Please answer my questions, and I will get back to you with more info and docs.

[kaare_t 155]

I could not find the newest manual in the MEAU website (sh080009p), only a couple of revisions earlier (sh080009m - 130029). I've PM'ed you the newest manual for your reference.

[Mitsu 2]

Interesting case. It would be interesting to know what solution you eventually decide to use in this case, skye. It would also be interesting to know how many bar code scanners you have on each QJ71E71. @kaare_t: what solution would you advice (purely out of interest)? Each bar code scanner will take up 2 out of max 16 available buffers (or ports). So you could connect max 8 scanners tcp/ip on one QJ71E71. You would also need 2 buffers (send/receive) to communicate with the EWM system. So max. 7 scanners and 1 tcp/ip connection to get the data to and from the EWM system. I assume the interrupt based receive instruction (RECVS) could handle the required speed. So scanners connected with tcp/ip to the QJ71E71 and the QJ71E71 communicating with the EWM system with two (or more) of the remainging ports (unless scanners allow UDP, which doesn't seem to be the case)? @skye: what plc cpu's are used in the system?

[Skye 0]

Dear kaare_t, thank you for that details , I started to read the documentation. Some more information: The CPU type we use is Q03UDECPU BCRs are Cognex Dataman 60L (I think they only handle TCP not UDP) We have for CP-8 14 BCRs, for CP-5 7 BCRs, for CP-6 6 BCRs, for CP-3 11 BCRs. We have more than one E17Q71 for those that are over 8 BCRs per CP. So let's say one of the BCRs is sending a read to the connected CP-8, the Q-Series should trigger a telegram to the EWM. Is it correct to say that for this there must be a program using the BUFRCVS which will perform that action? Does it mean this way (from the EWM perspective) I can handle all communication EWM<->E17Q71 via one TCP connection (since the Q-Series is collecting the BCR data, then sending it to the EWM)? Of course one connection per CP-Instance. This would be acceptable. Attached an example of what is in use e.g. for CP-3. And the landscape as an overview Edited 11 Dec 2013 by Skye

[kaare_t 155]

1. For the BCR->CP-x you only need to create a socket in the Q, waiting for data. Simply open up ports and wait for data to arrive using your experts preffered instructions. 2. For the CP-x -> EWM you can use one computer socket for each CP. Feel free to use the same ports on the CP's and/or on the computer. This will be decided by your programming on the computer side, but you should create one TCP (or UDP) connection for each CP to enhance performance (so that each CP has a dedicated channel to send the interrupted data on). Overall thoughts: Your experts should use interrupt programming for checking the BCR's to handle incoming telegrams instantly if this is required. If so, I would also recommend them to do "Direct processing" of the send data too, this can be done by adding a "D" after the "Ynn" (e.g. YnnD) operation flag for the E71 cards.

[kaare_t 155]

Skye: How did it all work out? Did you get any results, and how did the experts deal with the information above?