AB question from a primarily Mitsubishi guy...

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.

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

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

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 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.


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:


xxx.png



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:


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

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
 
Last edited:
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.
 
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.

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
 
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.


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.
[XIC C5:0/DN XIO C5:0/CU RES C5:0]
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, then
[SUB C5:0.ACC -32768 F8:0]
to get the count at the end of the shift.


No need for additional counters or overflow checks.
 

Similar Topics

I'm been deciphering a program for a press here. I've gotten most of it deciphered using the manual to understand the instructions (first mitsu...
Replies
5
Views
37
OK. You guys helped me out a bunch with my first Siemens question. I found a bunch of issues with integrity checking the PLC programs I was...
Replies
3
Views
123
Hi all, Writng a FB in ST on Beckhoff TC for a pulser which turns on and off on a cycle, is paused by turning bControlInput to FALSE, but resumes...
Replies
4
Views
108
Hello folks! Never been here before but I have a question that's been bugging me for a while. I recently got a job at a chemical plant that's...
Replies
8
Views
289
I am currently backing a Micro Logix 1100 and no-one seems to have the file for me to upload from. Is there a way for me to upload the project off...
Replies
15
Views
394
Back
Top Bottom