Problem with S7 STRING to REAL conversion

[JesperMP]

I think that this whole thing boils down to, that S7 string handling including FC39 works as intended.

The problem started because the STRING[14] variable did not get an initial value AND because the manual assignment of the string length failed for some reason.

RMA,
you could post the entire code section, including the point where you assign "14" to the second header byte.
Then we could take it from there.

Maybe you have got it solved by doing the same thing in a different way. But it is still a good excercise to figure out why it went wrong the first time.

 

[RMA]

Hi Guys,

sorry I'm a bit late, I decided we needed some hard facts to go on, so I went chasing them.

I may not know much about S7, but I spent nearly 15 years of my life as chief trouble-shooter for a UK automation company, so I do know how to go looking for problems!

My real program is to complex to post here and I suspect trying to cut it down might just result in removing the source of the error, assuming there is one (which is quite likely), as well as the 317 bug, I am now convinced exists.

Instead, I went back to my test program. Before each of the following tests I flushed the memory and loaded a different project, so every time I was starting off from a clean base.

The first program worked quite happily on an S7 314-2 DP and on a Slot_AC 412-2, but as you can see from the screen dump, it didn't on the 317.

Since I assume I can only append one picture at a time I'll add the next two screen dumps as separate posts.

 

[RMA]

As you can see, the REAL to STRING hasn't worked and the BIE bit has been cleared.

So the next thing I did, was to initialise Byte 0 of the DB - exactly as do in my main program, before calling the FC.

As you can see, no difference.

 

[RMA]

So then I split the program into two networks - hey presto - now everything's working.

Having run this once, I can now go back to program 1 and if I just load it down it will now run properly as well. I can play about with the DB as much as I like, but once it's run once I can't break it again. To stop it working I have to flush the memory and go back to an absolutely clean system.

If that doesn't say that the 317 has a bug in its firmware, I don't know what does!

 

[JesperMP]

Roy,

S7Guy has explained that you are not assigning the string length to the correct byte.

You do this:

L  B#16#E

T  DB41.DBB0

Try to change it to this:

L  B#16#E

T  DB41.DBB0

T  DB41.DBB1

Then see how it goes.

 

[RMA]

I've tried all three possible variations.

S7Guy is right, once it's running, the FCs don't care what's in Byte 0
- it can even be "0" and everything works.

The problem is only on the first time through on a completely clean system - and even then it's only a problem on the 317.

That's why I'm convinced that that problem is a bug.

It'll be interesting to see if the problem disappears when I upgrade the firmware to V2.3, but when that will be heaven knows. Getting authorisation to buy the 4MB MMC is going to be a pain in the neck. I could probably get authorisation for a new 317 easier. Come to think of it, that might not be a bad idea!

I've got to travel back home for the weekend soon, so I won't be around much longer. But I'll be back in on Monday to see what's going on.

Cheers

Roy

 

[JesperMP]

Its not the final chapter, but after a little experimentation I have found the following:

1. I can not reproduce the case that you had where the code does not work. I use PLC-SIM to test.
The way that FC30 follows the lines where you set DB1.DBB0 (and maybe DB1.DBB1) means that FC30 overrules the previous lines.
FC30 will set DB1.DBB1 to '14' as is required.
In your code example FC30 makes the conversion correctly and sets DB1.DBB1 correctly. That means that FC39 works irrespective of the two previous lines.
Removing the call to FC30 allows for further experimentation with FC39.

2. The requirements for FC39 to work is that DB1.DBB1 is '14' AND that the format of the string is the previously mentioned '±x.yyyyyyyE±zz'.
'+1.234560E+001' has been mentioned in your previous posts, so I thought that I ought to mention it. It should be '+1.2345600E+01' if you want it to work.
DB1.DBB0 seems to be irrelevant to FC39.

3. When testing, every time you make a change to the code - remember to download a fresh DB1, otherwise you will be working with 'old' values. Maybe that can account for the mysterious not working / working scenarios.

 

[RMA]

+1.234560E+001' has been mentioned in your previous posts, so I thought that I ought to mention it. It should be '+1.2345600E+01' if you want it to work.

Thanks for pointing it out, but in fact this is just a bit of confusion introduced by Siemens, because, for reasons best known to themselves, they require different formats for REALs as constants (as in my test program) and the STRING which you feed to FC39. In my real program I've got the correct format for the STRING.

As I mentioned, following my tests on the three different CPUs, I'm convinced that the 317 has a bug (let's face it, there is no complex software which is entirely bug-free - whether you actually see the consequences of the bug is another question, pure chance really). Anyway, the work-around of declaring the STRINGs to have a maximum length of 16 works, and until I get round to upgrading the firmware to V2.3, I'm not going to lose any more sleep over it!

You said you were testing using PLC-SIM - I've never managed to persuade PLC-SIM to let me look at DBs. Is there a trick to do this, or do you add extra code to copy the contents of the DB to a memory location? I'm using V5.2, is there a newer version which is more flexible?

Cheers

Roy

 

[JesperMP]

If what you write is true, then that is certainly confusing.
Siemens requires a different format for the FC39 "string to real" function than its own REAL format !
Edit: But I think that when I tested FC39 I used a string with '1.2300000E+01' as the input. And it worked !?

To view or change a DB variable in PLC-SIM:
Add a "generic" variable (CTRL+F2).
Example: Then type DB1.DBB2 for the address and select 'char' for the type.
The address must exist beforehand, i.e you have to download DB1 to PLC-SIM first.

 

[RMA]

You learn something new every day!

I've just tried that out with the DBs in PLCSIM and it works fine. I had always organised what I wanted to look at before loading the program - everything else still works, just not DBs. I presume it's because they don't have a fixed format. I prefer using DBs to Merker for most things, because I find it easier to organise things that way and it was a real pain in the neck not being able to observe them in PLCSIM.

Why it is, I don't know, but the fact is if you define a REAL number as a text STRING for input to FC39, then it must have 7 digits after the decimal point and only 2 digits for the exponent. On the other hand, if you want to enter a REAL value as a constant in a program, or as a starting value in a DB then you've got to give it 6 digits after the point and 3 digits for the exponent.

Maybe Siemens knows why, I doubt if anybody else does!

Cheers and thanks once again for the help,

Roy

 

[S7Guy]

I imagine the format for the real number string is related to the IEC standard (of which I am not overly familiar with). Or, it might be something arbitrary, since the way that FC39 was coded relies on a very stringent format. For instance, the first character is evaluated as a plus or minus sign, and if it doesn't meet this condition, it errors out. And, the E must be the 11th character, or it errors out, and so forth. If you look at the code, it could easily be amended to match the Siemens real data type (it uses the ANSI standard instead). If I was doing extensive conversions like this, I would just come up with my own library of conversions that would adapt to any format that "came down the pipe", since there are even more variations out there.

Are you suggesting that this arrangement of bytes in a string is a Siemens-only convention? I thought this was what the IEC61131 standard had mandated for a STRING datatype? I'm not trying to defend Siemens, I'm just wondering if I had got it wrong with that assumption. Do any other PLC manufacturers treat the first two bytes of a string in the same way?

Good question. I'm not sure if it is Siemens-only or not, because I don't use anything else. Perhaps someone from the "dark side" will dare to venture into this thread and tell us how others do it .