Scalable ethernet system with iQ-series - how big can you go?

[Ekke 1]

Hi!

We are thinking to build an "alert system" to our factory by using iQ-F FX5 PLCs and HMI screens in locations where needed. All connected via ethernet since we have wiring for that in many places already. Might not be the best option available, but these PLCs are pretty cheap, familiar, scalable (we don't know yet how many I/Os, analog inputs, temperature sensors etc. are needed) and small enough. The plan was to use maybe just 5 PLCs to start with and then add more when needed. I think we need one master PLC to communicate with HMIs to "hold everything together". :)

But found some "problems":

There seems to be a limitation on the number of input/output points and it's "up to 384 points" in remote points (according to FX5 Hardware User's Manual). But those "points" are for CC-Link/AnyWireASLINK, so I don't know if that "affects" ethernet systems too? CC-Link IE?

But there is max. 8 stations/connections limit for one FX5 master...

Can this (or these) be avoided by using iQ-R PLC as a master PLC? RJ71EN71 ethernet module says "128 connections (connections usable on a program)" (64/ethernet-port). And I didn't find that kind of limitation in input/output points with iQ-R... 

Is there some other thoughts & limitations we should consider? When we will hit the roof with this kind of system?

Thanks!

[kaare_t 155]

12 hours ago, Ekke said:

There seems to be a limitation on the number of input/output points and it's "up to 384 points" in remote points (according to FX5 Hardware User's Manual). But those "points" are for CC-Link/AnyWireASLINK, so I don't know if that "affects" ethernet systems too? CC-Link IE?

For the FX this is correct, no matter if you install remote IO or not. But note that it is per unit. So each FX5 can have 384 IOs each...

 

12 hours ago, Ekke said:

Can this (or these) be avoided by using iQ-R PLC as a master PLC? RJ71EN71 ethernet module says "128 connections (connections usable on a program)" (64/ethernet-port). And I didn't find that kind of limitation in input/output points with iQ-R... 

Yes, use the R as a "hub" or "master" to hold everything together. It "collects" the desired data from all remote stations (FX5), and you can act accordingly if desired. The ethernet module has some limitations with regards to the number of connections, but I would use CCLinkIE Field module for the FX. In other words, skip CCLinkIE Field Basic, and go for the module that utilizes CCLinkIE Field. You can of course go for Basic version, but I'm not exactly sure what the limitations are and for this kind of system I would personally prefer to have all possibilities. Regarding the limitations on the Ethernet module, were you thinking of using it for anything special, or are you considering using Fixed Buffer comms or Predefined Protocol/SLMP between stations and master? I would still recommend CCLinkIE Field module for the FX and a CCLink IE Field module for the R (or use the RxxEN that also supports CCLinkIE Field).

 

12 hours ago, Ekke said:

Is there some other thoughts & limitations we should consider? When we will hit the roof with this kind of system?

It depends. If your "only" talking about 5 FX systems to start with, this is not a problem at all. One single R system kan utilize 4096 IO alone. It all depends on what you want to do in the R system - as an example; do you want to just collect data from all the FX and trigger alarms based on simple logic then you can go with a "small" R (just simple alarm-codes for each alarm bit in the FX). However, if you want to "control" the whole factory and use the FX more or less as remote IO stations, where the R is executing the complete code then you should consider a CPU with higher capacity. And in any way; if you hit the roof with one CPU, just install another R system in a CCLinkIE Control ring network. If you need to have the "pyramid structure" (one master to rule them all), then install 2 additional R systems (to a total of 3 R systems), where 2 of the R's are collecting data from all the FX systems, and the third R system is collecting data from the 2 R systems. Basically there's really no real limitation.

[Ekke 1]

On 11/8/2018 at 8:29 PM, kaare_t said:

Regarding the limitations on the Ethernet module, were you thinking of using it for anything special, or are you considering using Fixed Buffer comms or Predefined Protocol/SLMP between stations and master? I would still recommend CCLinkIE Field module for the FX and a CCLink IE Field module for the R (or use the RxxEN that also supports CCLinkIE Field).

Thanks for the reply. I think SLMP is ok, but haven't really checked other options... 

That FX5-CCLIEF about doubles the price of FX5, so would like to use plain PLCs... :)

Well, maybe we will just start with some FX5s and try to solve problems when they appear.. :P

For now, it's only planned to have "one-way-connection" so FX5s are just inputs.. and I think this will be just auxilary system to get alarms where they are needed, some buzzer screaming in the factory hall doesn't "always" tell what's the problem and where. So not very critical system, but really helpful if we can get everything to work as expected.

 

[kaare_t 155]

Sorry for the late reply.

SLMP is great, but also check out CCLinkIE-Simple (or what it's called), I think that's built-in to the FX5... I bet it would simplify the setup, but I'm not sure of the specs for the "Simple" version in regards to dataexchange quantity and so on. But it's worth mentioning and checking out.

All in all, your topology seems like a good choice I believe. Good luck, and write a post if you have questions.

[Ekke 1]

On 11/21/2018 at 8:59 PM, kaare_t said:

Sorry for the late reply.

SLMP is great, but also check out CCLinkIE-Simple (or what it's called), I think that's built-in to the FX5... I bet it would simplify the setup, but I'm not sure of the specs for the "Simple" version in regards to dataexchange quantity and so on. But it's worth mentioning and checking out.

All in all, your topology seems like a good choice I believe. Good luck, and write a post if you have questions.

Finally did some "research" with this and it seems there are quite big limitations with FX5 and/or IE Field Basic, I think this is what you referred as "Simple".

If I have understood right, IE Basic can have 4096 remote inputs (RX) and max. 64 stations. But that 64 is 16 stations in 4 groups. iQ-R supports groups, but iQ-F (FX5) doesn't. So it's down to 16 stations. And that 4096 remote inputs is actually 4x1024 so inputs are down to 1024 too. That's not really that much and surely isn't "futureproof". (As a sidenote, with FX5 as a master, there can be only 6 stations and 384 inputs).

And then there is that IE Field.. that needs own cabling, so it kinda isn't what we were looking for (idea was to use network we already have) and doubles cost of every FX5.

I'm not sure if we can use some other "communication method" and use those 2x64 connections that iQ-R offers, I think that would be enough for a future too.

Edited 18 Jan 2019 by Ekke

[kaare_t 155]

Well, when you say you need that quantity of data to be transferred I'm not sure I would recommend SLMP either... I would say CCLinkIE Field. I know it's more expensive, but a system like you describe is probably worth it, or? I would say that with the fairly complexity of your system it would be worth it to cut down on man-hours since it will be easier to setup and maintain than any alternative. But of course, SLMP gives you a flexibility that CCLinkIE Basic doesn't offer... I must have misunderstood your original post, as you mentioned an alarm-handling system. I thought you were to transfer some alarms from "nodes" to a central unit, but the way you are writing makes me think you might want some more (which is fully understandable), but that changes the game a little.

In any way, you don't need any special cabling for CCLinkIE Field. It's standard CAT6 cabling for Gigabit Ethernet, and it's both switchable and routeable.

[Ekke 1]

22 hours ago, kaare_t said:

Well, when you say you need that quantity of data to be transferred I'm not sure I would recommend SLMP either... I would say CCLinkIE Field. I know it's more expensive, but a system like you describe is probably worth it, or? I would say that with the fairly complexity of your system it would be worth it to cut down on man-hours since it will be easier to setup and maintain than any alternative. But of course, SLMP gives you a flexibility that CCLinkIE Basic doesn't offer... I must have misunderstood your original post, as you mentioned an alarm-handling system. I thought you were to transfer some alarms from "nodes" to a central unit, but the way you are writing makes me think you might want some more (which is fully understandable), but that changes the game a little.

In any way, you don't need any special cabling for CCLinkIE Field. It's standard CAT6 cabling for Gigabit Ethernet, and it's both switchable and routeable.

Thanks for the input again.

Well, not 100% sure what we "need" but it would be nice to have some "futureproof" so we don't run out of I/O (well, mainly inputs) in the future. 

Idea was to gather inputs from different places and show alarms/info in the HMI screen(s). Not very critical system, but a way to get info faster and in more usable form to users.

We have quite good coverage ethernet in the factory, so it would be nice to use it, not to wire a second network "parallel" to it.

Closest thing I have found is RJ71EN71 and socket communications (TCP/IP or UDP/IP), it allows these:

P1 connector No. 17-64 connection
P2 connector No. 1-64 connection 

That would be plenty, my guess it that we need maybe 20-30 to cover most of planned alarms/info. Just no idea about the speed etc. but I think it won't be a problem since we don't have "that time critical" things happening so few sec delay would be ok.

I tried Brainboxes ED-008 8xDI/O "remote I/O" option and connected it (Modbus TCP/IP) to FX5, it seems to work ok so it might be one cheap option to add I/O to this system.. (140 eur / 8 inputs is quite cheap but it needs 24V too).

I still haven't wrapped my head around this, what limitations there are in different systems etc. But I think you are right, CCLinkIE Field might be the best option, but it seems to be a little overkill and costs might be a problem... our business isn't that big and only few workers :)

 

[kaare_t 155]

I see, well then you have to make some decisions...

Good luck with decisions, and let us know if you have questions or concerns and we'll try to give some tips and pointers

[Ekke 1]

On 1/24/2019 at 7:08 PM, kaare_t said:

I see, well then you have to make some decisions...

Good luck with decisions, and let us know if you have questions or concerns and we'll try to give some tips and pointers

Well, had some time to put effort to this again, and it seems that you can use one connection to access multiple PLCs in TCP/IP... Tried with 3x FX5, one as a master and used only 1 connection in that.. this might be one part of the solution 

 

[kaare_t 155]

That is partially correct, and is somehow why I was asking some questions about what you're going to use it for...:

If you have time for TCP to open, communicate and close before the next new open, communicate, close then it's all OK. If you need to transfer data to several PLC's at the same time for example you can't do it with only one connection since TCP is connection-oriented...

This is why it's important to start with a spec, more or less... What is the requirement. Since you have time to wait for connection handling between communication then you can create a sequence between two or more PLC's without problems. Great that you got it working!

[Ekke 1]

21 hours ago, kaare_t said:

That is partially correct, and is somehow why I was asking some questions about what you're going to use it for...:

If you have time for TCP to open, communicate and close before the next new open, communicate, close then it's all OK. If you need to transfer data to several PLC's at the same time for example you can't do it with only one connection since TCP is connection-oriented...

This is why it's important to start with a spec, more or less... What is the requirement. Since you have time to wait for connection handling between communication then you can create a sequence between two or more PLC's without problems. Great that you got it working!

Yeah, still don't have a clear picture what are "limitations" with this system, or what kind those are. And don't have "specs to start with" since don't know what would be needed in, let's say, 5 years from now. Just don't want a system, that is too limited in some way and speed isn't top priority in this system. But surely it can't be "too slow", just don't know how slow is ok, and when we will hit that limit if doing this type of TCP-open-communicate-close network...