Omron PLC stop responding when stress test is performed

[borysg1]

Hi, My setup is as follows: 1. QT application in PC 2. CP1L-M30 with CIF41 ethernet card. 3. Communication is realized using FINS protocol. I perform following loop: /* Odd address test */ res_wr = driver.writeWord(FINS_MEM_AREA_W_DM,7354<<8,0x5555); QCOMPARE(res_wr,0); res_wr = driver.writeWord(FINS_MEM_AREA_W_DM,7356<<8,0xAAAA); QCOMPARE(res_wr,0); for (val=0; val<=0xFFFF; val++) { //std::cout<<"LOOP: "<<val <<std::endl; res_wr = driver.writeWord(FINS_MEM_AREA_W_DM, addrr, val); res_rd = driver.readWord(FINS_MEM_AREA_W_DM, addrr, &val_rd); if(val != val_rd) { num_read_bugs+=1; } QCOMPARE(res_wr,0); if(res_rd != 0) { QWARN("Wrong res_rd or res_wr"); } res_rd = driver.readWord(FINS_MEM_AREA_W_DM, 7354<<8, &val_rd); if(0 != res_rd) { QWARN("Wrong res_rd"); } if(val_rd!=0x5555) { num_read_bugs+=1; } res_rd = driver.readWord(FINS_MEM_AREA_W_DM, 7356<<8,&val_rd); if(0!=res_rd) { QWARN("Wrong res_rd"); } if(val_rd!=0xAAAA) { num_read_bugs+=1; } } It runs few thousand times and then suddenly PLC stop responding. I've following question. 1. Do you know what can be root casue 2. Do you know how can I investigate this issue (read some status registers?) 3. Do you know how can I recover this issue (write some status register?). I assume that reinitializing connection should help here but I would prefer some less 'hardcore' solution. Any other hints are very appreciated Regards, Marek

[David M.]

Hello Marek, I have the same problem. After a few thousands of communications with the PLC, the communications are stopped for one or two minutes. If I try a ping to the PLC i don't have reply. If I try to enter to the setup is result is an error by the browser. The scenario is as follows: - PC with a software written in Delphi. - CP1L-M40 with CIF41 ethernet card. - Communication is realized using FINS protocol (over UDP). I have tried with 3 different PLC, and with 3 different CIF41, and the result is the same. I don't have any solution or additional information. You are not alone in this war. Regards, David.

[Berti Baker]

Hi, Ha ha ha - what are you dreaming about? This is like a Denial Of Service attack. The CP1L is the most puny CPU and you bombard it with the power of Ethernet. This is like going down the motorway on a bicycle - and going to end up with someone dead. The CIF41 unit is actually an Ethernet to serial port converter, and can only handle 1 message at a time. If the port is overloaded then the CPU shuts it down for a while (60 seconds?). This is what you are seeing with your test. Send your commands down in simplex (wait for the reply before you send another command) and you should be alright. Regards, BB

[David M.]

Hello, In my case, I transmit the FINS command, I wait the response, and I wait a second for the next communication. I think that's not a problem. I found one solution. If I use an ethernet switch with only the PLC and the computer I don't have any error. However, if I connect other computers to the switch I have errors. The other computers do not communicate with the PLC. For some reason the PLC does not like sharing the switch. Regards, David.

[Jay Anthony]

I would suggest a little Ethernet snooping with software like Wireshark shareware. Good product.

[Berti Baker]

Hi David, You're spot on, and maybe highlight the same problem. If you're using an Ethernet HUB (not switch) or your other computers are sending broadcast/multicast then the CP1L will be receiving packets from other nodes - not just the FINS request. If you're not the only one sending packets its difficult to only send one at a time! Make sure you use a switch, preferable Managed, and as Jay suggests if you can set up port duplication then you can use wireshark to 'sniff' the packets going to the CP1L. Regards, BB