muusic_man
Member
Just about everything I didn't write....
Yup.
Just about everything I didn't write....
So many bad programming examples are the result of violating the first rule of holes: "When you find yourself in one, stop digging."so they called in a third-party programmer to reprogram the machine and instead of removing the old logic and re-writing as much as possible, he just disabled some rungs and made others true 100% of the time with empty branches
So many bad programming examples are the result of violating the first rule of holes: "When you find yourself in one, stop digging."
One certain OEM we've got machines from had a fetish for oneshots and OTL/OTU to control systems in place of step sequences. The oneshots make troubleshooting anything a nightmare.
Far worse was a packaging machine. Worked great until company changed label suppliers and machine wouldn't work right anymore. Adjusting settings and sensors made no difference. Finally opened up code to find it didn't use any sensor after the first one in line, and the program was all based exclusively on cascading timers. Ended with complete rewrite.
#6 writing a 2400 rung program, getting it to run.
then you print it out 1 rung per page, throw it up in the air.
recode the program the way you pick up the papers.
debug it to run, then turn it over to the customer.
YES, it happened to one of my customers....
When I add a test feature or temporary workaround to something, I always preface the tag names with my initials, so I can easily take out the logic when I'm done, or remove my initials to leave the good logic in place.
But I wasn't always disciplined about taking it out, or also putting in initialization logic.
A few weeks ago a customer came to me with a problem in a system that had been running well for 5+ years. Sure enough, we found a boolean tag in the True state labeled "KIR_Test_Cycle1". Somebody must have poked a value into it during troubleshooting, because once we toggled it off the machine began normal operation again.
I could have avoided that by putting an OTU into the Initialization routine so that an ordinary power cycle would have un-done that mischief.