SLC output remains 1 after download

Yesterday I had a tech make an edit to an SLC 5/01 that had two 15 station systems that operated two pumps. He changed it to one 30 station system that operated 1 pump. When he went online to get the program out and save it, one of the pumps at O:9.0/0 was on and so his data table for O:9.0 had a 1 in bit 0. When he downloaded after his edits, the 1 was still there and O:9.0/0 came on. I went to the data table and tried to make it a 0 but the 1 kept coming back. I searched the ladder and checked the x-reference for anything that may have been turning it on but found nothing. I went offline, set it to 0 and downloaded again and it was fine. Had there been anything connect to the output though thre was the potential for something very bad to happen. Has anyone else seen this?

Do you have any FORCES in the program?

Depending on the application, you may want to clear your outputs at startup.

Good Stuff

HEREhttp://www.plctalk.net/qanda/showthread.php?s=&threadid=11035
There is a lot of good stuff in this thread. It covers all aspects of what can happen.

Did you XREF "O:9" or just "O:9.0/0" ?

care to post the code? ... we'd be glad to take a look at it ...

FLL-ing outputs will force them off on first scan but if there is a set memory bit that is writing to output, that will not change anything. the only way is to crossref affected output bit (and word) and see what is writing to it.

Others are providing helpful logic to clear outputs at startup (if this is needed). But this may help explain what ChuckM saw.

The uploaded program had the output on at the time of upload. On download, the PLC's output (O) table was filled with its saved contents including this '1'. There was nothing in the, now revised, program referencing this output so there was nothing to turn it off.

He noted that you can't just go to an output data table and change the '1' to a '0'. The running system won't allow it.

Forcing an output does not change the output table. It merely substitutes your 'force' as the source of the information to send to the actual physical output instead of the location from the data table. You may notice that if a program references the state of an output as a contact, that contact does not change during a force as it is refering to the output data table, not the actual physical state of the output.

Hee also found that you can change the 'O' data table when OFFLINE. He changed it and re-downloaded the 'fixed' program.

The PLC was acting correctly - it is not a 'bug'. It's just something we need to be aware of. If the PLC had, on its own, turned the output off, just because there was nothing actively turning it on in the program, then that would have been a serious 'bug'.

I don't know about the 5/01, but with the 5/03 and /04 if you set an unprogrammed bit in the data table, it stays set, and if you reset one, it stays reset. Another way to do it is righ click, then toggle bit.

Ken Moore said:

Depending on the application, you may want to clear your outputs at startup.

Click to expand...

I'm going to start doing something along that line from now on I believe. Although I know I have had to have done what this tech did myself (download/edit/upload) a thousand times, I've never seen this happen. I'm going to try to recreate this I think when I have some spare time with different processors and see what happens.

OK - our company is dealing with Micrologix right now when we're using AB. I'll attempt to recreate my experience when one of those comes up again. Also I think I have an old SLC-500 (the 'brick type') under the bench so I'll haul it out and try it. I KNOW I saw this phenomenon on some AB (probably a SLC). Sorry if I generalized my description. Though it may have been the state of RSLogix (or possibly even APS) at that time that caused my online output change failure. I believe him when he says that he sees nothing affecting the bit and failure to turn it off. Besides, going offline, setting it to zero and downloading would have no net effect if something in the ladder was keeping it on.

Another possibility.......

Maybe the Data File had Static Protection enabled. This would prevent the user from changing the data but would allow the logic to affect it.

I seem to remember way back in the past that Static Protection was automatically enabled on the Output file. It no longer does this by default.

Also, it only takes effect while online. Offline they would have been allowed to toggle the bit.

OG

That's a good call, Operaghost. ChuckM is using a 5/01, which has output file static protection explicitly enable (you can't change it). That certainly sounds like his problem (feature?).

I have only worked with the 5/03 and later, which default to no protection. I never even noticed the protection selection in the data file properties. You learn something new every day.

Keith

just to close the loop on this one ...

and the winners are (in order of posting):

bernie_carlton ... operaghost ... kamenges ... and sorry if I missed anyone else ...

[attachment]

and my excuse for not already knowing this myself is that I've never really worked with the older SLC-500 "fixed" or SLC-5/01 processors ... at least that's my story and I'm sticking to it ...

Thanks for the replies. That clears up the confusion and apparently why many of us (at least not I) have seen it happen. This was on one of our few 5/01 processors.