Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Garyhlucas on January 19, 2022, 11:45:39 AM
-
My boss came in this morning and asked why a blower was running that was not needed after I installed a BRX36 to replace an AB1400 in a scrap grinder. I hooked up a PC and looked at program code and could see a C9 bit turned on driving the output for the blower. No programs were running except Main and Top and Bottom of scan. I use indirect addressing for all I/O. There are just two programs and neither one was running. In the program with stages all the stages were off. Yet that bit stayed on. I was able to force it off and when I unforced it stayed off. Then I ran the program again and this time 3 bits stayed on after stopping execution, leaving 3 big motors running!
I was taught back in the days of the TI405 about using OUT in stages instead of SET and turning on the same bits as you jump stage to stage to keep them on as needed or they just go off. I have dozens of programs over 30 years that work that way, this is the first time I have seen a failure like this. It could be hazardous.
I cleared the PLC completely and reloaded the program and so far it seems to work correctly over the past hour.
-
No HMIs talking to this BRX36? Is the REST API feature ON? Could another PC be doing this? You might consider whitelisting valid IP addresses that have access to the BRX36's network.
-
No HMIs talking to this BRX36? Is the REST API feature ON? Could another PC be doing this? You might consider whitelisting valid IP addresses that have access to the BRX36's network.
The only way to write C bits remotely is through the native Do-more protocol, so unless it is an HMI or some other PLC doing it through RX/WX, it isn't possible through REST, Modbus, or DL RX/WX.
-
My boss came in this morning and asked why a blower was running that was not needed after I installed a BRX36 to replace an AB1400 in a scrap grinder. I hooked up a PC and looked at program code and could see a C9 bit turned on driving the output for the blower. No programs were running except Main and Top and Bottom of scan. I use indirect addressing for all I/O. There are just two programs and neither one was running. In the program with stages all the stages were off. Yet that bit stayed on. I was able to force it off and when I unforced it stayed off. Then I ran the program again and this time 3 bits stayed on after stopping execution, leaving 3 big motors running!
I was taught back in the days of the TI405 about using OUT in stages instead of SET and turning on the same bits as you jump stage to stage to keep them on as needed or they just go off. I have dozens of programs over 30 years that work that way, this is the first time I have seen a failure like this. It could be hazardous.
I cleared the PLC completely and reloaded the program and so far it seems to work correctly over the past hour.
That's concerning. SET leaves the state active, OUT gets shut off through termination. If you have an example of a program that is leaving OUT coils enabled after termination of the stage, program, or task, I would really like to have the code.
One major thing happening when you cleared and reloaded the PLC is the clearing of all retentive memory. I have seen cases where stuff was just a little off until image register was cleared, and then everything was fine. I have had my suspicions as to why it might be, but I've never been able to prove anything, things related to how run mode edits try very hard to not bump things. If it were to happen again, please use the retentive memory manager to make a snapshot of the entire image register.
-
...it isn't possible through REST...
Oops. Yeah, I keep forgetting that.
-
Bob,
No HMI, No networking, just my PC to the ethernet port, no switch. I'll send you the program.
This all started because the grinder manufacturer built the machine with 5 start and stop buttons to start 5 motors. You had to start in one sequence and stop in reverse, and you had to wait several minutes for chips to clear out. Stop quickly or in wrong sequence and bad stuff happens, at least 5 times so far! Manufacturer wanted $6000 to come out and reprogram. AB wanted $700 for software to talk to AB1400, only one in the plant. Manufacturer wouldn't give us the program, it was "proprietary" With just the wiring diagram I wrote a new program in one day, two days to install a BRX36 and 3 input modules and convert outputs to 24vdc. $620 for the BRX and modules, sell the AB1400 and two modules for $600 on Ebay. I no longer need an oddball spare PLC for like $1100. Win Win Win!!!
We now have 8 BRX36 plcs in the plant and one spare, with 3 more coming soon.
-
Nothing you are doing should be sensitive to known issues, but for reference, what firmware version are you running?
-
We now have 8 BRX36 plcs in the plant and one spare, with 3 more coming soon.
Do the other 8 BRX36 PLCs have a similar function as this one that is failing? If so, do they leave C-bits ON as well?
-
All programmed in the same way and no problem. It got worse last night, 4 bits stayed on, even through a power cycle, and tripped a 200amp 480 volt breaker when 4 large motors started at once. I have another PLC here, I am thinking replace this one with another and see if the problem goes away.
-
All programmed in the same way and no problem. It got worse last night, 4 bits stayed on, even through a power cycle, and tripped a 200amp 480 volt breaker when 4 large motors started at once. I have another PLC here, I am thinking replace this one with another and see if the problem goes away.
If they're retentive, they will stay ON. If you expect them to turn OFF after a power cycle, make them NON-retentive.
-
Which instructions are you using to turn the bits on? OUT I assume. If you're using something other than OUT, the termination behavior could be doing this.
-
All programmed in the same way and no problem. It got worse last night, 4 bits stayed on, even through a power cycle, and tripped a 200amp 480 volt breaker when 4 large motors started at once. I have another PLC here, I am thinking replace this one with another and see if the problem goes away.
Sorry about that. I tried being very mean to your program and test programs in attempt to duplicate your issue. I was running some things by BobO and he had a look at your program too. He noticed your AUTO Program code block was set to non-retentive. If it so happens that the BRX power cycles, or better yet, reboots for some reason, while AUTO is running, it could possibly leave the C-bits on the OUTs in the ON state when it comes back up. So, you might check your System Log to see if there have been any PLC reboots, or you might want to set AUTO to retentive and try again, or you might want to at least utilize the $tFirstScan System Task to reset those C-bits to zero on first scan.
-
while AUTO is running, it could possibly leave the C-bits on the OUTs in the ON state when it comes back up
Not seeing the code, are you saying C-bits would potentially be active when controller comes back up? How would this be possible if they're non-retentive?
-
while AUTO is running, it could possibly leave the C-bits on the OUTs in the ON state when it comes back up
Not seeing the code, are you saying C-bits would potentially be active when controller comes back up? How would this be possible if they're non-retentive?
He sent it to us.
No. AUTO is his program block that is driving the C bits. It is marked as non-retentive, which means if it was running when the PLC rebooted or power-cycled, it will be off when the PLC restarts. C bits are retentive by default, so since the program block ends (by restarting the PLC) without clearing the bits, they will still be on at startup. Either mark AUTO as retentive, set the C bits to non-retentive, or clear the associated C bits in $tFirstScan.
-
After reading through the help file, I can't determine how setting the AUTO Program to retentive would solve the issue.
-
After reading through the help file, I can't determine how setting the AUTO Program to retentive would solve the issue.
Retentiveness is a design decision. Assuming after a power cycle (or PGM->RUN transition), all the control memory should be OFF (by design), then you are correct. But if after a slight power glitch, you expect your machine to run where it left off, keep everything retentive. It appears even a slight power glitch you expect everything to be OFF (i.e. just about everything needs to be non-retentive).
It's the C bits that also need to be non-retentive, i.e. they need to turn OFF after a power cycle or PGM->RUN transition. Realize that with the AUTO program NOT running after a power cycle, its logic CANNOT turn the C bits OFF (or ON) - they will just be in their retentive state after a power cycle. Hence, why C bits probably need to be non-retentive. It's the same as an unused retentive C-bit - it will be OFF or it will be ON after a power cycle - there is no logic driving it ON or OFF, the retentive value just "is". Just make most things non-retentive (i.e. go to a state of 0) after a power-cycle or PGM->RUN transition.
-
I always set a RSTR for in first scan for any C-Bits that are powering an output for any motor on all of my programs. It solves many issues & I have never had a motor turn on when there has been a power outage.
-
Realize that with the AUTO program NOT running after a power cycle, its logic CANNOT turn the C bits OFF (or ON) - they will just be in their retentive state after a power cycle.
I understand this to mean that with AUTO in retentive, after a controller power cycle, AUTO will pick back up running even if RUN has not been initiated for AUTO. This would essentially pick back up where it left off and potentially be able to terminate bits of interest. I guess I see the problem with this being that if you have a power glitch/controller cycling, all of your outputs are dropping out. Upon restart you're potentially jogging all of your equipment and potentially in an unsafe manner.
Then I ran the program again and this time 3 bits stayed on after stopping execution, leaving 3 big motors running!
This doesn't sound like a reboot/power cycle issue.
-
Then I ran the program again and this time 3 bits stayed on after stopping execution, leaving 3 big motors running!
This doesn't sound like a reboot/power cycle issue.
Agreed. When you say "stopping execution", what do you mean? Do you mean that AUTO program EXITs (i.e. you executed an EXIT instruction from AUTO.) or ?
-
Then I ran the program again and this time 3 bits stayed on after stopping execution, leaving 3 big motors running!
This doesn't sound like a reboot/power cycle issue.
Agreed. When you say "stopping execution", what do you mean? Do you mean that AUTO program EXITs (i.e. you executed an EXIT instruction from AUTO.) or ?
He's got a mix of EXITs and HALTs. Without more info on how the machine runs, it's difficult to say what may or may not be an issue, but you have to peel the onion. Having retentive C bits directly driving outputs, where the only thing driving the C bits are OUTs in a non-retentive program block is a formula for trouble. He needs to start with that.
-
I understand this to mean that with AUTO in retentive, after a controller power cycle, AUTO will pick back up running even if RUN has not been initiated for AUTO. This would essentially pick back up where it left off and potentially be able to terminate bits of interest. I guess I see the problem with this being that if you have a power glitch/controller cycling, all of your outputs are dropping out. Upon restart you're potentially jogging all of your equipment and potentially in an unsafe manner.
Correct. This is first issue I'd like him to resolve. Either AUTO needs to be retentive, or the C bits need to be cleared by some other method (make non-retentive or clear on startup). It's up to the developer to decide which makes best sense, but retentive C bits driving physical outputs without any logic driving them at startup is at least one formula for trouble.
I agree that there is likely more to the issue, but you gotta clean things up as you identify them. I don't see how it could happen in the code, but I'm wondering if there is some unexpected interaction between HALT and EXIT. HALT was really intended as an ESTOP, and it is generally my preference that if the supervisor wants to end execution early, that it sets a request and lets the program itself EXIT. With that said, they should work the same, and as far as I know they do. I'm just wondering if there is some subtle interaction that I'm not seeing. There is an answer and we'll figure it out.
-
As many have said, the best way to avoid unexpected behavior is to get the stuff set the way it needs to be on first scan. A while back, I had been using HALT but after reading through the documentation (like you said) it was advised against using HALT in favor of EXIT. I was wondering if he was using HALTs in the Program.
By the way, I hope you guys are getting back up on production. I've placed an order for 24 EBCs, 24 DM1Es and about 150 various analog/digital modules.
-
A couple of things:
1. I can duplicate this kind of bad behavior by inserting a REBOOT instruction and randomly rebooting the PLC while having retentive C-bits and yet non-retentive Program code block using OUTs for the C-bits.
2. If you make a program change to this type of situation, you will get a Warning from Do-more Designer on the Program Check. It will say something like:
AUTO#3(@3) W424 Using retentive element (C109) in OUT coil within a non-retentive stage (AUTO.S1)
This warns you of a potential issue you need to address or at the very least be aware of.
-
As many have said, the best way to avoid unexpected behavior is to get the stuff set the way it needs to be on first scan. A while back, I had been using HALT but after reading through the documentation (like you said) it was advised against using HALT in favor of EXIT. I was wondering if he was using HALTs in the Program.
I don't mean to suggest that it won't work or should be feared, it's really more of intent. HALT is like killing a process. Brute force. Prevents the program from deciding the best way to end. Requesting the EXIT allows the program to do whatever it wants to get to shutdown.
By the way, I hope you guys are getting back up on production. I've placed an order for 24 EBCs, 24 DM1Es and about 150 various analog/digital modules.
Combination of factors. Parts, COVID, retirements, etc. There are bright spots and dark spots. Intel has told us not to expect any of certain parts for a while, but we think we may be getting others. We already have a large supply of parts to build CPUs, so that's one bright spot. Reps have suggested that it will start improving by summer, but who knows. It's really frustrating for everyone.
-
Gary may or may not post, but he confirmed via email that it was because the operator was killing power. Since these posts hang around forever, just wanted to make sure that was entered into the record. It's working fine now.
-
What was the resolution? AUTO to retentive or other?
-
What was the resolution? AUTO to retentive or other?
He's clearing the Cs on startup. Do-more is a little different than DL, in that Cs are retentive by default. They are cleared on program to run, but not at powerup. We probably should've done that differently, but once things get done, we try not to change them.
-
Yes it was the default retentive bits that caught me off guard. On this project I had no need for the program to remember any states, and I thought default was non-retentive. One of the hazards of long stretches with no programming.
Thanks everyone for help.