Rockwell v Tia Portal

Im a rockwell programmer, but I need to do some stuff in TIA Portal.


So in Rockwell i'd create a UDT structure and Pass that in and out of multiple add onStructures, each of these structures would have a Instanst structure in the Local or Global Tags this was used for thing like the timer memory and intermediates when doing calcs etc. Setpoints were either passed in at Addon Call or Read from the UDT.

SO In Tia Portal :
ive defined.

FB1 - FB_Scale_Analog - My Code = ADDON?
DB3- Mem_Analog CH1 - 1st memory Instance = Instanst structure ?
Data type - Sig_DataType - Structure for My Sensor = UDT?


Is a FB the Same as an Addon Insturction
Is the FB Instance ( Mem_AnalogCh1_1[DB3]) the same as the Addon Instance Structure in RockW
Can I pass an Custom Data type in/out like I do in rockwell - is this the correct way or do I just access every thing from the DB3, if this is the case should I define them as TEMP and will they be retained e.g. AnalogSetP - Real -> FB1->Temp or Static. Also what I call instance 2 of FB1?

Sorry for the scatterbrain question but i didn't know how to "google this"

Generally, yes to what you wrote.
An FB in TIA is similar to an AOI in RSLogix. Difference is that in TIA you can download a modified block at runtime with no issues, as long as you dont change the declaration part.

Can I pass an Custom Data type in/out like I do in rockwell - is this the correct way or do I just access every thing from the DB3,

Click to expand...

Generally, data that is expected to be accessed outside the FB should be passed in and out. That includes data that is accessed by an HMI. Unless the data is very simple, always define it by userdefined Data Types.
Data that is being accessed by the FB only should be part of the STAT (static) declaration of the FB.

, if this is the case should I define them as TEMP and will they be retained

Click to expand...

TEMP (temporary) is data that will be discarded when the FB execution is finished. The data will not be retained. If the data is to be retained it should be part of the STAT declaration.

Also what I call instance 2 of FB1?

Click to expand...

This is what I do.
If I have an FB "StandardMotor", I call the instances "IDB01_StandardMotor", "IDB02_StandardMotor", "IDB03_StandardMotor" or something like that.
You dont actually access the IDB data outside the FB, so you do not have to think about it being structured or easy to remember.

The data that is passed in and out and via userdefined Data Types, and usually stored in shared DBs, should be well thought out so you have structures that are well organized. I am guessing it is exactly as you would do in RSLogix.

An FB is equivalent to an AOI.

It has a section of variables called InOut that you can use for passing variables by reference. These can be any type of data type (structure and so on)... In TIA you create a new Data Type, then create a variable in a DB (not the instance DB) of the type you created and in the FB interface section create an INOUT variable for you to pass your variable.

You should never, although you can, access data from the instance DB. If you need that data either put it as OUT or INOUT parameter.

Variables defined as TEMP will not be retained between cycles. If you need an internal variable to be kept between cycles, you can create one in the STATIC area of the FB interface.

I name my instances something that I can relate to. I have FB's for Motors and Valves. So on a Valve, I'd call my instance DB's as VXXXX (V1201, V507, and so on). The FB itself doesn't change name between instances, it will always be called as in my case, fbSolValve.

JesperMP said:

Generally, yes to what you wrote.
An FB in TIA is similar to an AOI in RSLogix. Difference is that in TIA you can download a modified block at runtime with no issues, as long as you dont change the declaration part.

Generally, data that is expected to be accessed outside the FB should be passed in and out. That includes data that is accessed by an HMI. Unless the data is very simple, always define it by userdefined Data Types.
Data that is being accessed by the FB only should be part of the STAT (static) declaration of the FB.
TEMP (temporary) is data that will be discarded when the FB execution is finished. The data will not be retained. If the data is to be retained it should be part of the STAT declaration.

This is what I do.
If I have an FB "StandardMotor", I call the instances "IDB01_StandardMotor", "IDB02_StandardMotor", "IDB03_StandardMotor" or something like that.
You dont actually access the IDB data outside the FB, so you do not have to think about it being structured or easy to remember.

The data that is passed in and out and via userdefined Data Types, and usually stored in shared DBs, should be well thought out so you have structures that are well organized. I am guessing it is exactly as you would do in RSLogix.

Click to expand...

Thanks that explains nicely, my thinking was correct then, just got my Melon a bit confused.

A quick note, FB is similar to AOI but more flexible most importantly it allows far more data types.

JesperMP said:

The data that is passed in and out and via userdefined Data Types, and usually stored in shared DBs, should be well thought out so you have structures that are well organized. I am guessing it is exactly as you would do in RSLogix.

Click to expand...

One thing to add to what Jesper said:


If you are passing a UDT into an FB, you almost always want to call it as an INOUT. This only passes a pointer to it, instead of actually copying the whole data structure. Saves a ton of both processing time and memory. It also allows for both read and write access. Very convenient if you have a big data structure for, say, part tracking, that you need almost everywhere in your code.

Can I just ask, why is the data from the instance block not to be used from the outside?
I know the rule, but don't know the reason (and can't find one, however hard I try).

In most of my (small) projects that nobody is gonna look at, I don't bother and just use the instances. I never had any problems. (and in the bigger ones, I follow the rules just for the rules alone, never found a situation it would create a problem)

m_turk said:

Can I just ask, why is the data from the instance block not to be used from the outside?
I know the rule, but don't know the reason (and can't find one, however hard I try).

In most of my (small) projects that nobody is gonna look at, I don't bother and just use the instances. I never had any problems. (and in the bigger ones, I follow the rules just for the rules alone, never found a situation it would create a problem)

Click to expand...

Because you don't know (or may not know) whether the variable is used inside the FB logic. With TIA Portal, I now somewhat hide the instances into a folder all the way in the bottom of the tree structure to be sure no one goes diggning through it first.

Probably historical and as PLC's generally have small program memory (well compared to PC's), the use of temps or local means the space can be allocated in another block when it is processed.
A good example is in Mitsubishi, To comply with the current IEC etc. Mitsubishi reserve an area of memory (M, D, T, C) in the upper limits of the ranges for example D7,000 - D7,999) (in GX works, GX IEC), these are used as temporary stores for use in blocks (local Variables). Mitsubishi did not have user function blocks the code was one long list of cyclic code.
When a function block is called, the code actually uses some of these to pass the IN/OUT values to the function so for example
Function Test has two input parameters & one output parameter.
***Main Program****
Call to Function Test
Load Value_1 (D100) pass value 1 to temp
Transfer D7000
Load Value_2 (D101) Pass value 2 to temp
Transfer D7001
Jump to P123 (jump to function)
RETURN Here...
Load D7000
Transfer D102 Result is returned
Rest of Program
......
FEnd

Forgot one thing, there are only a few accumulators in most PLC processors so if a block needs more space for storing data for use further along the function then this is another reason for using temps.

P123: (Function Code)
Load D7000 (value past from D100)
Load D7001 (Value Past From D101)
ADD
T D7000 (Store result in D7000 for return)
RETURN
END
It means you can call this function as one instance and use it many times
Reduces size of total program, Temporary memories are re-used throughout the program many times so reduces memory requirements.
Traditionally Siemens S5 had 255 bytes of flags (M) flags 200.0 to 255.7 were used by Siemens as scratch areas (as well as FW0 Used for indirect addressing). So anybody who was fluent in S5 would know using these areas if Standard Siemens blocks were used only use them as temp flags or words or your program would do un-predictable things.
I'm sure there are other reasons

m_turk said:

Can I just ask, why is the data from the instance block not to be used from the outside?
I know the rule, but don't know the reason (and can't find one, however hard I try).

In most of my (small) projects that nobody is gonna look at, I don't bother and just use the instances. I never had any problems. (and in the bigger ones, I follow the rules just for the rules alone, never found a situation it would create a problem)

Click to expand...

There are exceptions to everything and even Siemens have examples of reading and writing data to instance DB. With that in mind this is my thinking.



Data integrity:
I design a block to perform specific tasks and process data that I need outside the block. To that end I use parameters that insure the data is up-to-date. If I read it from the instance DB it is impossible to tell at which point I'm reading the data, before, after or during a process.


Structured programming:
I do everything I can to make it very easy to understand what the block does and how to use it months or years after I wrote it. Along with commenting the block and networks I follow "industry standards" that include naming conventions and block access.


Encapsulation:
Data integrity and structured programming are essential elements to achieve encapsulation. Everything that I can make reusable saves me loads of time in future projects. I drag an OB and a couple of FBs into a brand new project and I have completed motor control portion of the project in "two[ten] minutes or less" (as Siemens preach). I pass it parameters and take out parameters to plug into other plugs or code.

m_turk said:

Can I just ask, why is the data from the instance block not to be used from the outside?
I know the rule, but don't know the reason (and can't find one, however hard I try).

In most of my (small) projects that nobody is gonna look at, I don't bother and just use the instances. I never had any problems. (and in the bigger ones, I follow the rules just for the rules alone, never found a situation it would create a problem)

Click to expand...

I've seen cases where is was well documented, on purpose, and made sense. One company's standard always had an HMI structure on the STAT of an FB, which was where an HMI faceplate that paired with the FB pointed to. The HMI faceplate and PLC code were always updated together, by the same engineer, and everyone knew how to use it.


Generally, though, it turns things into a mess. It makes it tricky to cross reference, and makes it hard to follow. It requires extra documentation, and knowledgeable coders. God help you if you're writing into an FB's instance and don't know it. Reading is more likely to be ok, but it still isn't a best practice.

I didn't mean using the local variables, of course.. (In most systems you can't even acces them), but I guess I understand when you say historically...

cardosocea said:

Because you don't know (or may not know) whether the variable is used inside the FB logic.

Click to expand...

Yes, that is the one thing I agree, but with checking and writing the FB so you never write junk on useful tags and only on local ones.. I know right now you can, but to me, it is common logic you don't want to do that anyway..

kalabdel said:

Data integrity:

Structured programming:

Encapsulation:

Click to expand...

Data integrity is what I agree with, like I said to cardosocea..

Structured programming: Well.. Yes, I agree, but it is so only because it is a convention, I was more on the line - Why is it a convention.

Encapsulation:It is even quicker without it. Juct call the FB, name it and you're done. No linking to Global DBs.

mk42 said:

I've seen cases where is was well documented, on purpose, and made sense. One company's standard always had an HMI structure on the STAT of an FB, which was where an HMI faceplate that paired with the FB pointed to. The HMI faceplate and PLC code were always updated together, by the same engineer, and everyone knew how to use it.


Generally, though, it turns things into a mess. It makes it tricky to cross reference, and makes it hard to follow. It requires extra documentation, and knowledgeable coders. God help you if you're writing into an FB's instance and don't know it. Reading is more likely to be ok, but it still isn't a best practice.

Click to expand...

Well, that is kind of what we're doing. FB, Scada and Hmi templates for elements that you then just link to DB name or number..
But we usually use IN or OUT parameters, just unlinked on the call. That is how you we are indicating they are "safe for you to use".

In/Out parameter for use in global area has to be documented too, so i don't really think it is more documentation..

What do you mean with the cross reference, why would it be harder?

I agree with not doing on a random FB, of course.

m_turk said:

Can I just ask, why is the data from the instance block not to be used from the outside?
I know the rule, but don't know the reason (and can't find one, however hard I try).

In most of my (small) projects that nobody is gonna look at, I don't bother and just use the instances. I never had any problems. (and in the bigger ones, I follow the rules just for the rules alone, never found a situation it would create a problem)

Click to expand...

For Simatic manager, If have your blocks folder set to 'symbolic has priority', you can access any symbolic name including instance data knowing that if you change the FB interface, all references to the symbol name will be corrected when the blocks are compiled. If you have set 'absolute value has priority', then you will access the same absolute address which will be another symbol or part of another symbolic address.


For TIA, all accesses are symbolic (unless you start using peek/poke etc.) so you can access instance data as if it was global data.

m_turk said:

What do you mean with the cross reference, why would it be harder?

Click to expand...

I've come across some systems where I've been pounding my head against the wall trying to figure out why a STAT tag in an FB has the value that it does. Maybe it seems to be getting overwritten by something, maybe it is never set in the FB at all. It turns out that the tag is being written directly to the instance DB, elsewhere in the code.


If you cross reference the tag in the FB, historically, you don't see the external access. If you cross reference the instance DB, you historically don't see the internal access. Recent versions of Portal have addresses this slightly, but there are still lots of gotcha scenarios.

mk42 said:

If you cross reference the tag in the FB, historically, you don't see the external access. If you cross reference the instance DB, you historically don't see the internal access. Recent versions of Portal have addresses this slightly, but there are still lots of gotcha scenarios.

Click to expand...

In Step7, as far as I remember, the function to "cross reference" a variable inside an FB is not really cross referencing, but instead showing you on sequence where the variable is used (Ctrl+****+F and G ??).

I believe that if you cross referenced the address outside (InstanceDB.DBXXX) you'd be able to see the uses of that variable, but not the STAT inside the FB as they are not the same thing. One is a pointer if you will that can point to any instance DB, the other is the actual instance DB.

Although, I found that this was possible in the exact same way... banging my head not understanding what was going on only to, by chance, notice that there were references to the Instance DB and digging up on it.