Host Engineering Forum

General Category => Do-more CPUs and Do-more Designer Software => Topic started by: PLCwannabe on October 02, 2019, 06:26:42 PM

Title: Retentive Memory Issues
Post by: PLCwannabe on October 02, 2019, 06:26:42 PM
 Hello,

  I'm doing a lot of reading and writing to plc, working on an ongoing do-more project. Occasionally, I lose all of my retentive memory (counter acc. values, timer acc. values) etc, even if I haven't been working on those rungs that the counters or timers are on. I then have to reenter everything manually. What can cause this to happen? These values are never read or written to in the C-more, so i know they are not getting cleared by the HMI.  Any suggestions?
Title: Re: Retentive Memory Issues
Post by: ATU on October 03, 2019, 11:00:30 AM
Does it come with a plastic strip on the battery to prevent discharging?
Title: Re: Retentive Memory Issues
Post by: Mike Nash on October 03, 2019, 12:00:52 PM
The batteries I have seen have a tab, but it is just to help remove the battery on the Do-mores, the battery is enabled from the factory.

Look at Memory Image Manager, specifically the "Enable Automatic Download" option near the bottom left. It may be overwriting your values.
Title: Re: Retentive Memory Issues
Post by: ATU on October 03, 2019, 02:17:57 PM
I guess if it was a battery issue anyway, you would get messages in the  system log. However, would the error message be lost as well?
Title: Re: Retentive Memory Issues
Post by: BobO on October 03, 2019, 02:47:05 PM
If the issue is due to a failed battery, there would be a message in the system log indicating that the memory was initialized on startup. I'm wondering about the auto download as well.
Title: Re: Retentive Memory Issues
Post by: PLCwannabe on October 03, 2019, 07:01:00 PM
I don't think the battery is an issue, as I am using a backup power supply. I am programming from multiple PC's though, so maybe one of the computers is the problem. Does  "enable automatic download" checkbox apply to the do-more software on a certain computer, or does it apply to a certain project?
Title: Re: Retentive Memory Issues
Post by: ATU on October 03, 2019, 07:38:16 PM
Any Messages in the System Log?
Title: Re: Retentive Memory Issues
Post by: Mike Nash on October 03, 2019, 08:04:59 PM
Does  "enable automatic download" checkbox apply to the do-more software on a certain computer, or does it apply to a certain project?

That's a very interesting question indeed. I do not know the answer though.
Title: Re: Retentive Memory Issues
Post by: Mike Nash on October 03, 2019, 08:25:25 PM
So, I just played around with DmSim and opening a project from file vs just uploading from the PLC, and I do see a potential for maybe getting things into an awkward place. The upload-only doesn't appear to know about the memory image settings in the saved file.
Title: Re: Retentive Memory Issues
Post by: PLCwannabe on October 04, 2019, 12:45:12 AM
No messages in System log. I do sometimes read project from file instead of reading directly from plc, when prompted to do so by the start-up page.

I really have never used the memory image manager. I've always assumed that retentive memory locations will keep their values, even if program changes are made. Does the software perhaps at some point decide that too many changes have been made in the program, lets clear all memory locations to zero?
Title: Re: Retentive Memory Issues
Post by: franji1 on October 04, 2019, 06:56:57 AM
The Memory Image manager is not enabled by default.  Also, the Download (Write) to PLC dialog would show you whether you were updating Memory Image (along with the System Configuration, Program, and/or Documentation).

If you have any regions defined in your Memory Image, then you would see an option in the Download to PLC whether to write some/all of the regions to the PLC.  It is usually UNCHECKED by default, since even if you have regions defined, you may not want to always write them (e.g. Run Mode Edit).  See the first attachment.

The 2nd attachment shows what it looks like when you do enable the Write of the Memory values - you have the option to write specific regions.

Hence, it should be obvious whether you are overwriting memory with the MIM at download time.
Title: Re: Retentive Memory Issues
Post by: ATU on October 04, 2019, 09:51:49 AM
Is your event log completely empty?
Title: Re: Retentive Memory Issues
Post by: PLCwannabe on October 04, 2019, 09:48:50 PM
No, it is right full.
Title: Re: Retentive Memory Issues
Post by: ATU on October 07, 2019, 08:08:09 AM
Have you looked at it directly after one of these memory wipe events?
Title: Re: Retentive Memory Issues
Post by: PLCwannabe on October 08, 2019, 07:51:01 PM
No I have not.Next time it happens I'll try to check all those logs to narrow down what is actually going on. If I ever figure it out what is happening I'l post it here.
Title: Re: Retentive Memory Issues
Post by: PLCwannabe on October 26, 2019, 01:01:22 PM
   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.
Title: Re: Retentive Memory Issues
Post by: Greg on October 28, 2019, 12:10:43 PM
@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)
Title: Re: Retentive Memory Issues
Post by: PLCwannabe on October 28, 2019, 03:37:36 PM
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??
Title: Re: Retentive Memory Issues
Post by: Greg on October 29, 2019, 09:19:45 AM
So, in order to understand this:
Title: Re: Retentive Memory Issues
Post by: PLCwannabe on October 30, 2019, 12:15:22 PM
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.
Title: Re: Retentive Memory Issues
Post by: Greg on October 30, 2019, 03:36:25 PM
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:

Your program is just the *.DMD file located with wherever you store your projects. To see where that is:
Title: Re: Retentive Memory Issues
Post by: ATU on October 31, 2019, 10:14:45 AM
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. "



 
Title: Re: Retentive Memory Issues
Post by: Greg on November 01, 2019, 01:37:38 PM
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:
Title: Re: Retentive Memory Issues
Post by: Controls Guy on November 02, 2019, 12:43:55 PM
Right, the task as an entity could be continuously enabled with just the alarm logic disabled within it for 20 seconds.