AB question from a primarily Mitsubishi guy...

[dploof23]

Hello,
I am making changes to a system that has a 5/04 processor and I come from the land of Mitsubishi so I have a question....
I have some counters that used to count production of each 8 hour shift. The plant switched to 12 hour shifts. The total on the counter during an 8 hour shift would never reach 32767 or greater. On a 12 hour shift it does. The old logic had the counters reset by either a manual reset button from the HMI, or the .dn bit of the counter. I removed the reset by .dn bit, and added a second counter to increment when the .dn bit of the first counter becomes active. Then I am doing a CPT command, adding the two counters together and throwing the value in a F8 register.


My question is this...in Mitsubishi land when I put 32 bit data in a D register the next consecutive D register is used to store the data. Is it the same in AB? If I put 32bit data in say, F8:40, does it use F8:41 as well or can I put a different set of 32 bit data in F8:41?


Sorry for the long winded question....


Thanks,
Dave

 

[Operaghost]

It is different. Each element is the proper size to hold its data. F8:0 holds a value, F8:1 holds a completely different value. For example:

T4 uses three words for each element
C5 uses three words for each element
N7 uses 16 bits for each element
F8 uses 32 bits for each element

So you don't need to know the size your data requires, You simply go from element 0 to element 1, 2, 3, etc

OG

 

[drbitboy]

As OG says, F8:0 refers to 32-bits that do not overlap with the 32-bits referred to by F8:1, so when you put one value in F8:0, it does not affect the value in F8:1





TL;DR


In A-B land, F8, because it starts with F, refers to a floating point "file."


I.e. it is a memory area where each item in the file (F8:0, F8:1, etc.) is treated as a 32-bit floating point number. So when the MOV insturction moves the first 16-bit counter value (as a 32-bit FLOAT) into F8:0, it does not affect F8:1, and putting a value in F8:1 does not affect F8:2.



EvenLonger;DR



Just as an aside, why not put a zero into F8:0 on the reset from the HMI? Then, whenever .DN is 1,

1. ADD the counter .ACCumulator or .PresetValue to F8:0, and
2. RESet the counter

At the end of shift, ADD the current counter .ACC value to F8:0. This approach protects against the productivity ever increasing to the point where more than 65,535 items are produced.



Alternatively, if you do not expect to count beyond 65535 in one shift, then you

1. could also leave the counter as is,
2. let the counter .ACC wrap "around to -32768 (from +32767), and [continue] counting up from there," and
3. MOVe the .ACC value (not the bits) into F8:0
4. ADD 32768 to F8:0 at the end of shift either
   • if .OVerflow is 1* i.e. if the wraparound (OVerflow) occured,
   • OR if .ACC is less than 0.
5. N.B. the code will probably need to unlatch the minor error status bit (S:5/0) when the counter .OV bit has a 0-to-1 transition.
6. N.B. This is more involved, and will be harder to follow, three months from now.

Also, instead of a FLOAT (floating-point) file, you might want to create a LONG (signed 32-bit integer) file L9 (or delete file F8 and create L8). Since the process is counting whole products, there is no need for the fractional capability of a FLOAT file.

 

[Operaghost]

I do it a little differently.

While I rarely ran into the upper limit of 32767 (I never let it roll over and count up through the negative range), the method I used when it might be an issue was to count up to 1,000. Then use the DN to add one to a second counter while resetting the first one. Then do a CPT to store the full total in a float. For example:

C5:0.ACC + (C5:1.ACC x 1000) store in F8:0

You have to take care not to let the first counter double count when you reset it. By that I mean the rung goes true and it counts once from 999 to 1000. Then it adds one to the second counter and resets the first counter. The first counter resets, but immediately jumps from 0 to 1 because the rung is still true. I add a one-shot to prevent a double count. Not unique to this scenario. That is always a potential issue with counters.

 

[Corsair]

AB Counter Firmware Problem

The need for the one-shot on the input of the AB counter is due to a persistent firmware bug in the AB CPUs. The RES instruction clears the 16-bit accumulator for the counter (which it should do) but it also clears the history bit that is used to detect transitions of the input (which it should not do).

The PLC class outline download at Corsairhmi.com explains the problem in detail around page 258 in the section entitled 'A Classic PLC Bug'. I think it's existed in everything from PLC-5 to compactlogix. Every company has firmware bugs but few manage to keep them going for 40 years.

Using a 32-bit double integer to accumulate time directly is preferable to using something with a float. The SCUD missile that got past the Patriot battery and killed 28 people was because someone was accumulating time in a floating point value. We need to give some thoughts as to how we handle numerics...

 

[drbitboy]

Ooh, good point OG about the .DN-driven reset, but perhaps the [XIC .DN] rung could assign a 1 to the .CU bit of the counter object after the reset.



On further reflection though, if it needs a one-shot to handle the reset of the counter, which counter has its own one-shot, then wouldn't it be better (cleaner) to simply do this?

 HMIreset
---] [-------[MOV         ]
             [Source     0]
             [Dest    F8:0]



 PhotoEye    OSRstorage
----] [-------[OSR]-------[ADD          ]---
                          [SourceA  F8:0]
                          [SourceB   1.0]
                          [Dest     F8:0]

As much as the counter offers to solve the problem, once code needs to be added to handle the special case to handle overflow, maybe the built-in counter instruction should be abandoned.


Or, what about this for the reset logic:

  C5:0.DN   PhotoEye   C5:1
---] [--------]/[--+---[CTU]---+---
                   |           |
                   |   C5:0    |
                   +---<RES>---+

I think that eliminates the nearly always redundant [OSR]?

 

[Corsair]

Why use counters?

More directly to the question - if you have to put your own one-shot on the input anyway - what is the point of using a counter? Just do an 'Add 1' to a double integer.

Can't remember the last time I used a counter instruction. I always felt like it was too much work to make the instruction happy. The HMI has an easier time hitting the double integer without needing the float conversion.

 

[drbitboy]

The need for the one-shot on the input of the AB counter is due to a persistent firmware bug in the AB CPUs....

That's more a design decision that can trip someone up than a bug, although the difference is probably semantic


A.K.A. "That's not a bug, that's a feature!"

 

[Operaghost]

You can't really call this a bug. It is how it operates. It is clearly documented as such. A bug is when it does not do what the documentation says it should do.

This document you point to might want to explain it as a bug that A-B covers by documenting. But them saying it is a bug, doesn't make this a bug.

They refer to a "history" bit which would be great if they had one of those. There is no history bit. The EN is not a history bit.

OG

 

[drbitboy]

...They refer to a "history" bit which would be great if they had one of those. There is no history bit. The EN is not a history bit.

I think the /CU (count up*) bit of the counter object is the one-shot history bit; there has to be some storage so the instruction increments** the count (C5:n.ACC) on a rising edge only.



* .CD also, for count down
** or decrements




Update: it is confirmed that counter object /CU bit is the one-shot history bit for counting up; see image below and/or attached .ZIP with .RSS and .PDF. This also verifies the [XIO trigger] as an alternative to Corsair's OSR (Post #4)to handle the reset "bug" as suggested in Post #6.

 

[dploof23]

Thank you all for the replies.

 

[Operaghost]

I know we are getting off topic, and I apologize....

In my opinion, the CU/CD cannot be called history bits. They are ENABLE bits. They couldn't be called that because we need one for a CTU and another one for the CTD. They simply indicate whether the instruction is true or not, like any other EN bit.

We would need a separate bit for history, like the storage bit for the OSR/OSF in the PLC-5/Logix 5000 (not SLC though). There just isn't a part of the counter data structure that can be considered a history bit.

Calling it a flaw, bug, or intentional mistake just doesn't fit. Again, my opinion.

OG

 

[drbitboy]

In my opinion, the CU/CD cannot be called history bits. They are ENABLE bits. They couldn't be called that because we need one for a CTU and another one for the CTD. They simply indicate whether the instruction is true or not, like any other EN bit.


...
Calling it a flaw, bug, or intentional mistake just doesn't fit. Again, my opinion.

I can sympathize with those semantics.


That said, when coded in that way i.e. in a context where only one CTU is used, .CU functions as the one-shot history/storage bit, as my code proves, even to the point that you can unlatch it manually to override the one-shot when needed.


Also, IIRC, the A-B non-SLC programming manuals that provide flowcharts of each instruction show that it also functions as the history bit internally.

 

[OkiePC]

More directly to the question - if you have to put your own one-shot on the input anyway - what is the point of using a counter? Just do an 'Add 1' to a double integer.

Can't remember the last time I used a counter instruction. I always felt like it was too much work to make the instruction happy. The HMI has an easier time hitting the double integer without needing the float conversion.

I concur. In a Micrologix with easy access to 32 bit "L" integers, that is what I do. In a 5/04, 32 bit integer math is a little more convoluted, so I tend to cascade 16 bit integers (or counters) as others have shown. I would also combine them to a "real" or float in the PLC if I need to use them for other control reasons or if I am stuck with a poor HMI that doesn't want to do the calculation for me.

 

[parky]

Well, well, RSL does not have 32 bit counters, that's a bit short sighted although I agree with incrementing a Dword.