Retentive Memory Issues

[PLCwannabe]

   Just figured out what the issue is with retentive memory loss. It appears the counter.acc values cannot be made retentive even though they are set as such in memory configuration. (see attachments). Upon power down, the D3 location does not lose its value whereas the counter loses it every time. They are both incremented by the same input. Is there an issue with the attached code block, or is this a software issue?
    I tried using a c-bit in the reset rung as well, still won't work. I also tried setting the counters to non-retentive, which they then still were.

[Greg]

@PLCwannabe

I cannot duplicate this issue. But, you are correct, it is acting like the CT-memory is not retentive.

Instead of powering down, what happens if you just go to Program mode and then back to Run mode? Does the counter value go to zero? Or does it retain the count?

Also, is it possible for you to send your program to me? (support@hosteng.com)

[PLCwannabe]

It only happens during a power off cycle.  The counters are all within a task, instead of the main program. Maybe counters are automatically non-retentive within a task??

[Greg]

So, in order to understand this:

• The power light on the BRX PLC is green, not yellow?
• Can you save your Event Log to a file (button on bottom right) and email it?
• Can you email a copy of your program to me (support@hosteng.com)
• You are not using or downloading a Memory Image?
• The ENTASK that enables the Task POWER_MONITOR is set for "Continuous on Power Flow at Interval 0ms, yes?
• The Memory Configuration has CT-memory block set for "Entire Block Retentive"?
• You are not using CT13.Acc (or any of its other structure members) anywhere else in your program?
• Do you get any Warnings when you Accept and/or Write to PLC any changes you make to your program?

[PLCwannabe]

1. Power light is always green.
2 & 3. I'll try to email the stuff later when I figure out how to do that.
4  I did save a memory image once but I am not ever using it.
5 I think this is where the issue is. I have to use a 20-second first scan delay on all the enable task instructions because I was getting a bunch of nuisance alarms in the first few seconds after a power-down/run/program transition. When I remove this delay from the task with the counters, the acc value is not lost.
- within the main program block, acc values are never lost, the issue is only within a task
-only happens during a power loss, and NOT when a run/term/stop transition is made.
6- Entire block retentive
7-Only used once within the program
8-No warnings.

[Greg]

Well, the thing is, if a Task is ever disabled, for whatever reason, then the Counters (& Timers) in it will be reset. So, I would agree, there is something about the way in which you are enabling that Task that must be resetting the Counter in a "normal" way because of termination.

To save the Event Log:

• From the menu, PLC --> System Information... This pulls up the System Information dialog.
• Press the Event Logs tab.
• Make sure the <Show All> button is depressed
• Click on the <Save to File> button at the bottom right. This pulls up a normal "Save As" dialog in File Explorer
• Give it a File name and make note of where you are storing it.
• Attach it to an email and email it to me (support@hosteng.com)

Your program is just the *.DMD file located with wherever you store your projects. To see where that is:

• From the menu, File --> Manage Projects --> Folder Settings
• Notice that your Projects Folder is where your *.DMD file will be located, most likely, that is, unless you are browsing to somewhere else on purpose when you open your project

[ATU]

According to the help
"The Global Up / Down Counter (UDCG) instruction does NOT have termination logic, meaning that it will retain it's state information even if it is contained within a Program,a Task, or a Stage, that is disabled. "



 

[Greg]

PLCWannabe, the thing that is causing your CT3.Acc to be reset on a power cycle is the fact that your POWER_MONITOR Task code block is set to retentive plus it is on the 20-second delay at startup. This may sound counter-intuitive at first (like, if the Task is supposed to remember, then shouldn't it remember the Counter's count?). However, the default setting for a Task code block when you first create it is non-retentive. You have to manually set that to retentive either when creating the Task or by later configuring it that way. So, I don't know why you set it to retentive, or even if it really needs to be for your application, nevertheless...

The reason this happens is that internally, there is a system (i.e. hidden) bit in the Task code structure that tells it to "run termination logic if you are ever disabled." By having your POWER_MONITOR Task set to retentive, then on a power cycle, it remembers this bit. Thus, when it powers up and you have the ENTASK programmed with a 20-second delay, the Task is powering up in the disabled state, so it runs termination logic, which resets all the Counters in the Task (among other things).

Also, as ATU pointed out if you used a UDCG counter instead of a CNT, then the count will always be retained regardless of your Task code configuration (retentive or non-retentive) and regardless of your 20-second delay.

So, there are basically 3 different fixes:

• Use a UDCG Counter
• If you keep the 20-second delay, make the Task non-retentive
• Program the ENTASK without the 20-second delay, as you have already discovered

[Controls Guy]

Right, the task as an entity could be continuously enabled with just the alarm logic disabled within it for 20 seconds.