CTU reset question

[Jlandwerlen]

Originally Posted by drbitboy

Interesting, because that has worked for me in the past (i.e. [MOV 0 blah.ACC]).

It did work but just like doing a reset the counter incremented. The whole issue is around keeping the trigger high while doing a reset.

[cwal61]

Use the CLR instruction on the CTU ACC. This will leave the CU bit set and reset the CTU ACC to 0.

XIC CTU.DN CLR CTU.ACC

[drbitboy]

Diagnosing the process, one scan at a time; see images below.

      .ACC   /DN   /CU     Trigger

(1)     2     0     0         0  Logging starts, ~5ms before count from 2 to 3

(1a)    2     0     0         0  Logging scans over ~5ms until trigger becomes 1

(2)     2     0     0         1  Scan of trigger rising edge and before count;

                                  /CU is 0 while trigger is 1 => rising edge

(3)     3     1     1         1  Scan of trigger rising edge and after count;

                                  count (.ACC) is 3 = .PREset so /DN is 1;

                                  RESet will occur on last rung of this scan

(4)     0     0     0         1  Scan after trigger rising edge and before count;

                                  RESet has assigned 0 to .ACC and 0s to all status bits,

                                  /DN and /CU specifically are now 0s

(5)     1     0     1         1  Scan after trigger rising edge and after count;

                                   since /CU was RESet to 0, trigger value of 1

                                  is detected as another rising edge on this scan,

                                  even though trigger was 1 on last scan

(5a)    1     0     1         1  Subsequent scans over the next ~100ms; no change

xxx.png

yyy.png

[drbitboy]

Originally Posted by ceilingwalker

Tried this also......same result.

Hmm, maybe Logix 5000 is different from MicroLogix:

   .ACC  /DN  /CU Trigger

(6)  0    1    1     1     Scan after trigger rising edge and before count;

                             CLeaR has assigned 0 to .ACC, but all status bits are unchanged,

                             /DN and /CU specifically are still 1s

(7)  1    0    1     1     Scan after trigger rising edge and after count;

                             count (.ACC) is still 0 i.e. there has been no "false count" to 1

                             because /CU is still 1;

                             /DN has become 0 since .ACC is less than .PRE.

(7a) 1    0    1     1     Subsequent scans over the next ~100ms; no change