Problem with S7 STRING to REAL conversion

[Ken M]

Damn it, RMA, you've got me hooked!

I've just set up an OB1 with one call to FC39. I've stuck the same data in to my string :- <14><14>+5.1120000e-03, and I can't stop it working OK. I get 0.005112 out as my real.

I've tried to break it by putting in things like 'E' instead of 'e', but it just keeps working. Provided I keep things in the right order it works with all the numbers I've tried so far. (But I've got quite a few I haven't tried yet. I'll report back in a few millennia and let you know how the tests are going.)

Ken

 

[RMA]

I think you may have the answer there, I've been having my suspicions that the problem may be something really weird, some bug perhaps.

I'm using an S7 317-2 DP bought last August i.e. just after they were released, and I believe there has been a Firmware upgrade since then, the other possibility is that the programm is pretty complex (the Archive is about 2.5 MB, although a big chunk of that is the HMI) so there may be some weird interaction somewhere.

I think I'll do a new project which does nothing else and if it still doesn't work go and try it on a 314 we have lying around.

I'll come Back with the results.

Cheers

Roy

 

[RMA]

Oh boy, this getting really good.

I created a new project and set up the following in OB1:

NOP 0

CALL "R_STRNG"
IN :=1.234567e+000
RET_VAL:="REAL to STRING Test".DB_VAR

SPBIN exit //check for error

CALL "STRNG_R"
S :="REAL to STRING Test".DB_VAR
RET_VAL:="REAL to STRING Test".DB_REAL


exit: NOP 0

the first "NOP 0" is only there so that when you observe in run time you can see the input to FC30.

Then I created the following DB

DB_VAR STRING[14] '' vorläufige Platzhaltervariable
DB_REAL REAL 0.000000e+000

Result on running, didn't work, looking in VAT showed all Bytes in DB_VAR to be "0" including, curiously enough the first one - I thought that got set when you created DB, never mind that's not relavent. This time the error trap also worked when I added it.

OK next redo DB_VAR without defining a string length .e. let it default to 254.

Result - program now works as expected.

Redefine string length to 16 Bytes - still works.

Now comes the good bit, reduce the string length to 14 Bytes - aaaargh! Still works - double check DB, VAT etc. Yup, it's now working at 14 Bytes!

Next question - is this a 317 funny or is it a general problem.

What size of STRING did you define in your DB Ken, or did you let it default to 254?

 

[JesperMP]

A STRING[14] contains 16 bytes, not 14. Try to define a new DB with a string of 14 characters, you will see that it takes up 16 bytes.
So everything adds up correctly.

edit: Try to make it a STRING[12]. That will be 14 bytes long, but should fail when used with FC39 as the input value.

But cant understand why it didnt work the first time where you had it set to 14 chars.

 

[Ken M]

Hang on, I haven't finished testing all these other numbers yet ... There seems to be thousands of them. And I haven't even started on the imaginary ones.

I created my DB with a variable named Test of type STRING[14]. And yes, in order to accommodate 14 characters in this string, the data occupies 16 bytes (2 header bytes + 14 characters).

Curiouser and curiouser ...

Ken.

 

[JesperMP]

...looking in VAT showed all Bytes in DB_VAR to be "0" including, curiously enough the first one - I thought that got set when you created DB, never mind that's not relavent.

Maybe it IS relevant.
Can you redo the actions that you did to make a STRING[14] variable that does NOT work ?
Can you make a working STRING[14] to NOT work by clearing the two header bytes (via a VAT) ?

If this points to the error, then it would be a bug in STEP7 and not in the S7-317.

 

[JesperMP]

Maybe its a timestamp conflict.
When you change the declaration of the STRING variable in the DB, then you should also check the calling code. It might require you to update the DB access. When done with that you must download both the DB and the block that calls FC39.

If for example you created a DB first, and then later added the STRING variable without performing all the steps, then that could account for the header bytes being still set to zero.

Timestamp conflicts catches me every now and then.

 

[RMA]

Okay guys, we're finished now, I think.

Why it worked after declaring a length of 16 and then going down to 14 afterwards is a mystery between God and Siemens. If you Stop and Start the program afresh with the length declared at 14 once again it doesn't work.

So it looks like the real answer is declare at 16 bytes and don't worry about why!

I've been back into the main program and modified it accordingly and it's working fine there too now.

Just leaves the question: is this a 317 bug or do you always have to declare a length of 16?

Oops I've just noticed you guys have been back in between times.

Jesper - yes I know that the 14 byte string occupies 16 bytes - if you look at the VAT you'll notice the two Bytes before the start of the STRING[1] byte - those are the length bytes and that's where it starts in the DB declaration.

In the test program it's absolutely repeatable - if I start everything from scratch, so that the DB is clean first time round, and declare the STRING[14] i.e. total length is 16 bytes, then it doesn't work. Declaring STRING[16] i.e. 18 Bytes in all, of which two are not used, then everything works perfectly.

Another curious think I noticed, if you try and enter something like +0.123456E+002 in the input side of FC30, the S7 editor changes it automatically to +1.234560E+001 - this occurs for all values of the first significant digit between 1 and 9. If you now go and look at the output String in a VAT you find that if the the first digit is 3 or more then your +3.123456E+000 gets stored as +0.312345E+001 - explain that one! I'm not sure where the breakpoint is or why, I thought it might be at E and tried it with 2.8, but that stayed happily as 2.8, all most peculiar.

Fortunately in FC39 it swallow my 5.112 with no problems.

Anyway, as I said everything is now working (after two and half days, thank God!)

I notice you say that you ceated your string with a STRING[14] declaration Ken - what CPU were you using? It's looking increasingly like a 317 bug. I guess it's my own fault - every kid knows you never buy Version 1.0 of anything and I learnt that lesson on DEC PDP 11s (and even more with VAX VMS) over 30 years ago.

Thanks a lot for the help, it's a great forum you've got here, and I'll be keeping an eye on it in future!

I don't suppose I'll be contributing that much, I've only been working with PLCs for a couple of years. I come from the dinosaur world of ABB, Foxborough, Kent (where I started in 1969!) and co., I guess I'm a bit of a dinosaur myself. I'm interrupt driven and this blasted cyclical thing in PLCs drives me bats sometimes. Unfortunately you can't really avoid S7 in Germany nowadays.

Cheers and thanks once again for the help,

Roy

 

[S7Guy]

I looked inside FC39, and the only thing that can make it fail (other than invalid characters in the string) is if the string length does not equal 14. It doesn’t even look at byte 0 of the input string, so it wouldn’t matter if the string format was [254], [100], or [14], as long as the actual data is exactly 14 bytes long.

Once it gets by this check, it looks for the proper format (like if the ‘+’ sign is where it’s supposed to be), but that’s it. The code is pretty straight forward, and there are no system functions being used that could be firmware related. I’m guessing that the problems you were having earlier had something to do with the way the data was coming in. In the Siemens world, if I define a string and enter data directly in the initial value field, then I can see the length of the data in byte 1, and the maximum defined length of the string in byte 0. But if some other process is sending the string to me, and I give it the string address starting at byte 0, then the first two bytes become data and do not represent the string length (this is exactly why I prefer to use character arrays instead of strings in S7). Perhaps the FTP process is sending the data with a 0 byte offset, whereas hand-entered data has the 2 byte offset, which would explain why it seems to be inconsistent during testing. Just a thought.

 

[RMA]

S7Guy, I take your point about the problem of passing incoming strings straight on, but in this case I'm catching the FTP string when it comes in and stripping out the bits I need and then building the new string for the conversion to real, so I can be sure that the string length etc. is correct because I'm calculating and storing them myself. On the other hand I appreciate your point about working with arrays, I think I'll have a closer look at that, it's something I hadn't considered - Mmm, if I'm not mistaken, wouldn't help in this case, because FC30 and FC39 both MUST use STRINGs, but for general data transfer, you're right.

No the problem really does seem to be with the 317 firmware. I've now tested the simple program I mentioned above on a 314 as well, result:

Program:

Feed REAL constant into FC30 REAL to STRING
Store result in STRING in DB

Take STRING from DB and feed into FC39 STRING to REAL
store result in REAL in same DB (immediately after STRING)

In DB declare STRING as STRING[14] result - 314 works, 317 does not.
Declare with STRING[16] and now both work quite happily! Seems to me to be pretty much an open and shut case.

What really p*sses me off though, is that as a result it's taken me 3 days to do something I was expecting to get done in a couple of hours - and I don't suppose Siemens are going to offer to pay me for the wasted time!

 

[Ken M]

Roy,

When I tested the conversion I didn't use a CPU (!!) I used PLC-Sim. I could understand the idea of the success being CPU-specific if the conversion was an SFC built in to the operating system of the CPU, but in this case it's a loadable FC and it's operation should (should!) be the same regardless of CPU.

I think PLC-Sim pretends to be a S7-400 series so it can accommodate all the uniquely 400-series features like 4 accumulators etc, but from S7-Guy's input the code in the FC is straightforward.

Hmmm... right know, I just don't know.

Ken.

 

[RMA]

In the meantime, I've been checking out the Siemens Support site and there is now an update for the 317 to V2.3 Firmware, mine's on V2.1. I haven't found anything about V2.2 - maybe that was never offered as a public update.

There's no mention about sorting any bugs, but there again there wouldn't be would there! Unfortunately, the online update only works with Step7 V5.3, and I'm still running V5.2. However, I need to update to V5.3 soon anyway because I have to upgrade ProTool to the new WinCC version and that also only works with V5.3.

I hope I'll get this done in the next week or two and I'll report back.

Cheers

Roy

 

[JesperMP]

Originally posted by RMA:
In the test program it's absolutely repeatable - if I start everything from scratch, so that the DB is clean first time round, and declare the STRING[14] i.e. total length is 16 bytes, then it doesn't work. Declaring STRING[16] i.e. 18 Bytes in all, of which two are not used, then everything works perfectly.

When you first declare the STRING[14] it does not work. Subsequently changing it to [16], [254] and then back to [14] it will work.

Originally posted by S7Guy:
I looked inside FC39, and the only thing that can make it fail (other than invalid characters in the string) is if the string length does not equal 14. It doesn’t even look at byte 0 of the input string, so it wouldn’t matter if the string format was [254], [100], or [14], as long as the actual data is exactly 14 bytes long.

I guess that S7Guy means that the second header byte must contain a "14".

I think I know what goes on. When you first declare the STRING[14], the first header byte gets set to "14" but the second remains "0".
After some manipulation the second header byte gets set to "14", after that everything works.
What if you input an initial value for the string, such as "+1.234560E+001", I would guess that the second header byte is set to "14".

What is the content of the two header bytes when you define the STRING[14] that fails? (OK, you said I could see it in the screenshot - but do check it again).
What is the content of the two header bytes when you define the STRING[16] that works?

NB: WIN CC Flexible works with STEP7 v 5.2, but not in "integrated" mode.
Sidenote: I would not be so eager to get from Protool to WIN CC Flexible. It is very different from Protool, very heavy, and still in version 1.0.0.

 

[RMA]

Jesper,

you've hit the nail on the head. After I create the DB with STRING[14] and upload it, looking in the VAT all Bytes are zero. Funny, I could swear I had a situation where the first Byte (alone) was set to 14 - however, I can't say for sure if that was after a fresh load - presumably not.

(I've just checked that out, if I modify the structure of the DB, i.e. change the STRING[14] to [16] and vice versa, the length Bytes do not get cleared. This only happens if I reload a project or do an "Urlöschen" - I've only worked with S7 in Germany, I don't know what the English command is called!)

As usual, FC30 bombs out with an error (BIE bit = 0), then, without stopping the system I wrote 14 into Bytes 0 & 1 - hey presto immediately everything works. Still leaves the open question of why this works on the CPU 314!

I then tried writing just Byte 0 and then just Byte 1 - perhaps not unexpectedly, it is the first Byte (0) that matters - Byte 1 is irrelevant.

Now this raises an interesting question, in my real program, I write these two "14"s at the start of the network, before I do anything else. Does this mean that memory transfers are not immediately carried out line for line, as it were? If not, I've probably got some pretty flakey programs floating around out there!

Sidenote: I would not be so eager to get from Protool to WIN CC Flexible. It is very different from Protool, very heavy, and still in version 1.0.0.

I don't really have a lot of choice, the customer is insisting on it. I chose ProTool because it was perfectly adequate for the job (although at one stage we were getting frighteningly near the 2K tags!). A couple of years ago (my doesn't time fly when you're enjoying yourself - middle of 2001, actually!) when I was just starting to work regularly with S7, I was involved with WinCC. I found it very counter-intuitive and what I particularly didn't like was that for many operations you had to mess about in two separate wizards to achieve the desired result. You can get used to anything, but comfortable it was not! Maybe it's improved since then.

Still the project runs to the end of 2005, for me till the end of March, so maybe I won't be in too much of a hurry to implement it after all. Do you know if there's been any feedback on it anywhere?

I'll do a search afterwards.

Hey, some nice soul has just pressed my Step7 V5.3 update into my hands - that should keep me busy for the rest of the day.

 

[Ken M]

I don't believe that S7 or STEP7 controls the contents of the second byte at all - that is entirely up to the user. Let's say you have variable length strings in an application. You don't create one variable for each possible size of string. You create one variable for the maximum size of string and if you have a shorter piece of data, set the second byte accordingly. This tells any subsequent functions how much of the data they should use. So Roy's application should work with any declared string size from 14 upwards provided the second byte contains a value of 14.
All my tests were on the basis of me loading a fixed value of 14 to both bytes - I haven't yet experimented with alternative values in the second byte.

Ken.