counters and accumulators

Mwils

Member
Join Date
Jan 2021
Location
Salt Lake
Posts
15
I have a questions on counters and accumulators and how do the accumulators work as a preset?
I have a program that uses the accumulators as the preset for positioning motors.
C5:1
preset: 32000
acc. N210 (Motor POS) per recipe.
 
It looks to me like the counters are used to track the position of the object as it moves
The Counter .ACC is the position from home.
It will work fine as long as the speed is not to fast
ItÂ’s interesting to see it shown that way
The one shotÂ’s are not necessary at the CU and CD inputs of the counters. The CU and CD are by default edge triggered input They only add or subtract a 1 on the leading edge when the input goes from False to True.
I notice that the counters are all in a subroutine, my guess is that the subroutine is call with an interrupt in the main program to get a faster update time
Why they didnÂ’t just use High Speed counters for the position is a question. The High Speed counters will work much better and not miss any counts. They are not dependant on scan times for the counts
And operate independently of the plc scan
 
I have a questions on counters and accumulators and how do the accumulators work as a preset?
I have a program that uses the accumulators as the preset for positioning motors.
C5:1
preset: 32000
acc. N210 (Motor POS) per recipe.


I am having trouble understanding the question:

- The counters count up and down, with the CTU and CTD instructions.
- The accumulators are the part of the counter that keeps track of how many counts.
- when the accumulator counts up to the preset, the Done bit (.DN) is set



You can move the accumulator of a counter (ie C5:1.acc) to a preset if you like (or anywhere else) but I don't see that happening in the code that you posted.


C5:1 counts up and down based on the input. The value of the accumulator in the code posted is equal to 212, not 210

A preset is something that the counter counts to and then the done bit (.DN) is set. The counter will keep counting, but the .DN bit will stay on until the counter is reset. I don't see any code to reset the counter. And I don't see a recipe loaded from an HMI or another part of the PLC data table in this code.
 
I believe that there is other logic that does compares with the .acc as 32000 is the top limit of the counter (people just put the highest value in there if they are not using the .DN bit), so somewhere in other programs they are probably using compares with the accumulated counter values against either fixed values or values stored in integer words i.e. N7:x
As already stated, the one shots are not required as counters only trigger on rising edge in this case.
 
Actually for the particular approach used in this routine, I think* the one-shots (ONS instructions) may be necessary on rungs 0000 & 0001, as well as on 0003 & 0004, but they are not required on 0002.

That said, all one-shots could possibly be eliminated if the logic were refactored (reorganized but keeping the same behavior) by

  • removing the initial XICs on rungs 0000 and 0003
  • removing rungs 0001 and 0004
To be sure we would need to see the rest of the code, specifically,

  • what drives the timer instructions using T4:15 and T4:16
    • are these TON or TOF debounces?
  • and when this routine is called
    • periodic interrupt?
    • event-driven interrupt?
    • called from continuous task?
* Time for some experiments ...
 
Last edited:
P.S. I think @parky is right (as usual): the .PREsets of 32000 are values that their respective .ACCumulators will never reach, so the .DNs are not being used; the CTU/CTD instruction pairs are simply alternatives to [ADD count 1 count]/[SUB count 1 count]; the latter would require the ONSs, of course.

P.P.S. @Mwils/OP: try printing .RSS in landscape orientation; it may clean things up a bit.


P.P.P.S @Mwils/OP: is this successful code for a working machine, or is this code that does not yet do what you want, or is it summat else?
 
Last edited:
.....
A preset is something that the counter counts to and then the done bit (.DN) is set. The counter will keep counting, but the .DN bit will stay on until the counter is reset. I don't see any code to reset the counter. And I don't see a recipe loaded from an HMI or another part of the PLC data table in this code.

Slightly incorrect ..... The .DN bit is maintained by the scan of the instruction, whether it evaluates True or False, to be ON when the counter's Accumulator is Greater Than, or Equal to, the Preset.

Which means that if there are Counts Down, that take the .ACC less than the .PRE, the .DN bit will go Off.

This is a background function of the Counter, and you can make the .DN bit go ON and OFF by changing the .PRE and .ACC values, regardless of whether the Counter has counted !
 
Yup, given the OP's logic leading up to the CTU/CTDs, the ONSs are required.

Indeed. My memory is that this will be true anytime there is more than one CTU or CTD instruction, ie the limit for operation without oneshots is one of each.

This happens because the CU bit provides the oneshot functionality for a CTU in normal operation. It is set to match the state of rung when scanned and increments the accumulator on a false->true transition; if there is another rung that evaluates false while the first evaluates true then the CU bit will oscillate between true and false resulting in a count every scan cycle.

As a related effect, if you have multiple CTU whose true/false state will always be identical, it is the same as having only a single one.

Same thing for a CTD with the CD bit.
 
P.S. I think @parky is right (as usual): the .PREsets of 32000 are values that their respective .ACCumulators will never reach, so the .DNs are not being used; the CTU/CTD instruction pairs are simply alternatives to [ADD count 1 count]/[SUB count 1 count]; the latter would require the ONSs, of course.

P.P.S. @Mwils/OP: try printing .RSS in landscape orientation; it may clean things up a bit.


P.P.P.S @Mwils/OP: is this successful code for a working machine, or is this code that does not yet do what you want, or is it summat else?

Thanks for the print suggestion.
The program is from a working machine.
 
Here is more of the code of the RSS /pdf file. That shows motor movement control. I have been trying to simulate what they're doing to do but it doesn't work the way the machine works. The counter continues to count even with compare instruction in place as they have it:smas:. They are only using accumulator instruction and a CLR instruction but that's is for automation is present and is option selectable from builder.
 
So this code doubles the resolution of the encoders by counting both rising and falling edges.


What drives the timers that use structures T4:15 and T4:16?
 
T4:15 is a TOF and is driven by the VFD fwd output bit.
T4:16 is a TOF and is driven by the VFD rev output bit


So T4:15/DN is 1 when the VFD is moving the motor forward, plus a (brief?) time beyond as the motor coasts to a stop, to catch any edges that may occur?


And the same for T4:16/DN in reverse?
 

Similar Topics

Hi Hope you all are doing well. Iam working on a project with some AOI. I also hate no online edits... lol. My problem occurs when I use a UDT...
Replies
0
Views
12
Hey guys, thanks for reading. I am trying to use a micrologix(1000 or1500) to control 3 hydraulic pumps. I have a time clock to give a signal to...
Replies
38
Views
3,392
iFIX 5.5. We have alarm count database tags with SIM driver and I/O address = "C:AREA-SD:ACK" which is suppose to count the acknowledged alarms in...
Replies
16
Views
1,325
https://www.youtube.com/watch?v=zTOOYWMJg9M . Specifically see 1:46 to 2:11. 3. The Cell PLC is in constant communication with two other field...
Replies
14
Views
3,075
Does the 1100 only have 1 high speed counter, but it can have multiple inputs? And so then the 1400 has 6 HSC and you have a choice of multiple...
Replies
1
Views
1,709
Back
Top Bottom