Created Date: July 26,2008

Created by: Steve Bailey

You work in the event manager. Set up a "Tag " event action that writes a value to the "SYSCountMax " tag another "Tag " action that writes a value to the "SYSCountMin " tag, another "Tag " action that writes a value to the "SYSCountInterval " tag, another "Tag " action that turns on the "SYSCountRepeat " tag.

Once you 've done that, the "SYSCountValue " tag will range between the "SYSCountMin " tag value and the "SYSCountMax " tag value, incrementing by one at the frequency set by the "SYSCountInterval " tag.

The counter works in simulation. Try it out.

In your initial post you asked for additional system bits at different time tick intervals. Personally, I'd like to see additional system counters.

Created Date: July 28,2008

Created by: robertkeenan

I think the screens are very slow at doing the basics. I have been fighting with a project for a few weeks now and have to admit the screen is not up to it. I have been told that Iam asking to much from the screen and would need to cut back on the graphics. All I had was a couple of buttons on a popup window. I hate to see how animation could work. To make my panel work I had to create multiple screens and then try to work out how to change between screens without the operator having to push a button every time.Another example of how slow they are is in the displaying of data from the PLC. I have an ethernet connection to an 06 and when the PLC measures excessive current it stops the process and brings up on the screen the measured current and the max allowed. This value does not alway appear. It would seem that a time delay is required to allow the data to display, but in a production enviroment those few seconds may seem like a lot of time just to display a number, no fancy graphics.

Created Date: July 28,2008

Created by: Steve Bailey

Where are you guys getting this stuff?

I had an application that was going to use the trending object and I needed to be able to demonstrate it to the customer without being connected to a PLC. The help for the built-in counter is not very good, but the catalog mentions its existence. I figured it might be something I could use, so I started experimenting with it.

Created Date: July 28,2008

Created by: jgreenewv

Originally posted by robertkeenan:

I think the screens are very slow at doing the basics. I have been fighting with a project for a few weeks now and have to admit the screen is not up to it. I have been told that Iam asking to much from the screen and would need to cut back on the graphics. All I had was a couple of buttons on a popup window. I hate to see how animation could work. To make my panel work I had to create multiple screens and then try to work out how to change between screens without the operator having to push a button every time.Another example of how slow they are is in the displaying of data from the PLC. I have an ethernet connection to an 06 and when the PLC measures excessive current it stops the process and brings up on the screen the measured current and the max allowed. This value does not alway appear. It would seem that a time delay is required to allow the data to display, but in a production enviroment those few seconds may seem like a lot of time just to display a number, no fancy graphics.

Robert,

I'm not sure what's causing you problems. I 've got two 8 " C-Mores that have been operating for a couple of years with fairly complex graphics, and have not had any issues. One is communicating with a DL260 via Ethernet and the other is communicating with a D2-DCM (19,200 bps serial). I 've also got several 6 " C-Mores running what I would consider an ordinary mix of text and graphics with a serial connection to DL06 PLCs. They all have a virtually instantaneous response. Not knowing your exact setup, but is it possible that the scan time on your PLC is getting bogged down, delaying the communications with your C-More? I'm quite surprised that you are having so many problems with a seemingly simple configuration. Have you worked with Tech Support on this? They have been quite helpful when I have called in with other problems. Good luck.

Joe

Created Date: July 28,2008

Created by: a agnone

AS far as graphics go, there is a slight delay in the updating. For instance the red light on Y0 blinks the red button on the machine. If I duplicate the red flashing light on the HMI, there is a slight delay. You see the red light flash on the hard wired button, but the light on the C-more is like 1/4 sec behind. This gets really apparent when sending data or numbers to the graphics on the C-More. I see what Robert is saying. If the PLC is sending out numbers, which are constantly changing, the C-more doesnt always catch the updates. If the PLC is sending 1,2,3,4,5,1,2,3,4,5 from a timer I see 1,4,2,1 on the C-more. But now wait. I have a analog card reading a scale and outputting it on V1400. I instantly see the number in V1400. There is no lag. The number on the C-More changes very rapidly. What is going on here? By doing what Steve had me do, cleared up the graphics motion because the movement number is coming from the C-more. I might have to try other things to make sure what I just said is true, but it seems if it comes from a timer or counter, it takes awhile for the C-More to see it, but from my analog card it sees it right away. If this is true, what can be done to improve updating?

Created Date: July 28,2008

Created by: Steve Bailey

If this is true, what can be done to improve updating?

There are several things you can do to improve update speed.

The CMore manages the communications with the attached PLC. It tries to refresh all of the variables on the displayed screen as fast as possible. You can help by making the memory locations contiguous. For example, if you want to display V400 and V2000 on the same screen, the CMore is going to have to issue two "Read " commands to the PLC, one for V400 the other for V2000. If, instead, you need V400 and V401, the CMore cam issue a single "Read " command to read two words of data starting at V400.

Along the same lines, if the CMore needs data from V memory, C memory, timer memory, and counter memory, that's a minimum of four transactions.

Furthermore, any variables included in the alarm database are updated whether or no they are present on the displayed screen, so they add to the communications overhead.

On one application, I used all internal memory variables for display on the screens and used the event manager to read PLC memory and transfer into internals once per second.

The device I was connected to in that case had an internal clock and I included the seconds in the data I was reading. It used Miodbus protocol and had a limit of 20 words of data per transaction. It took a total of six transactions to read all of the data I needed. The best I was able to get in that application was a reliable update every two seconds, occasionally every second.