Skye

Dear experts, this topic can be closed. Regards, Gunter

Dear experts, I used this forum for help analyzing our PLC setup in the warehouse in 2013 and feedback from the experts here was very helpful. I would like to offer an engagement as freelancer on our project since we need to cut-out a system which runs out of maintenance in Dec 2016. Please see attachment for details and very happy to receive any questions. I hope this is not against the forum rules as I couldn't find a suitable forum "job offers". Kind regards, Gunter Senior PLC Engineer Japan.pdf

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

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?

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.