OMRON CJ1M Ethernet Configurations

[Pago 0]

Hi all, I'm using a SCADA application using OMRON OPC Server version 1.22 to comunicate to about 200 CJ1M OMRON PLCs. But i'm with huge problems in comunications. All 200 PLCs are in a B class ethernet network tipology. Every time i restart OPC server it takes more than 8 minutes to get up the comunications. In SCADA it is better not too talk but as example imagine the operator do a reset command to a counter and wait about 3 or 5 minutes to verefy the command was wrtitten. Some one told me that may problems could have to do to the fact that i hadn't configured nothing on FINS network/node address on PLCs. Makes this sense once that i'm using Ethernet? (I guess it makes but..) Can someone give some tips on this? I can give some more information if needed. Regards,

[banker 2]

Hi Pago 200 PLC on 1 network is many. How many tags do you have. Have you set update rate. Don't set update rate to fast if you have many tags. Banker

[Pago 0]

In a matter fact 200 are only "my" PLC's. I will have to interact with other ones on other networks by OPC Server or/and Send/Receive commands. I have more than 6000 Scada tags but these come from about 670 arrays configured on OPC Client/Server. About the update rate i guess i've it well configured. The different types of variable are grouped and most of them with asynchronos option (i've tested with Synchronos) and thos who are not, have an update rate between half a minute to a two minute update rate. I've tried these with shorter times and with other configurations but....nothing. Really need some help on this. Another sugestion for quick implementing for thi structure? Regards,

[Fredrix 3]

Just have to ask, why so many PLCs? And only 30 tags per PLC? I think the network it self is a big problem. Are you trying to read from all 200 PLCs from one single computer and one single OPC server? What SCADA software do you use?

[Pago 0]

Hi fredrix, Yes, i'm reading all PLC from just one Single Server PC and only one OPC Server. About 30 tags, aren't only 30 tags per PLC. Why so many PLCs. Well this is a BMS application and some PLCs had to be instaled on strategic points for major reasons. As SCADA i'm using GEFanuc iFIX 4.0! About the solution any tips? By the way now i'm trying to reconfigure FINS networks and nodes on all PLCs. regards,

[Fredrix 3]

Instead of installing so many PLCs on strategic locations, why not use distributed IO, like Omron SmartSlice over DeviceNet ? Edited 15 Apr 2008 by Fredrix

[Pago 0]

The solution wasn't provided by me (I just have to implement it). That would be a good chance to dispense a few PLCs (Some of them are really needed by cable path reasons). But now that's an impossible solution to be implemented. I really need to solve this one. I've the intention, as lons as possible, to have some concentrator PLCs using send/receive commands and on this case i cloud "eleminate" some PLCs from OPC Server. For now I couldn't have Send/Receive commands working. I Really need a solution for this and i didn't find it...yet! Regards,

[Fredrix 3]

Send/Receive sounds like a good idea, then you could gather data from the PLCs with the least amount of IO into one, which would decrease the number of PLCs the OPC server (CX-Server actually) have to read.

[Pago 0]

Let's see. But this would be only part of the solution. It doesn't resolve all my problems. Send/Receive would be useful to concentrate on one PLC data from 64( or 68) PLCs only. I'm finishing the FINS network configuration. Hope during this week i can test comunications with this configuration. But i'm a bit "Hopeless".

[Fredrix 3]

Is it possible for you to run multiple OPC servers? And maybe multiple PCs?

[Pago 0]

Well, this a solutions that i've thinked before as a temporary workaround. But i had somo problems to access remotely to OPC Server with OPC client (maybe some DCOM permissions weren't working). But answering, nop, multiples PCs wouldn't be possible. I have only a dedicated Clustered server with about 5 GB RAM and aneough Hdd space to runs my SCADA and SQL Server too. regards,

[Fredrix 3]

Just thinking out loud now, but what if you try to set different ports on the PLCs ? Maybe that will allow the PC to communicate with more PLCs at the same time

[Fredrix 3]

Found any working solution ?

[Pago 0]

Yes, i guess. I'm still working on it. but if it really works i'll notice you. The main problem is, as far i discovered, the configuration on SCADA OPC Client tool (power tool). I've configured one server for each building architecture level (seven). I though this could be a way to find out the solution when i saw 7 clients connected to the server. Now i'm configuring all item on OPC Client tool subdjacent to one unique server. So far so good. Thanks for your interest Regards,

[BobB 58]

Darned OPC!!! I am quite happy using FINS Gateway with CiTect SCADA quite frankly and Controller Link.

[Fredrix 3]

Well, I am working on a project using Citect SCADA and Omron OPC, we did som tests of OPC, OMFINS and FINS3 (Fins Gateway). OPC Gave us the best performance, and OPC is the only one who supports the EM areas

[BobB 58]

My experiences of OPC have not been good but I have not tried Omron OPC with CiTect. I have had all sorts of problems with BACnet OPC on several sites. It has been absolutely awful. It takes up to 6-7 minutes to register all the points (500 or so) from Alerton BMS controllers. It is absolutely painful. Drop outs are common. I have had CiTect reporting up to 15000 digital reads and 120 odd word reads per second with a Controller Link card mounted in the PC and a fairly early version of FINS Gateway (3. something) and a CiTect FINS driver that was far less than efficient. In fact it was not good at all. That was with 8 PLCs on the Controller Link network. CiTect have a new beta driver for FINS Gateway that has to be stamped to a site licence number. I have that driver - it is not generally released - and so far it is working very well. Our local Omron guru has been working with CiTect for some time now so that they would get it right. Documentation is holding up general release but it addresses W areas etc that were not previously available with FINS3 addressing. I do not know if it addresses EM or not. Have never tried to address EM with CiTect. By the way, I was an early beta tester for CiTect with the very first FINS Gateway driver. No one else was having problems with the driver except me. It turned out that the other test sites only had one PLC attached and less than 100 tags. I had 8 PLCs attached and 3500 tags. It turned out that the messages sent were not being received in the same order due to distance on the network. Identifiers had to be added so that the information received was placed in the right position. Interesting to things going 'berserk' on the sreen by the way.

[Pago 0]

Hi, I've been very busy with no time to maintain my posts, so my appolegies for feedback only today. So today i'm getting some of my posts on forums updated (i guess it's deserved for all good knowledge of us. About all this post, PROBLEM SOLVED (long time ago.hihihi!). How...? Well the main problem was the number of PLCs and the OMRON OPC Server. I've detected alsom somme packet loss/fails wich could be the reason for Bad Qaulity data on OPC client. Instead of OMRON OPC Server i've tested Kepware OPC server with OMRON suite's and worked fine. OMRON has a limitation of 32 devices per channel, limitation wich is not configurable on OMRON OPC Server (as far as i know). On Kepware's i've created five channels each with a different UDP Port number. I distribute the devices for these channels. With this i needed no special changes on variable scan times. Are a lot of variable and most of them with one second scan time. The network has no significant load. All keeps work fine till today. In fact i've having some issues on comunication between PLCs with send/receive commands. some time i get some error. I guess this could be some routing time trouble and packets could be discarded and consequently originates the timout error. I need to spend some time on it but the day only has 24 hours. Thanks for your interest Regards, PAGO

[PMCR 66]

Pago There is a very simple PLC setting that you can make to allow each individual PLC respond faster to network traffic. There is a setting in PLC Settings that sets the maximum time per PLC scan that is dedicated to servicing peripherals. ie communications (Ethernet, DeviceNet, Controller Link, Serial , etc). It is found on the Peripheral Services tab, and is called 'Set Time to All Events'. The 'Default' = 4% of the previous PLC scan time, which can be quite small. I have found that a setting of 50 (which is 5.0 ms) has a huge impact on the response time of a PLC, especially when multiple PCs are talking to a PLC. Keep in mind, this is a maximum time, not a fixed time, so the typical impact will be less than the time that you set. The only negative impact is that it can make the scan time longer (in my case by 5 ms). For most applications, this is OK. I recently visited a customer who had approximately 30 PCs running SCADA software talking to 10 PLCs. Because of the number of PCs requesting data, the average response time (measured by FINS Gateway) was 100 ms. By setting 50 (5.0 ms) in the 'set time to all events', I dropped the average response time to 6 ms. This was a huge difference to this customer.

[Pago 0]

PMCR, I never used or even payed attention to that PLC setting. I'll explore. In this case project 5ms would be a less impact but for the most of my projects any 1ms could have a huge impact. About the your costumer problem, it depends how the SCADA architecture is implemented. In that case i would have only two PC comunicating with the 10 PLC's. The other 28 PC would work as client of those 2 configured as SCADA Servers. With this situation the information would be concetrated and redundant to all PCs on the system. The network traffic would be the same but the payload on the network would be distributed. The other point would be the type of the protocol used. Since TCP generates de twice the traffic needed i'd use UDP protocol (no response). But this is a point of view whithout details of the architecture. Kind regards, Pago

[PdL 71]

Kepware OPC servers rock big time

[james_applied 0]

I would look into a bespoke multithreaded VB application using one comms component per PLC. This may get you over your lag.