Help with Micro 1000 program

sorry for dredging up this old post, but a lot of people who don't have access to RSLogix500 have asked me for a PDF copy of the program which I attached to post #39 ... this should make the program available to more people ...

[Necro-post alert]


This came up in another thread; I am posting this in case someone finds this thread e.g. in a search.



FYI: In the VACPUMPS.pdf logic of the previous post, if N7:0 is 3 and bit PUMP_C_BYPASSED is 1, then none of the *_IS_1ST_PUMP bits will be set to 1 after Rung 0006. It will only be that way for one scan. The image below confirms that this happens.


Fixing it is left as an exercise for the user.

greetings drbitboy ...

well, I'll admit to being an old dog – but I'm always eager to learn a new trick ... but still I'm pretty sure (as in willing to bet substantially more than pocket change) that the program I posted above works exactly the way it was intended ...

history: the guy who contacted me about this project (both on and off the forum boards) was working at a hospital – and he was quite desperate to get these pumps working correctly ... after I put the program together, I sent it to him and he downloaded it to his processor ... I am quite sure that it worked correctly right out of the box ... specifically, if he had to make any onsite tweaks to it – I never heard about them ...

anyway ... I'm quite interested in why you say the program wouldn't work ... can you fill me in with some details, please ...

first things first ...

This came up in another thread; I am posting this in case someone finds this thread e.g. in a search.

Click to expand...

can you please provide a link to that "other thread" ... maybe that context would help me see where any misunderstanding is coming from ...

now to your statement ...

if N7:0 is 3 and bit PUMP_C_BYPASSED is 1, then none of the *_IS_1ST_PUMP bits will be set to 1 after Rung 0006.

Click to expand...

let's suppose that N7:0 is indeed equal to 3 – then the EQU statement on rung 6 would be evaluated as TRUE ...

suppose that bit B3:0/3 has the value of ONE – then the XIC for that bit – which is located in the lower branch of rung 6 – would be evaluated as TRUE ...

TRUE logic would cause the MOV instruction on rung 6 to write a value of ONE into the POINTER addressed as N7:0 ...

I think (and hope) that we're both together so far ...

now on to this statement that you made ...

It will only be that way for one scan.

Click to expand...

I'm really not sure exactly what "it" you were referring to ...

note that the CTU (Count Up) instruction C5:0 that you've shown is not actually used in my original program ... in fact, I didn't use any CTU instructions at all ...

so I'm going to GUESS that you have installed your CTU on your new rung 7 as a "testing" device ... probably to see if those three XIO instructions all became evaluated as TRUE at one time – and if so – for how long they remained TRUE ...

if I'm correct in that GUESS, then that might be the reason that we're not fully understanding each other ...

SECRET HANDSHAKE: there's a "trick" with using a CTU counter as a "testing" device when debugging a program ... try using an ADD instruction instead ... something like this:

Source A ... F8:0
Source B ... 1
Destination ... F8:0

try exchanging this little "debugging" tool for your CTU and see if your test results are any different ...

WARNING ... fight the natural impulse to use an Integer location ... instead use a Floating Point address for this purpose ... the reason is that if the value in the Integer ever increases to 32,767 then your RSLogix500 platform will set its Overload Trap bit when it tries to increment the value again ... this can fault the processor if it's not properly handled ... on the other hand, a Floating Point location won't generate an overflow ...

anyway ... if indeed it does turn out that there is a bug in the program that I posted, then I'll sincerely thank you for bringing it to my attention ... anyone who knows me will attest that I have ZERO ego issues ... I wash the dishes ... I do my own laundry ... and I get a $20 allowance once a week – if I behave myself ... I have found it impossible to develop an ego problem on a foundation like that ...

in closing ... the program that I wrote and posted was not a student "lab exercise" ... indeed it was a real-world program – written for real-world equipment ... I did my best to test it out before I sent it to my customer ... and to the best of my knowledge, it worked perfectly right out of the box ...

if I have made a mistake somewhere, then I'll humbly admit it – and I'll sincerely thank you for pointing it out ...

and incidentally, now that I've retired, I no longer have access to any PLC processors ... otherwise, I'd gladly fire this turkey up and give it another chance to surprise me ...

stay safe ... stay well ...

Ron Beaufort said:

well, I'll admit to being an old dog – but I'm always eager to learn a new trick ... but still I'm pretty sure (as in willing to bet substantially more than pocket change) that the program I posted above works exactly the way it was intended
...

Click to expand...

Ron, you can even bet more than "substantially more" because the program was flawless.. It's apparent to me that whoever says this program doesn't work either changed the logic or never even tried to load and run it.

Ron Beaufort said:

history: the guy who contacted me about this project (both on and off the forum boards) was working at a hospital – and he was quite desperate to get these pumps working correctly ... after I put the program together, I sent it to him and he downloaded it to his processor ... I am quite sure that it worked correctly right out of the box ... specifically, if he had to make any onsite tweaks to it – I never heard about them ...

Click to expand...

Ron Beaufort said:

in closing ... the program that I wrote and posted was not a student "lab exercise" ... indeed it was a real-world program – written for real-world equipment ... I did my best to test it out before I sent it to my customer ... and to the best of my knowledge, it worked perfectly right out of the box ...

Click to expand...

I can attest to everything Ron has just said because I'm the one who Ron helped. After completing this project the staff that serviced these pumps couldn't have been more happier when it came to to taking out any of the pumps for service. It saved both them and myself a lot of time. Like Ron said above, the program worked as intended right "out of the box"

First of all, I agree with you about ego: all that matters is understanding what the program will actually do.


So at this point, I have to say "what am I missing?"

Ron Beaufort said:

I think (and hope) that we're both together so far ...

Click to expand...

Yes, and I also think (and hope) you will agree that at that point, because N7:0 either

• started the scan as 3
• OR
• was incremented from 2 to 3 on rung 0001 when the timer expired,

that both A_IS_1ST_PUMP and B_IS_1ST_PUMP are 0 when we exit Rung 0006.



Also, since PUMP_C_BYPASSED is 1, then C_IS_1ST_PUMP will also be 0.





Aaaaaannnnddd, the light starts to come on ...



So either

• N7:0 was 3 and C_IS_1ST_PUMP was 1 at the start of the first scan after someone hit the C bypass button
• OR
  • The scan started with N7:0=2,
  • The timer expired and N7:0 was incremented to 3,
  • XIO(PUMP_C_BYPASSED) was False so C_IS_1ST_PUMP is 0,
  • XIC(PUMP_C_BYPASSED) was True so N7:0 was then incremented and wrapped around to 1
  • PUMP_A_BYPASSED and PUMP_B_BYPASSED must both be 0, because otherwise the sequencer would be disabled and there would be no
    • (timer expires) => (increment+wrap N7:0) chain of events

In either of those cases setting either A_IS_1ST_PUMP or B_IS_1ST_PUMP would be postponed until the next scan, which would not cause any chatter (my concern, and I assume yours) if only one pump was needed (NEED_1ST_PUMP=1 and NEED_2ND_PUMP=NEED_3RD_PUMP=0), just a one-scan, few-ms delay transferring from one pump to the next. That delay is not a big deal.



Although ...


With all three *_IS_1ST_PUMPs set to 0, then all of the other *_IS_2ND_PUMP and *_IS_3RD_PUMP bits would be 0, so all PUMP_* bits would also be zero for that one scan.


So wouldn't there be one scan of chatter when

• PUMP_C_BYPASSED = 1,
• NEED_1ST_PUMP = 1,
• NEED_2ND_PUMP = 1,
• and the system takes TWO scans to toggle from
  • {N7:0=2, B_IS_1ST_PUMP=1, A_IS_2ND_PUMP=1, to
  • {N7:0=1, B_IS_2ND_PUMP=1, A_IS_1ST_PUMP=1}?

And yes, the CTU in my code is there to test/detect the (all *_IS_1ST_PUMP bits = 0) case.




P.S. I used the CTU specifically because I wanted to catch only the rising edges of those ANDed XIOs, although I now realize that, since that True result is ever only one scan long, incrementing an INT by 1 without the CTU-internal one-shot would yield the same result.

Greeting Gary (GMc) ...

thanks for the backup - I'll sleep easier tonight ...

I've written quite a few programs over the years - but I do remember this little one especially ... once my business manager (precious little wife) realized how much more money I could bring home as an instructor - than as a programmer - well, let's just say that (like most married men) I'm not always the master of my own destiny ...

anyway - I haven't heard from you in years, dude ... give me a call sometime and let's shoot the breeze ...

send me a PM if you've lost track of the number ... I don't keep it listed too much anymore ...

best regards - to you and yours ...

stay safe ... stay well ...

Ron Beaufort said:

Greeting Gary (GMc) ...

thanks for the backup - I'll sleep easier tonight ...

I've written quite a few programs over the years - but I do remember this little one especially ... once my business manager (precious little wife) realized how much more money I could bring home as an instructor - than as a programmer - well, let's just say that (like most married men) I'm not always the master of my own destiny ...

anyway - I haven't heard from you in years, dude ... give me a call sometime and let's shoot the breeze ...

send me a PM if you've lost track of the number ... I don't keep it listed too much anymore ...

best regards - to you and yours ...

stay safe ... stay well ...

Click to expand...

Greetings Ron. Great to hear from you. We will have to touch base for sure.. As much as my wife loved the shopping and food in your area maybe we will make a trip there when all this "stuff" goes away and take you two out for a bite to eat.

[updated .ZIP to match the first six rungs; the timer reset logic is now identical to Ron's.]


Here is the current version of what I am working with, with Ron's suggestion for ADDing in addition to the CTU - there is no difference in the result.



The differences are:

• I am not duplicating anything past rung 0006 from Ron's original PDF.
• I am not duplicating the USE_SEQUENCER logic, effectively assuming it is always 1, but since I never turn on more than one bypass bit, that should not matter.
• I am not using the NEED_1ST_PUMP bit to feed the timer, effectively assuming it is always 1.
• I added some initialization in Rung 0000 via a First-Pass brange in parallel with the timer
• [Update: now uses Ron's timer reset logic] I am cycling the timer in a different way; that could make a difference; I suspect not, but will certainly test it.

I fully recognize Ron "Look for a 1" (briliant) B. is much more experienced than me at this and fully expect to be wrong (and learn summat); this is not about ego, nor is it David and Goliath. I spent a long time looking at this and testing it before I posted my findings. I will gladly put on my sheepish grin when I am proved wrong; trust me, I'm an engineer (i.e. that won't be my first sheepish grin).


Although I obviously don't know the actual system, I suspect one-scan - a fraction of an AC cycle - of chatter might not be noticed in the real world, once every fifteen minutes and only when C was on bypass, unless someone was looking for it, but it would bug the heck out of me to know it was there, and I suspect the same might be true of Ron.


In the words of a wise man: stay safe; stay well.

Here is the other thread (where this thread was referred to):



http://www.plctalk.net/qanda/showthread.php?t=124609

Another difference I forgot to note was the specific bits I used for various things, and I used B3 bits for the bypass discrete inputs in the original; those changes will not make a difference to the parts of the program that cause the one-scan chatter.



Ron, you could set yourself up with freebies RSLogix Micro Start Lite, RSLinx Classic Lite, and RSLogix Emulate500 if you wanted to fiddle with this stuff.


Gary, in the unlikely event I am right, the branch around the GEQ in Rung 0002, as shown in the image below, is one way to eliminate the chatter.

Ron, you could set yourself up with freebies RSLogix Micro Start Lite, RSLinx Classic Lite, and RSLogix Emulate500 if you wanted to fiddle with this stuff.

Click to expand...

thanks for the idea - but honestly I'm determined to get away from the PLC trade as much as possible ... and more importantly - my little wife is determined that I need to REALLY retire ...

I fully enjoyed the work - and it's been very good to me all the way through - but then again, about thirty years is enough ...

giving it up hasn't been easy - but it's sort of like a Band-Aid ... just rip it off and be done with it ...

so now I just read the forum about once a day (sometimes less) and piddle around with projects that are a lot less mentally demanding ...

life is good ...

If I am right, and that's a big if, I just realized it would be every 30 minutes that the chatter would occur, not every 15, when C was on bypass. There would be not chatter when transitioning from A_IS_1ST_PUMP to B_IS_1ST_PUMP, only the other way.

Left to right, top to bottom

The image below is extracted from Ron's VACPUMPS.pdf, and shows in red what happens on one scan to POINTER (N7:0) and to the three *_IS_1ST_PUMP bits over rungs 0004 through 0006, when POINTER is 3, PUMP_C_BYPASSED is 0 or 1, and the other pumps are not bypassed.

An [x] means the value has not yet changed from the previous scan.

My observation is that, if I assume I am as simple as a PLC (i.e. I can follow a PLC's ladder logic), then at the end of rung 0006, all 1st-pump bits will be set to 0 for this one scan when pump C is bypassed, which would cause chatter if two pumps were running (NEED_2ND_PUMP was set to 1 on the previous scan and will be set to 1 again later in this scan on rung 0014).

N.B. it does not matter how the combination {POINTER:3,PUMP_C_BYPASSED:1} occurred: PUMP_C_BYPASSED was 1 and the timer completion incremented POINTER from 2 to 3; or POINTER was 3 and the discrete input PUMP_C_BYPASSED switched from 0 to 1. Either way, the result will be the same: all of the 1st-pump bits will be 0 for this one scan, which will result in all pump bits (PUMP_A/_B/_C) turning off later on rungs 0016 to 0018, again for this one scan.

Again, it's not a big deal:

• this result is likely too short to have a physical effect that is sufficiently different from normal operation for anyone to notice it, who is not specifically looking for it
  • even then it will be masked by the correction on the next scan;
• its duration of one scan is unlikely to damage the pump motors;
• even if there is some damage, it happens very rarely so the cumulative damage over time (years) is going to be too small to be noticed compared to the normal wear and tear of a 45-minute, two-thirds duty cycle.

Whatch it Ron that little wife will have you running around doing all those jobs that you said "Yes I'll do it tomorrow", I know, I'm there