Counters?!?!

[drbitboy]

Using bit 0 as a proxy for even/odd is "creative?" Am I that non-normative ?

Assuming @robertmee has it correct (a/c alternating b/c until last day of schedule, then c only until the reset after day 7). I agree it can be done either way i.e. with [CTU C5:n] or [ONS ADD N7:n]. So the choice should be which is easier to debug.

ONS+ADD integer pro/CTU con

• 1-based logic for days 1-7
• No need to know the number of days in the schedule to know if the schedule is past, as rotary discrete inputs can be used directly (see second image below) when comparing the integers to choose A vs. B.

CTU pro/ONS+ADD integer con

• the oneshot is built in
• The CTU also provides the /DN bit, so simple XIC/XIO are used instead of integers compare
• CTU keeps counting after /DN becomes 1; CTU can have its preset be the number of days in the schedule, but CTU does not reset until it reach 7; then A/C or B/C when XIO C5:n/DN is much cleaner than all of those complex EQUs:

The scheduling logic is fairly similar (CTU on the left; ONS_ADD on the right):


The logic to choose the pump is far more concise with niceties like /DN of the CTU and bit 0 for even/odd (left), but the brute force approach is still quite readable without them (right).

 

[robertmee]

He has an external clock signal input that's on for duration needed for Pump A and B. So your minute counter is replaced by an XIC of that input. No LIM and counter needed. The clock input isn't a minute pulse the way I read it. The pulse comes on and stays on for the hours that Pump A or B are needed, then turns off until the next day. So rising edge is new day and duration of pulse, pump A and B run.

Also the logic on the left doesn't account for the schedule selection that I see. Pump A doesn't run on every even day when 4 or 5 are selected, for example.

 

[drbitboy]

Also the logic on the left doesn't account for the schedule selection that I see. Pump A doesn't run on every even day when 4 or 5 are selected, for example.

Actually, moving the rotary switch assigns the schedule length to the value of the .PRE of the counter, so preventing A and B from running after the scheduled number of days is handled by the XIO /DN instruction.

And the time-of-day boolean being handled by an external signal eliminates a boatload of silliness in the rest of my code.

 

[robertmee]

Actually, moving the rotary switch assigns the schedule length to the value of the .PRE of the counter, so preventing A and B from running after the scheduled number of days is handled by the XIO /DN instruction.

And the time-of-day boolean being handled by an external signal eliminates a boatload of silliness in the rest of my code.

The schedule is always 7 days. Pump C runs on the off days. Read the last sentence of the original OP's proposal. "Rinse repeat 4 days.3 days pump C on". On a 4 day schedule, the last 3 days, pump C is on.

 

[drbitboy]

The schedule is always 7 days. Pump C runs on the off days. Read the last sentence of the original OP's proposal. "Rinse repeat 4 days.3 days pump C on". On a 4 day schedule, the last 3 days, pump C is on.

Yes, I did finally get it. E.g. on a 4-day schedule:

• days 1-4
  • A/B from 6AM to 7PM
  • else C
• days 5-7
  • C all day.

 

[drbitboy]

The scheduling using CTU (left) is has more overhead because the rotary switches change the CTU preset, but otherwise the daily scheduling (increment day count on falling edge of external clock digital input) itself is similar:

[N.B. update: this code is missing a one-shot instruction before the ADD on Rung 000 on the right.]

​

The pump selection using integer and EQU compares (right) is more involved because of the multiple EQU branches (plus XICs on later days), while the rotary switch => preset in scheduling above makes that much simpler on the left. but either is readable.

Again, I assume OP will go with whatever they understand and/or can read more easily, and along that line @robertmee's approach on the right hardly needs comments.

Note: we could save a sub-branch on the right by doing

XIO ROTARY_SET_TO_4_DAYS
​

assuming rotary switch always has one of the three values, instead of

BST XIC ROTARY_SET_TO_5_DAYS
NXB XIC ROTARY_SET_TO_6_DAYS
BND
​

​

 

[robertmee]

The scheduling using CTU (left) is has more overhead because the rotary switches change the CTU preset, but otherwise the daily scheduling (increment day count on falling edge of external clock digital input) itself is similar:

View attachment 67177
​

The pump selection using integer and EQU compares (right) is more involved because of the multiple EQU branches (plus XICs on later days), while the rotary switch => preset in scheduling above makes that much simpler on the left. but either is readable.

Again, I assume OP will go with whatever they understand and/or can read more easily, and along that line @robertmee's approach on the right hardly needs comments.

Note: we could save a sub-branch on the right by doing

XIO ROTARY_SET_TO_4_DAYS
​

assuming rotary switch always has one of the three values, instead of

BST XIC ROTARY_SET_TO_5_DAYS
NXB XIC ROTARY_SET_TO_6_DAYS
BND​

View attachment 67178​

Still not going to work. The CTR must just have a fixed preset of 7 days. You don't change the preset based on the schedule. You compare the schedule and enable/disable pumps on the 5th or 6th day. Days 1-4, Pump A or B always run. But on a 5 or 6 day schedule, the odd/even don't work when the preset is fixed at 7. That's why I think the EQU comparisons to the days is the easiest approach. Your Right side logic is exactly correct. The left side logic is going to cycle on the schedule, not 7 days.

Back to my post on page 1, the pump sequence is as follows:

4 day schedule: A/C, B/C, A/C, B/C, C, C, C
5 day schedule: A/C, B/C, A/C, B/C, A/C, C, C
6 day schedule: A/C, B/C, A/C, B/C, A/C, B/C, C

 

[drbitboy]

Still not going to work. The CTR must just have a fixed preset of 7 days.

Not quite. LOL, this is why, even though both approaches work, yours is better: it's easier to understand and read what is happening, even though it may at first appear more complex visually.

TL;DR

• I agree the CTU needs to reset its .ACC after 7 days
  • and my code does
  • Cf. Rung 0001 of [LAD 7 SCHEDULING] clears the accumulator back to 0 when it reaches 7
• I am using the CTU .PREset to model when the scheduled days (4 or 5 or 6) are over,
  • *** N.B. but I am also allowing the CTU to count beyond the scheduled days i.e. to 7
  • This means I can use the CTU /DN bit to more simply choose between {A/B or C}, and {C-only} in the CHOOSING routine, without all the spaghetti branches of EQU[+XIC] instructions
  • Not that the spaghetti is a problem; obviously my more concise code is more confusing even though it is visually cleaner.

P.S. In my previous post with images, I post forgot the one-shot before the ADD on Rung 000 of routine ALT_SCHED (second image, right side).

P.P.S. I simulated the external clock discrete input, and both methods work identically, producing identical outputs.

 

[robertmee]

Not quite. LOL, this is why, even though both approaches work, yours is better: it's easier to understand and read what is happening, even though it may at first appear more complex visually.

TL;DR

• I agree the CTU needs to reset its .ACC after 7 days
  • and my code does
  • Cf. Rung 0001 of [LAD 7 SCHEDULING] clears the accumulator back to 0 when it reaches 7
• I am using the CTU .PREset to model when the scheduled days (4 or 5 or 6) are over,
  • *** N.B. but I am also allowing the CTU to count beyond the scheduled days i.e. to 7
  • This means I can use the CTU /DN bit to more simply choose between {A/B or C}, and {C-only} in the CHOOSING routine, without all the spaghetti branches of EQU[+XIC] instructions
  • Not that the spaghetti is a problem; obviously my more concise code is more confusing even though it is visually cleaner.

P.S. In my previous post with images, I post forgot the one-shot before the ADD on Rung 000 of routine ALT_SCHED (second image, right side).

P.P.S. I simulated the external clock discrete input, and both methods work identically, producing identical outputs.

Ah, I completely missed you were not resetting the counter on the .DN bit. Yeah, that's going to confuse the hell out of a tech....lol.

Now....Which method is going to allow easier schedule change, when they decide to run A two consecutive days, then B two consecutive days . I'm dragging you slowly but surely to method 2 In fact, replace the EQU's with Integer Variables, and you could easily build an HMI to do any pattern you wanted. Not so much with method 1.

 

[drbitboy]

Ah, ...

"that moment of dawning comprehension we live for"

I agree it's not obvious in the code (well it is...), but to be fair, it was explicitly called out in the comments.

Now....Which method is going to allow easier schedule change, when they decide to run A two consecutive days, then B two consecutive days .

Hah! I'll just move over one bit .

But seriously, neither: are you going to change those EQU/XIC branches when they do that?

No, this is way better handled than either of our approaches via an SQO instruction, which replaces most of our spaghetti with one instruction, the outputs for which can be updated from an HMI.

 

[robertmee]

"that moment of dawning comprehension we live for"

I agree it's not obvious in the code (well it is...), but to be fair, it was explicitly called out in the comments.



Hah! I'll just move over one bit .

But seriously, neither: are you going to change those EQU/XIC branches when they do that?

No, this is way better handled than either of our approaches via an SQO instruction, which replaces most of our spaghetti with one instruction, the outputs for which can be updated from an HMI.

No, see my update. I'm going to have the constants as N7:x integers and change them from an HMI

And who reads comments....lol

Anyway, fun excercise....80% of the challenge was interpreting what the OP wanted. Pretty much mimics the real world.

 

[Steve Bailey]

80% of the challenge was interpreting what the OP wanted. Pretty much mimics the real world.

Aint that the truth!

 

[Steve Bailey]

80% of the challenge was interpreting what the OP wanted. Pretty much mimics the real world.

Aint that the truth!

 

[plvlce]

Aint that the truth!

Aint that the truth!

So true it bore repeating!

 

[DustyC]

Just want to thank everyone for the input. I have run the first few line and it seems to be working! I will finish writing the logic later today. I just needed to assign a number to my N7 intigers for equal comparison. Thanks again everyone, so glad I found this site!