Good or bad programming please advise

I am programming in Siemens Step 7. I created an FB which controlles a Lenze profibus inverter. In this FB I also use stat variables. The instance DB holds the drive failure bit. (Which is a stat variable of the type bool).

Now I need to make alarms on my HMI if a drive has tripped. The quickest way is that the alarmlist is looking directly to the stat bit inside the instance DB.

Other option: Drive failure is output of FB. I which case I need to uses some merker/bit to link to this output. This cost me extra memory for the same information.

Is it a bad way of programming to look directly into the stat variables of an FB. (read only!)

Just want to know how you feel about it. To me it looks to be the simplest way but it doesn't feel right.

I would normally put all of my HMI data into a seperate DB, it is a throwback from protool and the older OPs but I think it still makes sense.

In most HMI programs, alarms are monitored by polling the relevant tags cyclically. Because of this, it is a good idea to group the alarm tags together in one block.
Following this it is not a good idea to let the HMI poll addresses in IDBs. The alarm tags would be spread out over too many addresses.

There are other alarm monitoring schemes, one is for example to let the PLC send a message to the HMI upon an alarm event. However, the above scheme is the most normal.

JesperMP said:

In most HMI programs, alarms are monitored by polling the relevant tags cyclically. Because of this, it is a good idea to group the alarm tags together in one block.
Following this it is not a good idea to let the HMI poll addresses in IDBs. The alarm tags would be spread out over too many addresses.

There are other alarm monitoring schemes, one is for example to let the PLC send a message to the HMI upon an alarm event. However, the above scheme is the most normal.

Click to expand...

Putting all of the alarms together also makes trouble shooting and expanding the system easier. Think of the guy following you. He may need to find that alarm in PLC.

Okay lets forget the HMI/Alarm.

Do you use the stat variables inside instance DB's directly (ready only) for what ever reason? I think it is easy because I don't need an extra memory for the same information. (This information is already inside the instance DB). Or make this data available outside the FB via an output variable. (In which case you would need an other memory to be able to use it)

There is no problem with reading and writing the instance DBs externally, as long as you know what you're doing. Apart from the link to the FB, they are otherwise identical to ordinary DBs.

Having said that, if somebody else is likely to be maintaining the program later on, then I would certainly refrain from writing to the IDBs. Reading from them should be less of a problem, unless there is a chance that the STAT area in the FB might be modified at some point in the future.

If you extend this approach, don't bother having ins or outs to FB's, just have one big stat area that everything can read/write to !

I treat instance data as "private" and only accessible by function blocks when accessing their parameters or static data.

Werner said:

Okay lets forget the HMI/Alarm.

Do you use the stat variables inside instance DB's directly (ready only) for what ever reason? I think it is easy because I don't need an extra memory for the same information. (This information is already inside the instance DB). Or make this data available outside the FB via an output variable. (In which case you would need an other memory to be able to use it)

Click to expand...

Yes, I use. But with some restrictions: IDB area must be strongly divided to "public" and "private" sections without crossing. Because Step7 haven't this feature, I only group variables properly with delimiters between sections, like ReservedBool, ReservedInt etc (this is useful, because FB interface isn't changed if you require to append variable - renaming doesn't change interface). This method has an advantage: HMI programmer can easy create tags for same type devices by changing DB number only according to template. I can use "public" status variables in another program places too.

L D[AR2 said:

If you extend this approach, don't bother having ins or outs to FB's, just have one big stat area that everything can read/write to !

I treat instance data as "private" and only accessible by function blocks when accessing their parameters or static data.

Click to expand...

I know this is the best way and I think I will programm it like this. But it will cost my a lot of extra plc memory.

It is also much more straight forward if you put ALL of the data to the HMI in one DB. It is much easier to find something using the cross reference. I work on large projects that may have 4 or 5 guys working on the same project. The HMI guy uses a singe DB and can test his screens without the PLC code. The PLC guy can populate the HMI bits after the code is done. When you do startup you can open ONE DB and see what data is changing. It's the only way.

Why not put the data where the program logically requires it, and then, for monitoring purposes, build as many VATs as you need with the data grouped accordingly?

Regards

Ken

L D[AR2 said:

If you extend this approach, don't bother having ins or outs to FB's, just have one big stat area that everything can read/write to !

I treat instance data as "private" and only accessible by function blocks when accessing their parameters or static data.

Click to expand...

I've seen programming where the ins and outs have been left blank at the block calls, the parameters are preset in other blocks by modifying the data in the instance DB's.

Have you an example of this Peter? I must admit, while I can see that it's possible, I don't think I would consider it good programing practice, even if I were convinced, that I was going to be the only programmer working on the project! OK, I must admit that my Top-Down approach t programming, resulting from my background in Process-Control is probably just as difficult for "Maschinenbauer" who prefer the bottom-up approach, but I don't think this is directly comparable. having said that, I agree with Simon, that one big STAT area is probably not a bad approach, if you want to take this route. I stick to my original statement, "It'OK if you know what you're doing." and extend it to say, "preferably, when you are the only programmer who will (probably) ever work on your program".

If the inputs/outputs are referenced using FBInstanceName.ParameterName from within the calling FB, this is ok as the symbolic reference will automatically get updated if the instance interface changes. This is vastly different to referencing a parameter via DB4.DBX0.0 (if DB4 was the instance DB for example) from an arbitrary point in the program.

The programmer set up the input parameters (only input) in a totally different block.

It confused the technicians, as all they saw was the same block called six times in succesion, with six different IDB's and each had 4 input parameters, which needed to have values assigned.

I found he had a seperate block for calculations and instead of storing the results in memory to be addressed at the block calls, he stored the results in the actual IDB words.

This specific programmer (for a large food equipment company in Belgium) was renown to us, as a very good programmer, but he never liked to do the same thing twice, its like he wants to try everything. I learned a lot going through his code.

The problem with the above, is someone changes the FB in a particular way, then there maybe consequences.

After saying that, no-one was going to change this particular piece of code. Any changes by non employees of the supplier would not have been guaranteed.