Step 7: Access 'M' memory byte address inside FB

STL??? · Dec 19, 2012

Hi - Merry Christmas Plcs.net members!

I would like my function block to use a Memory byte address which i pass in as a start address to which all offsets inside the FB are based.

Basically if i want to call this block more than once - i can enter different start addresses and the block does the rest for me.

i first experimented with passing in a value as follows;

Code:

      L     #iStartAddress  // FB IN - type INT
      SLW   3
      LAR1  
      L     100
      T     MB [AR1,P#0.0]
      L     101
      T     MB [AR1,P#1.0]
      etc...........

This works well but i want people to be able to cross reference the start address to guide them to the FB.

so i tried this - it works but i was wondering if i'm over complicating matters.

Code:

      L     P##StartAddress            // Load Pointer into Accu (Ar1 has L14.0)
      LAR1                              // Load into Ar1            
      // Ar1 contents DI0.0 
      // Retrieve - Byte 6 Memory Area | Byte 7,8,9 Byte/Bit Address      
      L     D [AR1,P#6.0]               
      // Ar1 contents DI0.0        
      LAR1                              // Update Ar1
      // Ar1 contents M100.0
      L     50
      T     MB [AR1,P#0.0]
      L     51
      T     MB [AR1,P#1.0]

Is this ok inside a FB? are there any pitfalls with this approach? can it be done simpler?

Thanks in advance for any help on this matter.

L D[AR2P#0.0] · Dec 19, 2012

STL??? said:
Is this ok inside a FB? are there any pitfalls with this approach?

Indirect addressing inside FB's needs to take into account AR2 if you want to be able to use the FB as a multiple instance FB

How many MBs are you pre-loading inside the FB

STL??? · Dec 19, 2012

L D[AR2 said:
Indirect addressing inside FB's needs to take into account AR2 if you want to be able to use the FB as a multiple instance FB

Thanks for replying LD - this is the part where i'm unsure to be honest.

To provide some background info, this is an existing program which has been converted from S5, each stations data is mapped to the same memory area - i believe this was a common practice back then.

The FB is unconditionally called and references a global DB via the OPN command so I'm thinking of converting the FB to a FC.

i want to create unique memory area's for each station - ultimately so monitoring is simpler.

L D[AR2 said:
How many MBs are you pre-loading inside the FB

14 bytes in total

Thanks

L D[AR2P#0.0] · Dec 19, 2012

Instead of passing a pointer to the start byte, use 14 parameters, one for each of the bytes - they will all come up in the xref then.

STL??? · Dec 19, 2012

L D[AR2 said:
Instead of passing a pointer to the start byte, use 14 parameters, one for each of the bytes - they will all come up in the xref then.

this is what ill do in the interests of simplicity

i did experiment doing the same inside a FC;

Code:

      TAR1  #dwSaveAr1

      L     P##pStartAddress            // Load Pointer into Accu (Ar1 has L14.0)
      LAR1                              // V memory?  

// make sure data type is 'M'        
      L     B [AR1,P#6.0]
      L     B#16#83
      <>I   
      JC    End

      L     D [AR1,P#6.0]               // Retrieve - Byte 6 Memory Area | Byte 7,8,9 Byte/Bit Address
      LAR1  

      L     50
      T     MB [AR1,P#0.0]
      L     51
      T     MB [AR1,P#1.0]
      L     52
      T     MB [AR1,P#2.0]
      L     53
      T     MB [AR1,P#3.0]
      L     54
      T     MB [AR1,P#4.0]
      L     55
      T     MB [AR1,P#5.0]
      L     56
      T     MB [AR1,P#6.0]

End:  LAR1  #dwSaveAr1

If i understand correctly V memory is the local data of the block in which my function is called (in this case OB1)

i have saved Ar1 before processing and restore it after so i shouldn't have any issues there.

what is the relationship between Fc parameters and V memory?

L D[AR2P#0.0] · Dec 20, 2012

All parameters are passed to FC's by 32 bit area pointers. In the case of anypointers for example,(they occupy 10 ten bytes) the parameter is an area pointer which points to the location of the anypointer. The editor generates code which copies the anypointer data into local memory of the calling block, hence your FC will need to access the V area to access the pointer to the anypointer, and the anypointer data as well.

KalleOlsen · Dec 20, 2012

STL???, what about posting the original Step5 FB? Perhaps there are other solutions also?

Kalle

STL??? · Dec 20, 2012

L D[AR2 said:
All parameters are passed to FC's by 32 bit area pointers. In the case of anypointers for example,(they occupy 10 ten bytes) the parameter is an area pointer which points to the location of the anypointer. The editor generates code which copies the anypointer data into local memory of the calling block, hence your FC will need to access the V area to access the pointer to the anypointer, and the anypointer data as well.

A lot goes on behind the scenes then

Seriously LD - your S7 knowledge is impressive.

KalleOlsen said:
STL???, what about posting the original Step5 FB? Perhaps there are other solutions also?

Kalle

Hi Kalle - i have requested the original S5 program - if it turns up ill update this thread.

i Appreciate you both taking the time to help me - thanks again.

Step 7: Access 'M' memory byte address inside FB

STL???

Member

L D[AR2P#0.0]

Lifetime Supporting Member

STL???

Member

L D[AR2P#0.0]

Lifetime Supporting Member

STL???

Member

L D[AR2P#0.0]

Lifetime Supporting Member

KalleOlsen

Member

STL???

Member

Similar Topics