startup code block applications

Hello guys,

In Siemens PLCs (and I'm assuming most others) there are code blocks that can be designated to run on startup (Siemens OB100 warm restart for example). I'm curious what kinds of things you typically would program into these blocks in industry applications. Any input would be appreciated, thanks!

Anyone?

I'm not that familiar with Siemens but I almost always have a routine that executes for one scan or a short period of time on power up to initialize the machine or system. The routine unlatches anything that could of latched up during running to make certain there are no motions or other odd events on power up. I also set or reset a lot of the acummulating variables to 0 on power up. The goal is to set the system up so it is dead and in a know/consistant state on powerup.

Some PLCs retain values in tags on powerdown (AB) others do not, and others retain only certain tags. I am not certain what structure Siemens uses but you need to think through what you want to happen on power up to eliminate the possibility of a dangerous situation.

I would normally define default parameters for program selection ect. We also put all alarm setpoints in the OB 100 block so that when the system starts up it has these defined.

So basically i would initialize the state of all processes. Maybe ensure all devices are in manual or all sequences are set to reset state. It all really depends on your process and you would need to determine this

For me, there is no "typical".
I try to minimize the amount of code like this that is necessary and program in a fashion that restarting tends to automatically reset itself.

Sometimes I can see, that "always 0" and "always 1" signals are generated in OB100.
I think, that OB100 is strictly related to application. Personally, I used OB100 to handle errors that raises before power down, to set some parameters (if they are not set in DB). I also use FB126 from Siemens for PROFIBUS/PROFINET diagnostics, so it must be called in OB100.

OB100 is used for one-time initialisation routines such as counter cards or communications. I've also used it for things that you don't want to run continously.

Example:

A recent project of mine had loads of scripting in the HMIs that needed to know the size of certain UDTs to calculate pointers for tags. To prevent the need for re-programming in the event of a UDT size change, the size of the UDTs were passed to the HMI as tag values. I wrote a routine that calculated the UDT sizes and called it from OB100 so that after a UDT change, restarting the CPU would correct all the pointer arithmatic in the HMIs.

Nick

I also use OB100 mainly for initialisation routines but in addition for a plant where I know that some parameters in an instance DB will be being changed on a regular basis in order to optimise the process then I'll pre-load these values in OB100 and drum it into the plant people that whenever they modify a paraameter they must also update OB100.

If I know I'm going to be around to do the modification myself then I won't bother with this but instead just update the Initial Values in the IDBs. Unfortunately, for some reason that I don't really understand, an awful lot of people don't seem to know -

a) why it's necessary to do this
or
b) how easy it is to do it

and finish up getting a very unpleasant surprised when, for whatever reason the PLC gets switched offf and then back on.