Siemens IEC string functions

Has anyone used the Siemens IEC string functions? I am having some difficulty in getting results from them. I currently have two Strings in a DB defined as STRING[12]. The data I currently have in String1 is 'junk' and the data in String2 is ''. When I try to replace the second string in the DB with the first using IEC FC REPLACE using String2 as IN1 and String1 as IN2, 12 as L and 1 or 0 as P the ENO state goes TRUE like it functioned correctly, but nothing actually gets replaced. Any Ideas.

How are you verifying that nothing appears to have changed ? You cannot monitor a string located in a DB so one way to "see" what is happening is to monitor the DB locations as "Chars" using a VAT table.

I don't know if it's an influence in this case, but it seems one of the rites of passage for anyone getting to grips with IEC string datatypes is to recognise the purpose and contents of the first two bytes. These are always in addition to the declared string length, so a STRING[12] will actually be 14 bytes long.

Byte 1 always contains a numeric value denoting the length of the string variable at the time it was created (whether manually or from within a source file).

Byte 2 contains the current number of valid characters in the string.

So the actual string data only begins at byte 3. Of course, depending on what you have done with the string previously, you may have to write values to bytes 1 and 2 to ensure subsequent operations know what they are dealing with. For example if your second string is '' (does this mean all nul characters or all spaces or ...?) then check that you still have the correct values in bytes 1 and 2.

Let us know what the contents are, byte-by-byte, before and after.

Ken

Simon, I am actually monitoring the variable using a WinCC input/output box. I do also look at the value in the DB online with editing capability (is this not showing me the current values?). Ken, I am inputing the strings in symbolic format like the function REPLACE requires, I am not referencing particular bytes.

Marek

If something else has inadvertantly altered these first two byte values in the PLC (say to '0') then WinCC will possibly believe that this is a zero length string with no valid characters, regardless of what the rest of the byte positions hold. We need to eliminate this as a possibility.

Also, I believe Simon is correct about using the Variable Table to check these addresses as individual characters. There is no other way to monitor such a variable. I think there is something in STEP7 which insists on this for any data type greater than 4 bytes. You can monitor a REAL for example in the datablock, but you can monitor a DATE_AND_TIME there. You should use the Variable Table.

Regards

Ken

WinCC sees the string fine and I can see the changes when I make them via the in/out box both on WinCC and in the PLC DB.

You'd better post the code segment that you are having problems with for further analysis.

I found the reason that the code wasn't working. When you create a String in a DB the first byte of the string is written with the maximum length of the string. The second byte is written with the length of the initialization String. My initialization string is Null '' therefore the second byte had a 0 in it. For some reason the second byte does not get updated after that, so when I use an in/out box from WinCC the String characters will get updated, but not the second byte. So when I run the IEC string functions they look at the second byte and see a 0 so they execute correctly by moving 0 characters. I think the way to resolve this is to initialize using ' ' instead of Null that way the second byte will be 12 and I will always see characters. I will test and let you know. (I have already tested using the IEC functions, just not WinCC)

Oops, I think I owe you an apology! I looked at this Thread and then decided not to post, because I was just thinking of the S7 aspects. I had a similar problem which it might still interest you to follow up here but because the problem turned out to be a firmware bug in the 317 CPU, it never occurred to me that something similar might apply to WinCC. I reckon it might have saved you a few hours if I'd posted after all, sorry!

"If I use any S7 functions which create or write to a STRING (integer conversion, real conversion) then S7 will update the second byte correctly according to the results of the procedure. On the other hand if I simply move values in or out of the declared string variable using load-and-transfer or moves etc these instructions know nothing about the significance of what they've just done. How would they know to update a byte at an arbitrary position in a DB several addresses ahead of where they've been working?"

The previous quote from RMA's link sums up some of my initial confusion. I still need to check and see if WinCC updates byte 1 when it sends a string, but my guess is that it does not. So the answer in my case is to just initialize the String with the same number in byte 0 and 1.

WinCC does update Byte 1.