SLC505, Wonderware & Kepware

[dances-with-plcs 0]

We have a customer that has: 24 Allen Bradley SLC505 12 Allen Bradley Panelview 1 PC with Wonderware All connected via Ethernet. We are replacing one of the SLC505's with a new 505 such that it will duplicate the Ethernet address of the unit we are replacing so that the Wonderware system will keep monitoring it. We are also adding a new PC with Kepware OPC and our SQL server data logger and report server commicating via Ethernet, which will monitor the new 505 only at first. We'd like to set the scan rate on the Kepware to 2 seconds per point for our new equipment, which means we will be running parallel data with the Wonderware on the new 505. We are only monitoring alarm points and all alarms are 'latching', which means that an operator must acknowledge every alarm on our new 505. My concern is that we will somehow have a detrimental effect on the existing Wonderware installation. I could lengthen our 2 second scan rate, but then our report could be off by 2 seconds. Eventually we will replace all 24 SLC505's an then be entirely on our Kepware system, eliminating the Wonderware PC. Does anyone see anything inherently wrong with our thinking? Thanks in advance for any thoughts.

[Tech Fred 3]

Depending upon the number of items you are reading a poll rate of 2 seconds shoult not impact your processing. The PLC will have to handle request from seperate connections which will slow the procees a little bit. Much like trying to hold 2 seperate conversations will slow your response to any one person. KepserverEX optimizes as much as possible to minimize communications to the PLC. The driver will block the requets to get as much data as possible with the fewest number of requests to the device. The other key to optimizing the performance in KepserverEX is to place each device on its own channel whcih allows the server to talk simultaniously to all devices. Please feel free to contact Kepware Technical support if you have any additional questions. We are there to help you. Fred Loveless Support Manager Kepware Technologies

[flopro 0]

Make sure S:2/15 is not set in the Channel 1 status file. If it is then only one communication request is serviced per scan. You can also "sprinkle" SVC instructions in the ladder logic to force the SLC to do some unscheduled communication request servicing on either comm channel. Usually you want to control these SVC instructions with an XIC S:2/5 (incoming command request pending) or S:2/7 (outgoing command request pending). After doing this to a SLC 553 with 3 PV600's, RSView32 and RSSql the Ethernet network became so "snappy" that the customer's operations personnel thought the control system had been replaced. It had been sluggish for 3 years and PV's had hold times on the buttons and interscan delays extended unnecessarily. I observed through RSLinx driver stats >80 packets/sec. servicing RSView32 and RSSql OPC topics. Remember, there are 3 PV600's also on this network performing discrete batching operations for three production areas besides RSView32 and RSSql. In PLC5 platforms you don't have the SVC instruction but you can adjust the S:71 time-slice in ms to let the PLC processor have that much more time to perform housekeeping routines between scans; communication requests being one of them. Just be aware that this additional time is added to the overall scan time.