8/29/2011 11:27 PM | |
Posts: 36 Rating: (0) |
Hello everybody Why we must use TEMPORARY variables in FC or FB as data block pointer? |
8/30/2011 8:15 AM | |
Posts: 2348 Rating: (263)
|
You mean in case OPN DB[#DB_num] why #DB-num is accepted as TEMP, but not as INPUT or i miss something? |
8/31/2011 2:12 AM | |
Posts: 36 Rating: (0) |
Hello Darius Thanks for your attention I can not use any other kind of varible types like STATICas data block pointer. |
9/5/2011 3:00 PM | |
Posts: 36 Rating: (0) |
Hello Darius If we want to use pointer for data blocks in an FB ,we must use TEMP.variable too.We are not able to useSTATIC variable either,why? |
9/6/2011 2:01 PM | |
Joined: 10/7/2005 Last visit: 4/24/2024 Posts: 3004 Rating: (1046)
|
Hello alifaez let me start by stating that you can use an FB's STAT variable as a DB pointer. This is however only possible if you remove the Multi Instance capability from the FB when you create it. By default, Multi Instance capability is ticked when you create an FB, in which case Step 7 will NOT allow you to use a STAT variable as a DB pointer. Even though I suppose the Step 7 Editor could be changed to able to handle/allow this, it won't be an easy fix for Siemens as AR2 is taken into accountfor all accesses to FB variables with Multi Instance capability(AR2 contains the Multi Instance offset). What you can do though in a Multi Instance capable FB is use for example "DIW xyz" directly as the DB pointers address. Note that this though means that the FB will NOT work if called as a Multi Instance. I hope this helps and attached is a pic with an example for both cases which shallhelp in making sense out of what I'm trying to say. |
Cheers |
|
9/7/2011 8:37 AM | |
Posts: 2348 Rating: (263)
|
Really nice:^) I didn't know this feature on turning multi-instance off Is there any other advantages you get on turning it off? |
9/7/2011 2:13 PM | |
Joined: 10/7/2005 Last visit: 4/24/2024 Posts: 3004 Rating: (1046)
|
To tell you the truth Aret, I never really thought about this before. One advantage I can see is though that you should be able to freely use AR2 since it isnot used in a FB without Multi Instance capability(just like an FC never uses AR2) Secondly, since the AR2 usage ina FB with Multi Instance capabilityis needed forall accesses toits Block parametersand STAT's (viaso called "register-indirect area internal addressing"), anFB without Multi Instance capabilitywill (should)execute a tad bit faster (haven't tested this though). Also,if you need to do indirect addressing to access STAT variables, you will NOT have to take the offset in AR2 into account when creating the pointer ina FB without Multi Instance capability. Another rather "useless" advantage is that you can alsoforego symbolic addressing of STAT variables and shoot directly for the DI address(e.g L DIW 2, T DIB 14, "useless advantage"becauseIdo NOT want to encourage this kind of addressing). Having said all the above and listed all possible advantages that I at least can think of.this, I have NOT had the need yet to take advantage of them myself (perhaps one day I will). Idogenerally prefer to create a Multi Instance capable FB which has the rather obvious advantage that it can be called asa Multi Instance. Juts for completeness, the link below has some more info on the subject of FB's and AR2: In which operations does STEP 7 overwrite ACCU or register contents? |
Last edited by: fritz at: 9/7/2011 2:17 PMtypos Cheers |
|
Follow us on