EpicWill (Customer) asked a question.

October 18, 2023 at 1:26 PM
Manually change memory values?

Hi guys, I have a BRX BX-DM1E-18ED23-D in a machine. I just made some changes to the PLC program (added hour meters for maintenance purposes) and it reset the stored hour values to zero.

 

No problem, I'll go in and manually change the memory values in the software. I did this but it'll only update the values if the PLC is in stop mode. Then when I flip it back to RUN it erases everything back to zero.

 

I even tried writing them, seeing that they were updated in the program. Then I saved the program, madea change to a comment so I could then write the changed program to the PLC and once again when Iflip back to RUN it resets all the counters to zero. What am I doing wrong?

 

I just want to set the total hours back to what they were before I changed the program but the changes won't stick.

  • 23 answers
  • 581 views

  • EpicWill (Customer)

    Got it! It turns out I was changing the wrong memory address. According to the help on a global counter:

     

    ".Zero (read-only) will be ON any time the value in the Counter's accumulator value (.Acc) is 0."

     

    So the counter memory addresses were at zero. I was changing the address where the counter's value was being sent to (D0, D1, D2) rather than changing the counter itself. So on RUN it just copied the ".Acc" value to the D register. I went in and edited the CT memory block and wrote it to the PLC. When I switched to RUN it copied those values to the D registers and worked properly.

    Expand Post
    Selected as Best

  • HOST_franji1 (HOST Engineering)

    You don't mention where this is stored, but check your retentive range for the block in question, the specific element is probably non-retentive (e.g. D0-D1023 is retentive in the D block, but you are using D1024).

     

    If it's non-retentive, it will reset to 0 after power loss or on Program to Run transition. Only retentive memory ranges retain their values after power-up or Pgm->Run transition. You can configure what sub-ranges or what heap items are retentive or not in the Memory Configuration dialog (PLC->System Configuration..., select the Memory Configuration entry in the list on the left).

     

    To make it retentive, either use a different element ID of that block that IS retentive, or modify the definition of the memory block and change the retentive range for that specific block to include that ID - make sure this is not breaking any code that is depending on the retentive-ness of the new range.

    Expand Post

    • EpicWill (Customer)

      I did check that after I made this post, the entire D block is set to be retentive. It would save on power down, it seems the only reset would be from STOP to TERM/RUN. Switching between TERM/RUN won't reset the values but they also won't allow the memory to be changed through the software. You have to be in STOP to change it.

       

      I can do that and overwrite it and the values update on the HMI panel but then as soon as I come out of STOP it resets everything to zero regardless of what was there before going to STOP.

      Expand Post

  • HOST_franji1 (HOST Engineering)

    Check your cross reference of that element. Expand Ranges in the Cross Reference view (Ex). You probably have some instruction writing to it. $tFirstScan task or ST0 contact driving something on first scan is probably driving it.

     

    Term->Run via the switch is not an actual transition (unless it was already in PGM mode). Terminal mode switch just tells the PLC to allow Do-more Designer to do mode changes also (in addition to the switch on the PLC). So if the PLC is already in RUN mode, Term->Run->Term->Run->Term does nothing to the PLC mode.

    Expand Post

    • EpicWill (Customer)

      I'm not seeing anything that might conflict or cause a reset using the cross reference window. The first scan and ST1 don't trigger any kind of D block memory reset. I was going to upload the DMD file but it's not a supported file type for some silly reason.

      • HOST_franji1 (HOST Engineering)

        Double check your logic then - whatever is writing to your D - the data that IT uses, debug THAT. It could be code, it could be data.

         

        How many rungs write to that D? Typically, you only want 1. Sometimes you have 2, one for initialization and one for "running" state. Check all the Cross Reference Logic for THAT D location and see what that logic is (or is not) doing. One of the columns for Cross Reference is for whether the parameter is an Input, Output, or In/Out - you want to see where that D is used as an Output or an In/Out.

         

        You could do a Find All on your D (include Ranges) then copy the Find Results to a .TXT file and post that here. An alternative is you could ZIP your .dmd file and post the .ZIP (maybe it accepts .ZIP files???)

        Expand Post

      • EpicWill (Customer)

        I'll check the code for any duplicate writes. I didn't write the initial code, I just added a second hour meter (copied what had already been working and changed the parameters to new values).

         

        As far as I can tell each D is only being written to once - there's 3 storing the counter values, one for each different hour meter for the HMI display. D0 is for the 100 hour counter, D1 is the total hours and D2 is the 1000 hour counter.

         

        I'm not sure how to properly use the cross reference feature, I can't seem to figure out how to get it to use just a D value. It seems to only want to reference an entire block.

         

        Edit: Got it figured out. Each D0, D1 and D2 are only used once. Rungs 32, 35 and 37 respectively. They're just destinations for the counter values to get moved to that the panel then reads and displays.

         

        I zipped the files and the forum does accept that, good thing to keep in mind for the future lol.

        Expand Post

  • HOST_franji1 (HOST Engineering)

    Peeling the onion.

     

    CT2 is tied to D0 (MOVE CT2.Acc D0 in rung #32)). See if CT2.Acc is reset/cleared on Pgm->Run.

     

    If that's true, C210 comes into question. I recommend sticking an INC D999 (unused) above the RST C210 but below the CNT in the output column of rung 31 and monitor D999 to see when it increments (it's hard to detect visually a C bit that is only on one scan, but an INC is useful to see it - you don't care what D999 actually is, just if/when it changes value => C210 came ON for one PLC scan).

    Expand Post

  • HOST_franji1 (HOST Engineering)

    So you determined it is the Counter that is reset. I tested and see that all Counters and Timers get reset when the PLC goes to Run->Program mode and also Program->Run (Terminal switch position is not a true mode - it just Designer change mode vs. the switch). Technically, they get reset the first time the Counter or the Timer instruction is executed after Pgm->Run. But that slight change in behavior description doesn't help with your situation.

     

    SO, I realized that the GLOBAL Timer and GLOBAL Counter do NOT reset EVER unless you explicitly reset them via the RSTT (Reset Timer) or RSTCT (Reset Counter) instructions or if you ever write to the .Acc values directly. So look at using the UDCG (Global Up/Down Counter) and TMRAG (Global Accumulating Timer) instead of CNT or TMR/TMRA. (They still need to be retentive - Ha!)

     

    If you need help with those Global versions, let me know. You will need to add some kind of reset logic to drive a RSTT and a RSTCT if you ever want them to be reset (basically what you had for the Reset legs on the original CNT and TMRA). So in your program C210 contact would drive a RSTCT CT2 box (along with RST C210 coil). Not sure about any TMR's (let me know if you need help).

    Expand Post

      • HOST_franji1 (HOST Engineering)

        Well - I could not post my original answer because someone determined that D***y_Contact is EVIL. So glad we have thought police on these forums. Back to the real world...

         

        Good. I'd feel more comfortable with a NO $Off contact on the DN leg of the UDCG (or NC $On contact) - reflecting that this UDCG NEVER counts down (vs. the D***y_Contact).

         

        D***y_Contact is probably fine - until it's not 😉.

         

        Try it out - should do what you expect.

        Expand Post
10 of 23

 

Did this information resolve your issue?