![]() ![]() |
Hi All,
I would like to get some information from experienced guys in Automation field.
What is the correct method of getting data to RSview32. Is it OK to map (one topic in RsLinx) one PLC only and that PLC sends message to collect data from other machines (PLC) or create link between RSView32 to all individual PLCs (one topic of one PLC in RSLinx).
Total number of PLCs are about 100
Thanks in advance
Shree
I would like to get some information from experienced guys in Automation field.
What is the correct method of getting data to RSview32. Is it OK to map (one topic in RsLinx) one PLC only and that PLC sends message to collect data from other machines (PLC) or create link between RSView32 to all individual PLCs (one topic of one PLC in RSLinx).
Total number of PLCs are about 100
Thanks in advance
Shree
![]() ![]() |
Hi All,
Can any guide me on this please...
Regards,
Shree
>I would like to get some information from experienced guys in Automation field.
> What is the correct method of getting data to RSview32. Is it OK to map (one
> topic in RsLinx) one PLC only and that PLC sends message to collect data from
> other machines (PLC) or create link between RSView32 to all individual PLCs
> (one topic of one PLC in RSLinx).
> Total number of PLCs are about 100
Can any guide me on this please...
Regards,
Shree
>I would like to get some information from experienced guys in Automation field.
> What is the correct method of getting data to RSview32. Is it OK to map (one
> topic in RsLinx) one PLC only and that PLC sends message to collect data from
> other machines (PLC) or create link between RSView32 to all individual PLCs
> (one topic of one PLC in RSLinx).
> Total number of PLCs are about 100
![]() ![]() |
As suggested by other members, it is a good idea to create as many topics as there are PLCs (in this case 100). It is necessary that a Communications Switch is used instead of a HUB. If possible use a router also to route the traffic as required, assuming that each & every PLC need not necessarily talk to all the others.
![]() ![]() |
Shree,
I don't believe that there is a maximum number of topics (PLC connections) in RSLinx. In any case you should be fine with 100.
First I would ask why you would want one PLC to collect data from the first 99? You are introducing another single point of failure and probably increasing traffic. Do you think that one PLC can poll data more effectively than the RSLinx PC? I doubt that, but there could be an architecture where this is true - for example, the PLCs are connected to each other via a fast network and the PC link is very slow.
Most likely, I would poll the data from the devices directly. Setting up a small scale test may be prudent.
Also, with 100 PLCs to log from, you might want to consider a more robust data logging solution, such as using Ignition (OPC-UA) to log to an SQL database.
I don't believe that there is a maximum number of topics (PLC connections) in RSLinx. In any case you should be fine with 100.
First I would ask why you would want one PLC to collect data from the first 99? You are introducing another single point of failure and probably increasing traffic. Do you think that one PLC can poll data more effectively than the RSLinx PC? I doubt that, but there could be an architecture where this is true - for example, the PLCs are connected to each other via a fast network and the PC link is very slow.
Most likely, I would poll the data from the devices directly. Setting up a small scale test may be prudent.
Also, with 100 PLCs to log from, you might want to consider a more robust data logging solution, such as using Ignition (OPC-UA) to log to an SQL database.
![]() ![]() |
Hi Nathan / Bob
Thanks for the reply.
I still not started using RsView32. At present we have one PLC sending message to all other PLCs at every 15 sec using Bit Shift Register at an interval of 0.5 sec, hopefully only one message at one time. We are getting these data (10 words per PLC) from 1st PLC to excel sheet as Hot DDE link & NetDDE to other PCs where there is no RsLinx. I am planning to introduce RsView32 hence this question is. We have DH+ and Ethernet (say 40/60).
Regards,
Shree
Thanks for the reply.
I still not started using RsView32. At present we have one PLC sending message to all other PLCs at every 15 sec using Bit Shift Register at an interval of 0.5 sec, hopefully only one message at one time. We are getting these data (10 words per PLC) from 1st PLC to excel sheet as Hot DDE link & NetDDE to other PCs where there is no RsLinx. I am planning to introduce RsView32 hence this question is. We have DH+ and Ethernet (say 40/60).
Regards,
Shree
![]() ![]() |
I would say that with DH+ it might be wise to use a data concentrator. The controllogix DHRIO card is very good at maximizing DH+ throughput. In fact, what you might do is get a Clx rack with just an ethernet and DHRIO card in it and hook the Ethernet side to the PC with the RSLinx, and let the DHRIO card manage the DH+ traffic for you.
![]() ![]() |
RSLinx does a pretty good job of optimizing communications. I would bet it is better then the individual PLCs if it is all ethernet.
If it is not ethernet, it might be wise to use one or more of the PLCs as a data concentrator.
It is hard to give you any good advice on this issue without knowing a lot about your network, how fast you want to poll, and how much data you are collecting.
It is not unusual for a lot of this data to already be transfered from one PLC to another anyway as often multiple PLCs need at least some of this data under normal circumstances. In a lot of cases there is already substantial message traffic between PLCs.
If it is not ethernet, it might be wise to use one or more of the PLCs as a data concentrator.
It is hard to give you any good advice on this issue without knowing a lot about your network, how fast you want to poll, and how much data you are collecting.
It is not unusual for a lot of this data to already be transfered from one PLC to another anyway as often multiple PLCs need at least some of this data under normal circumstances. In a lot of cases there is already substantial message traffic between PLCs.
Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2013 Nerds in Control, LLC. All rights reserved.
Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.
Fortune
If you wish to live wisely, ignore sayings -- including this one.








on 12 November, 2012 - 11:55 pm
