Another Siemens FB vs FC thread.

Yes, I'm sorry, I'm starting this topic again.
In my defense, I promise I tried to read on this forum and using other sources to get a good idea of what to do. Some of the answers I found are dated several years ago, so I don't know if the reasons exposed are still valid (due to new Step 7 functionality).
Probably I don't need a detailed explanation for your suggestions, just a short answer will be enough for me now. I need to make up my mind soon and start coding!

OK, this is the story. I'm very familiar with RSLogix 5000, and I use a lot of UDTs and Add-Ons. Now I started programming in TIA Portal V14, and I want to translate my Allen Bradley code to Step 7. I need to know whether I use FC (Function) or FB (Function Block).

I basically need your suggestions for 2 typical situations I have in RSLogix 5000:
1) Start/Stop motor Add-On.
Used, you guessed, to start and stop a motor. I just assign a Motor UDT to the Add-Ons and the motor is controlled from there.

2) The typical SCP Add-On to scale an analog input.

Thank you very much in advance!

To me, the FB vs FC debate is rooted in a simple question: do you need the block to remember anything from scan to scan internally? If yes (data, timers, whatever) an FB is probably your best bet. If no (like a math formula), then an FC is a good bet.

You can TECHNICALLY remember things in an FC by passing it as an INOUT, but that doesn't scale very well when you have blocks calling other blocks inside other blocks. FBs let you nest pretty deep, very easily (multi-instance). This gets pretty useful once you get the hang of it.

1) Start/Stop motor is probably an FB. The block probably needs to remember whether it is supposed to be on or not, and there may be some watchdog timers (did it turn on in time? did it turn off in time?). It really depends what data is stored in your Motor UDT, and how it all gets used.

2) Scaling is definitely something that would be great in an FC. It's just a math equation, and nothing is dependant on the internal state of what happened last scan. I'll also note that Siemens has Scaling blocks already included, you often don't need to create your own. They're under Basic Instructions -> Conversion operations.

Personally, when I create a block, unless I'm sure something makes sense as an FC, I make it an FB just to be safe. There really isn't much downside.

See the Programming Guidelines manual at the link below for a bunch of officially recommended programming tips:
https://support.industry.siemens.com/cs/us/en/view/81318674

It's not quite a direct comparison, but:

AOI = Function Block (FB)
Subroutine = Function Code (FC)

That's how I think of it, and while I'm sure the Siemens purists out there are grinding their teeth just reading my heresy, for what you wrote above, that's the best way I know of to approach it.

When you create an FB, for example a motor control block, you give it a data structure (which in AB world is all of the input/output and local parameters of your AOI). Then, each time you use it in your code to control a motor, you have to assign it do a DB, e.g. DB123, which takes the format of the data structure you defined. You could think of that DB as the AOI's tag in AB-Land.

Your FB's are called from within FC's.

Hope that helps!

For my 2 cents, I often do scaling in fb's unless it's safe to hard code the calibration. You need to store the calibration constants anyway, might as well keep them there.

I use fc's for calculations and translations. Sometimes you need to do a byteswap in ladder, for instance. I think that was only available in STL (maybe that's not an issue anymore in Tia?), so I made an stl fc that I call in ladder.

I usually treat the FB like I would a subroutine. So it separates the program into bite sized chunks for easy viewing / general layout.

The DB for each FB houses and is written directly to it from the HMI for example.

I treat the the FC like an AOI, which manipulates data from the FBs but wouldn't really make sense if it were in that FB, Comms, HMI stuff etc

ASF said:

That's how I think of it, and while I'm sure the Siemens purists out there are grinding their teeth just reading my heresy, for what you wrote above, that's the best way I know of to approach it.

Click to expand...

Siemens purists wouldn't know what you are talking about from the Rockwell world.

ASF said:

It's not quite a direct comparison, but:

AOI = Function Block (FB)
Subroutine = Function Code (FC)

That's how I think of it, and while I'm sure the Siemens purists out there are grinding their teeth just reading my heresy, for what you wrote above, that's the best way I know of to approach it.

When you create an FB, for example a motor control block, you give it a data structure (which in AB world is all of the input/output and local parameters of your AOI). Then, each time you use it in your code to control a motor, you have to assign it do a DB, e.g. DB123, which takes the format of the data structure you defined. You could think of that DB as the AOI's tag in AB-Land.

Your FB's are called from within FC's.

Hope that helps!

Click to expand...

I agree with this. Siemen's FBs allow multiple instances of code with each instance assigned a unique DB to operate with. That is basically the same as an AOI.

The way that I think of it is:

FC is for a piece of code that will only be ran in one specific way with the same I/O and memory bits every time.

A FB has the potential to be applied to multiple combinations of I/O, but you always want to evaluate them using the same logical process. If you have a test stand with 12 stations performing the same evaluation but with different I's and O's it saves a lot of time to write the evaluation logic one time and just plug in the inputs or outputs that are applicable to that station.

Thank you everybody for your ideas!
I will try to update you guys on what I end up doing.