AB question from a primarily Mitsubishi guy...

drbitboy said:

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.

Click to expand...

I understand what you are getting at, but because the counter increments on the rising edge of the CU and not the rising edge of the logic preceding it, it just does not have the capability to give us a history. There is nothing to tell it that the logic ahead of it has or has not changed state. That's not a flaw or a bug. It's just how it works.

The only instruction I can think of off the top of my head that provides a sort of history is the BTR/BTW (PLC-5) and MSG instructions. With those, the EN turns on when the logic goes true and then if the rung goes false it remains set until the DN or ER is set. That provides more of a one-shot/history than any other instruction. Unlike the CTU/CTD where they simply mirror the status of the rung logic preceding it.

To me, this timing chart (PLC-5) does not show any sort of history function

OG

parky said:

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

Click to expand...

The 5000 has 32-bit counters. The PLC-5 and SLC 500 were designed in the 1980's and do use 16-bit counters.

Using an ADD +1 certainly works. It just does not provide the automatically generated status bits, preset, and accumulator that are part of the counter instruction. I would say that in most cases, I am not worried about a double-count. I count six items, then take an action, then reset the counter. So, logically a reset cannot occur while I am also counting. Most of the time that is the case, but not all.

So I don't always need the one-shot. With an ADD +1 I would need it every time.

OG

I was talking about 500 as the OP stated not 5000

Operaghost said:

I understand what you are getting at, but because the counter increments on the rising edge of the CU and not the rising edge of the logic preceding it, it just does not have the capability to give us a history. There is nothing to tell it that the logic ahead of it has or has not changed state. That's not a flaw or a bug. It's just how it works.

Click to expand...

Maybe OG and I have a different meaning of the word "history bit?" Because this is what the PLC-5 instruction set manual says about .CU:






I.e. it is set "when the rung goes true" - how is that not a one-shot storage bit? I had assumed my "storage bit" and OG's "history bit" were the same thing; perhaps they are not?



note that the same manual has the same note about prescan for the (what I call "storage") bit supplied to the ONS instruction:

drbitboy said:

Maybe OG and I have a different meaning of the word "history bit?"

Click to expand...

I think that is the case. To me, a one-shot is true for just a single scan each time the rung goes from false to true. A storage bit is set until something acts to reset it. I have never referred to a history bit, or even thought about that term until this thread.

But I think we both agree that calling it a bug, a flaw, or a programmer mistake is incorrect just because someone doesn't think it should work that way.

OG

The irritation is that the bit - whatever you choose to call it - is reset by the CTR instruction so it throws a false extra count after the rollover to zero. People avoid that by one-shotting the input to the CU instruction. I've never seen this in any other PLC.

Corsair said:

The irritation is that the bit - whatever you choose to call it - is reset by the CTR instruction so it throws a false extra count after the rollover to zero. People avoid that by one-shotting the input to the CU instruction. I've never seen this in any other PLC.

Click to expand...

My issue is simply that you call it a bug or a firmware flaw that they tried to cover up with documentation. I worked for A-B/RA for a long time and get a little defensive even though I am no longer connected with them.

Yes, it is an irritation. I taught for a long time and I always pointed it out. But logically it is doing exactly as it is documented. It actually made for a great "logic" teaching moment to show a double count and force the students to figure out why.

And of course there are other resolutions besides a one-shot.

OG

Operaghost said:

My issue is simply that you call it a bug or a firmware flaw ...

Click to expand...

Ah, that was Corsair; I called it a "design decision" and a "feature."


I don't think of it as a bug, although I did allow that bug vs. design could be a semantic thing.

Corsair said:

The irritation is that the bit - whatever you choose to call it - is reset by the CTR instruction so it throws a false extra count after the rollover to zero. People avoid that by one-shotting the input to the CU instruction. I've never seen this in any other PLC.

Click to expand...

It's not the rollover to zero, its the .DN bit.


At the risk of being impolitic, Corsair's actual issue is caused by two ill-advised strategies:

• using cascading counters because 15 bits is not enough
• making the reset dependent only on when /DN is 1
  • once .DN is 1, the reset should be delayed until the scan when the trigger rung goes false
  • i.e. until the scan when /CU is 0 after the CTU instruction's rung
  • i.e.

I am not sure the claim no other PLC does it this way is valid. There are probably lots of issues like that. I tried whining about a Siemens timer not being reset by feeding it the equivalent of [XIO timer.DN]; that dog d/won't hunt.

Just to add my 2c into the discussion.....

Counter .CU and .CD bits are "history" bits, in the sense that they are inspected only on subsequent scans of the CTU and CTD instructions respectively.

They will, in any one scan, be set if the instruction is "enabled" on a "true" rung or branch, and reset if the instruction is on a "false" rung or branch.

So IMHO they are "history" bits, because they tell the processing of the instruction on any scan the state of the rung on the previous scan, and lets face it that could be seconds, minutes, days, weeks, or years later.

And to add...

"RES" a counter must also "RES" its "history" bits, that's what RES does, Reset.

If you just want to clear the current count then CLR Counter.ACC works just fine.

You don't need to worry about the .DN bit, that will always be set to true whenever .ACC > .PRE - always even if the rung the counter is on is "false"., set purely by .ACC >= .PRE

Thanks to daba, I realized a simpler solution to the OP's query is to set the .ACC value to -32768 at the start-of-shift reset, thento get the count at the end of the shift.


No need for additional counters or overflow checks.