Temp String creat from array of characters

Does anyone know if there is an issue with the way I am doing this. This works fine if I don't use the temp and go with a DB instead.

I have a temp Sserial =String[7] (address of 40)
and moveing an array of characters into it
then setting the hearder to 707hex

CALL "BLKMOV"
SRCBLK :=#pDestination
RET_VAL:=#iSFC20Return
DSTBLK :=#sSerial[2]
L W#16#707
T LW 40

So questions are:
As far as DSTBLK when I specifie [2] I would think it would put the character found into LB 42 and so on thu LB 47

And then I would load the header of W#16#707 max of 7 actual of 7.

Like I said when I change the DSTBLK a DB area it works fine, so I was wondering if it's an issue with the Local area, and is there anyway of monitoring a string in the local or do you just have to know it's what in there. If so it seems like this could be a very hard item to trouble shot.

Thanks,
-Joel

what is pDestination set to ?

pDesination:
Word 0 = 1002 hex
word 2 = 7 hex
word 4 = 12 hex
dword 6 = 8400fd0

My data in the DB is of type BYTE.

So
B0 = 10 - S7
B1 = 02 - BYTE
W2 = 7 - Repitition (7 characters in the string)
W4 = 12 - DB 18
DW6 = 8400fd0 - db 506.0

Is the Serial[2] and T LW 40 correct for what i'm trying to do?

Not read all the post, but one thing that is common in this type of transfer is when you use block move SFC20 with temps in the source or destination, you must set the pointer to 'V' type (previous temp).


EDIT: the reason being that once you are in SFC20, any reference to temp area will access the SFC20 temp area, pointing to the previous temp area ('V') will point to the temp area of the calling block.

Interesting...

Don't really think i'm ready to dive into that at the moment. Having a ruff time as is. So for now I'll go back to using a DB.

Not really a problem, when you set up the ANY pointer to look at the Temp area, then byte 6 will equal b#16#86 (Local Area), before the call, change this byte to b#16#87 (Previous Local Area).

Here's an example:

How does this work is the "V" memory area the same size as the "L" memroy area and any time you leave a block or call another FC or SFC ect it just moves the "L" to the "V" and leaves the "L" open for the new FC or SFC etc...

Am I under standing that correctly.

I couldn't find anything in the S7 help file for this.

I know it has to be in there.

I just picked up "Hans Berger - Automating with Step 7 in LAD and FBD" also "STL and SCL" is on its way.

I have heard alot of positive things about these books so hopefully they will clear alot of stuff up for me.

The 'L' area is just a scratch area, unsure how S7 internally addresses, I presume they have an internal offset somewhere pointing to the start of the 'L' words allocated to a specific FC on that specific call to the FC, plus a length dictated by the amount of TEMP's you have created.

I'm again presuming, that if you call another FC from that FC, it will have its 'L' area allocated in much the same way, but it would not cross-over boundaries, i.e. use the same scratch areas.

When you create the first TEMP, to the left you will see a number, for the first TEMP you assign, it would show 0.0, this is the 'L' area start address from within the FC, therefore if the TEMP you entered was a BYTE, you could access that by the name you just assigned or by using simply LB0, same for a BOOL (L0.0).

Every TEMP you enter afterwards would be offset to the next address (BYTE would be 1.0, BOOL would be 0.1, etc).

(NOTE: I would not advise using direct 'L' addressing, because if anyone later adds a TEMP before the one you've directly addressed it will cause the program to behave oddly).

0.0 for the first TEMP, would be the offset S7 uses to its internal pointer to where the TEMP's for that FC call begins.



When you call another block (in this case SFC20), it will have its own TEMP area ('L' addresses), therefore if you enter the SFC with pointers to 'L' addresses, the program would automatically start moving data from SFC20's TEMP area.

As a method to enable blocks like SFC20 to move data in and out of the TEMP area of the calling block, they included the 'V' area, which in reality is just the same 'L' area, but it tells SFC20, not to use the area allocated to itself, but the area allocated to the previous block (the calling block).

I presume there is some sort of STACK, where S7 can get the offset for the provious block.

To supplement Peter's answer, here are some screen shots showing what goes on in the background.

Here's a call a FC1 shown as normal. The IN0 parameter to FC1 is of type ANY. The blocks were downloaded and run in the simulator.



If you delete FC1 and FC2 from the offline folder and then copy FC2 (only) from the online folder to the offline folder and open FC2, you can see how the code in the background is generating the ANY pointer prior to calling FC1. Notice that the code still shows the L area for the parameters.




If you now show the corresponding MC7 code, you can see that what is displayed as the L area is actually coded as the V area (87). The editor "knows" that it is generating an ANY pointer to it's L area and hence creates the code to refer to the V area. If you generate an ANY pointer to the L area yourself, you have to do the same and convert it to the V area.



Here's the project for reference:

Okay,

So here is my basic run down. Putting this out there after studying it and reading thru it many times to make sure I have a grasp on it. Here is a very basic program structure and L data stack.

In my example I am constructing my any pointer in FC19(light blue) and using it with the SFC20(RED). Since SFC20(RED) is funtion it's self opens up it's own area in the 'L' data stack. So if the pointer built specifies 'L' memory it would attempt to write it to it's own area. Thus by using the 'V' memory would drop it down to FC19(light blue) 'L' memory area.

Is this the basic idea or am I way off base?

Thanks,
Joel

Added:
Looking thru it another question comes to mind.
CALL "BLKMOV"
SRCBLK :=#pDestination
RET_VAL:=#iSFC20Return
DSTBLK :=#sSerial[2]

My destination is fine. My sSerial[2] is my string I want my characters to be copied to. When I send sSerial[2] into BLKMOV is it smart enough to know it is 'V' memory or do I need to build a specific pointer before my BLKMOV call.

Working on a test program for it right now to try and figure it out.

looks good to me


Your quite right too, OB1 does indeed have its own 'L' memory, where useful information like scan time is held.

:nodi:

The editor "knows" that it is generating an ANY pointer to it's L area and hence creates the code to refer to the V area. If you generate an ANY pointer to the L area yourself, you have to do the same and convert it to the V area.

Click to expand...

By specifying


you are setting your destination to be one single character. You have to generate the any pointer yourself to point to the correct part of the string and generate a V area pointer as sSerial located in the L area of the calling block. (as demonstrated in the project in post#7)

When you want to "see" the any pointer that has been generated as a passed parameter, (you can't monitor inside SFC20), the following FC allows you to examine the any pointer components:

Sweet thanks,

Finally got it all worked out. Only other little change I had to make was with the L DW#16#1000000 that changes it to the V memroy. Had to change it to L DW#16#1000010 since the characters I am copying are an array of characters and not a string had to offset it 2 bytes. I think I got a pretty good handle on it now. Thanks for your time. Hopefully I'll leave you guys alone for a little while now