FC vs FB, DB

This post:
http://www.plctalk.net/qanda/showthread.php?t=52568

Would be very easy to solve with my global data blocks and FC style of programming:
1. Compare the offline DB to the online DB to ensure timestamps are the same.
2. Backup your project in case something goes wrong.
3. Open your project offline, and then open online.
4. Drag & drop the online DB to the offline project. This will "get" the current working values.
5. Open the DB and add whatever you want to add to it, then download to PLC.

I have used this method to add things to a DB while a process is running and never lost data or had any problems. How would you do this simple & fast with FB, DB method?
 
L D[AR2 said:
Use the help index to find the UC instruction, see below:
Click to expand...

Ah, that is different menu item than the F1 key.
"When the CALL instruction is used for a function block (FB) or system function block (SFB) an instance data block (DB no.) is expressed explicitly in the instruction. For a call made with the UC instruction, you cannot associate a data block in the UC address".

Very interesting, I am learning so much!
 
Last edited:
Paul B said:
This post:
http://www.plctalk.net/qanda/showthread.php?t=52568

Would be very easy to solve with my global data blocks and FC style of programming:
1. Compare the offline DB to the online DB to ensure timestamps are the same.
2. Backup your project in case something goes wrong.
3. Open your project offline, and then open online.
4. Drag & drop the online DB to the offline project. This will "get" the current working values.
5. Open the DB and add whatever you want to add to it, then download to PLC.

I have used this method to add things to a DB while a process is running and never lost data or had any problems. How would you do this simple & fast with FB, DB method?
Click to expand...

Say your DB contains a count value from the process, your method will lose the counts that take place whilst you edit and download the DB.
 
Paul B said:
Ah, that is different menu item than the F1 key.
"When the CALL instruction is used for a function block (FB) or system function block (SFB) an instance data block (DB no.) is expressed explicitly in the instruction. For a call made with the UC instruction, you cannot associate a data block in the UC address".

Very interesting, I am learning so much!
Click to expand...

I have completed code where my main control functions are in FB's called from within the same master FB, all are called using UC.

The main FB has only STAT's made up UDT's, the rest of the blocks have the same UDT's in the same order, up to the point where they need data.

All data is available to all blocks only the first call has an IDB.

IO is added in FC's externally where I transfer it in. So no IO parameters to any blocks.

Very neat.
 
L D[AR2,P#0.0] - true. I've not encountered an installation where it mattered. I have seen where if I upload with the line running and then download with the line stopped, motors start. So I don't do that! I use S5timers so they wouldn't be affected. Now that I have played with your SFB4 timers with global DB I can sure see where it would matter for that! Had a nice couple of hours exploring that code you posted, much obliged.

Repeat: How would you do this simple & fast with FB, DB method?

PeterW - I would like to see your code, if you would be willing to share . Click my name and send a PM if you don't want to post publicly.

With Siemens the level of complexity is a never-ending tower of stairs. Each time I reach the next floor and feel accomplishment I see the next flight of stairs. The beauty of the complexity is the power... I found my comfort zone after a year of exclusive Siemens programming and am still exploring the edges. I have learned much from you guys in just two days with this thread. It really helps to be able to see how others do things.
 
Here's an example project that I've just made up that uses UC FBx from the main FB.

By declaring the same UDT in the STAT area of the FB's, each FB called using UC acts as an extension of the original FB.
If you change the UDT, you must edit each FB and update the interface.

I've also used a UDT for SFB4's interface (as in the previous example project) to allow an array of SFB4 timers to be used.
I've shown two methods of calling SFB4 via FC's

With the first you have to generate the logic for the timer before calling the FC.

With the second method you pass the timer logic in to the FC.
 
LD, I eagerly downloaded this Sunday the 24th (big American Football day, the AFC and NFC Championships) from my home computer and emailed it to myself. I have now had a chance to open it in Step7 and I want to say another THANK YOU for your lesson. I continue to learn from you. I am very much obliged!

I don't know that I would program this way but I am intrigued by the ability to do so. I will say that I am starting a new project and exploring the use of UDT's for common structures. I have been using structures in DB's, so it seems very familiar to me.

The one thing I can see is when I declare a STRUCT in a DB it is very easy to go back and modify it. For example I might have ten identical motors and copy and paste the struct ten times. Then when I want to add a variable I have two options:
1. Re-copy and re-paste the struct ten more times. (With the UDT this is all handled by the software - I need only compile.)
2. Edit each structure's contents to include the new variable. With this method the data in each structure is retained.

The difference is the ability to maintain the current data. But I am sure enjoying learning, thank you for your contributions. :)

Declaring with a UDT is so clean...
 
Back
Top Bottom