GE PLC heartbeat indicators

I tried posting this on the GE forum, and not getting much interest, so I thought to try here where it is more-traveled...

I am using Cimplicity 8.2 SIM 19 to monitor 5 GE PLCs; an RX7i (CRE040), a 9070 and 3 9030s. To verify that the PLC communications to each is active, I am monitoring the 1 second timer bit %S005 with an indicator light for each on a screen. In the project I have the port scan rate for each device set to 5 ticks. All the PLC heartbeat indicators are flashing at about 1 second intervals, but after a few days, the RX7i seems to have slowed down to about a 5 second flash rate. The scan time on this PLC is about 19ms, and all logic in it seems to be executing normally. Any ideas why the %S005 bit is suddenly slower?

Thanks in advance...

Hi why do you use ticks for something that is displaying ON /OFF once a second? It maybe that your overloading the comms channel.

Are there any other tasks running on the PC that could cripple your Ethernet..windows update, virus checking stuff, etc etc

Non essential data could be opened up to say 1 second or 2 seconds instead of ticks. Your heart beat could even be longer depending if it is controlling a critical process.

I use a 2 second ON/OFF for my HMI heartbeat indicators, for example.

The %S005 bit isn't "getting slower". Your HMI comms are overloaded. I typically use 5 second pulses for heartbeats.

I usually run a 10 sec timer and monitor/reset the timer's "count" (accumulated time) from the HMI at 5 (every 5 seconds). If it reaches 10 then I get a "lost communications" alarm.

cjd1965 said:

Hi why do you use ticks for something that is displaying ON /OFF once a second? It maybe that your overloading the comms channel.

Are there any other tasks running on the PC that could cripple your Ethernet..windows update, virus checking stuff, etc etc

Non essential data could be opened up to say 1 second or 2 seconds instead of ticks. Your heart beat could even be longer depending if it is controlling a critical process.

I use a 2 second ON/OFF for my HMI heartbeat indicators, for example.

Click to expand...

No Windows Update, no virus checking; this is a closed network, isolated from any possible external interaction. Also, it is running on Gigabit fiber with top-end Cisco managed switches. I will try resetting all the device ports to a 1 second scan, but the 5 tick scan rate does not seem to affect most if any of the other data being polled.

I will also dust off Wireshark and see if there are any other network issues.

Thanks,

mbartoli said:

No Windows Update, no virus checking; this is a closed network, isolated from any possible external interaction. Also, it is running on Gigabit fiber with top-end Cisco managed switches. I will try resetting all the device ports to a 1 second scan, but the 5 tick scan rate does not seem to affect most if any of the other data being polled.

I will also dust off Wireshark and see if there are any other network issues.

Thanks,

Click to expand...

Can you give that one either 4 tics or 6 tics, just to get it out of synch with the others?

Also take a look at how much data your Cimplicity project is trying to get from the Rx7i and how efficiently you've set up the data that needs to be transferred.

Addressed variables are inherently more efficient than symbolic addresses. Long symbolic variable names put a limit on the number of variables that can be updated in a single transaction. If you are trying to read multiple individual symbolic variables, they all have to be explicitly called out in the read request. If they are traditionally addressed and the addresses are contiguous Cimplicity can request all of them by specifying the starting address and the number of bytes.

Even if you use traditional addressing, Cimplicity still issues separate read requests for each data type; one request for Boolean variables, another for integers, another for floating point variables, another for strings, etc. That is true even if the addresses are contiguous. For example, if you wanted to read ten integers starting at %R0001, 5 floating point numbers starting at %R0011, and 5 strings of 10 characters starting at %R0021, that would take three read transactions. Consequently, you can make your data exchange more efficient by grouping variables of the same data type in contiguous addresses.

Russ,

I will give this a try tomorrow when I can get back to that location on a regular shift; I am working an odd off-shift supporting another operation at one of our other locations for the past few days (zombie squad).

Steve,

This is the first I have heard about the data read requests; we use traditional addressing (I guess) ie: "I:083 - Relief Vent Flow Switch Open". We have no symbolic variables. The project on the RX7i started out years ago using LM90 and Cimplicity 4.0, so none of the new tricks were in existence back then (I think). Should I be looking at our data structure differently now? Again, as I said, the %S005 bit was working fine on all PLCs when I first set it up about a month ago in the Cimplicity project, and after about two weeks mysteriously slowed down its response from the RX7i, but all other points are apparently not affected; you can see analog values updating in less than 1 second intervals. Maybe it is that I am placing an unnecessary network load on the RX7i port by setting it to 5 ticks; we are polling about 800 hardware points between the analogs and discretes, and a total of about 4000 points in the project.

By "Read Request", I mean every transaction where Cimplicity reads data from the PLC. It might take a few dozen transactions for Cimplicity to refresh all of the points. If you are polling all points at the same frequency, then you don't get any individual point updated a second time until all points have been updated once.

The number of transactions it takes depends on the data type of the points and their addresses. For example, Cimplicity may be able to update as many as 2K integer tags in a single transaction if they are in consecutive addresses, say from %R00001 through %R02048. But if your application needs %R00001, %R02500, %R05000, and %R07500, that's going to require 4 transactions. Furthermore it won't mix floats and integers (or any mixture of data types) in a single transaction, even if the float is at %R00001 and the integer is at %R00003.

An inefficient layout of variable addresses can significantly affect the time between refreshing an individual point.

Steve Bailey said:

The number of transactions it takes depends on the data type of the points and their addresses. For example, Cimplicity may be able to update as many as 2K integer tags in a single transaction if they are in consecutive addresses, say from %R00001 through %R02048. But if your application needs %R00001, %R02500, %R05000, and %R07500, that's going to require 4 transactions. Furthermore it won't mix floats and integers (or any mixture of data types) in a single transaction, even if the float is at %R00001 and the integer is at %R00003.

Click to expand...

Steve, that makes sense. As I stated earlier, this project was originally laid out in Cimplicity 4.0 by others, with no regard for efficient bookkeeping as far as %R or %M assignments for screen tags. That said, for the ~3500 variables being polled by the project, the holes in the polling sequence probably put the number of reads at over 1000. I will confess, this is the first time that the polling request strategy has been explained to me, and I have been working with Cimplicity for over 12 years. With a project this size, it would apparently take a complete rewrite of the project to optimize the read requests. At this point, I am going to have to do what I can to improve the performance. Of course, with the improvements made already, the project is much more responsive than it was originally. The port poll rate had been set at the default of 5 seconds, which meant a long time between the time you clicked on a toggle to initiate something, and the time you actually got feedback of its completion. I have made progress, and hope to get more out of this.

Thanks,

What driver is Cimplicity HMI using?
I have not done a lot of research on it but there is a fairly new OPC Server developed specifically for the PAC called "Proficy Driver Server". See the quick start guide: http://support.ge-ip.com/support/index?page=kbchannel&id=S:KB14264&actp=search

I am currently using the S90 TRIPLEX driver to communicate with all the PLCs. Would the driver you are describing require a major change to my project?

Thanks,

Rus,

Setting the scan rate to 4 or 6 ticks made no difference. Setting it to 1 second made a notable improvement. All are set to 1 second for now.