Problem with S7 STRING to REAL conversion

RMA

Member
Join Date
Sep 2004
Location
North of Hamburg, Germany
Posts
2,052
For a project I'm currently working on, I get a text file from a customer PC into the S7 by FTP transfer. The file contains a string with date and time and the curent and maximum temperature for 5 magnetic coils. I need to check that the current temperature is less than the maximum allowed before the next experiment can proceed.

Because the String does not have the correct format for the STRING to Date and Time or STRING to REAL conversion, I extract the necessary characters and add in the missing bits (e.g. sign and a final zero) and store them in a DB (with symbolic names). However, despite the fact that the strings are in the format described in the help files neither conversion works.

Anybody got any ideas. I've tried the Siemens Hotline, but so far they haven't come back with anything.
 
When you refer to the string not having the correct format, do you mean it doesn't use the standard IEC STRING datatype? In STEP7 if you try any type conversions, the STRING data must be IEC compliant. The two key things here are that the first two bytes of any STRING datatype must hold the maximum defined length of the string in the first byte, and the currect actual number of valid characters in the second byte. You will find that if your declare a STRING variable as, say, 10 characters long, the actual variable will occupy 12 bytes of memory. In other words the first two 'syntax' bytes followed by your declared length.

In order for a successful type conversion, you will probably have to load the second byte to tell the function how much data it should be dealing with.

Regards

Ken.
 
I get the data as an FTP transfer of a text file. The file is a single line of 14 REAL numbers separated by TABs, of which the first four hold the date and time and the remaining ten hold respectively the maximum temperature allowed before the coil can be used again and the actual temperature for the five coils.

In order to compare the actual with the maximum temp. I want to convert the STRINGS to REALs. Since the REALs I receive are unsigned, have only six decimals after the point and only a single exponent it must first be modified to the S7 format i.e. ±x.yyyyyyyE±zz.

To do this I add the missing bits to the values received by storing them Byte by Byte in a 14 character string defined in a DB. I do this for the date and time as well and when I look at them on a VAT table everything appears to be OK. The conversion however doesn't work for either.

The Siemens hotline suggested trying a REAL to STRING conversion using FC 30 (I use the FC39 for STRING to REAL). I created a separate DB for this and changed DB_VAR to a 14 Bit STRING. When I look at it in a VAT the first Byte contains "14" evidently written there when the file was created. The remaining Bytes remain on zero.

Since I'm pretty sure that both problems are related - and probably so trivial that you don't find them mentioned in any book I'll just list that part of the program for brevity:

nw2: NOP 0

U "M_FALSE" //Nur eingesetzt um Anzeige bei
SPB nw02 //beobachten zu erzwingen

CALL "R_STRNG"
IN :=5.123456e-003
RET_VAL:="Spulentemp DB".Test_String

SPBIN exit

Now that's so simple you wonder what you could possibly do wrong, S7 won't let you put the REAL value in in the wrong format even if you try!

The SPBIN was included to check that the BIE Bit remains set, indicating a successful conversion - it does.

I'll try to paste an image of a screen dump of the VATs but I'm not sure if it will work because I don't know how to do it yet and from another forum I know that you don't see pictures in the preview.

If it does work the upper left VAT shows the date and time as stored ready for conversion to S7 DATE_AND_TIME format. The upper right VAT shows the result (or lack of it) of the above REAL to STRING conversion in DB21 and the lower right VAT shows the part of the DB41 file where the incoming teperature is stored ready for the STRING to REAL conversion.

Thanks in for any suggestions.

s7_vat_1024.jpg
 
I am mystified as to how the FTP data is formatted.

The contents of the "SpulenTemp_DB" is in CHAR format (i.e one BYTE wide each).
How is date and time formatted ?
How is each real formatted ?
A real normally occupies a 32-bit word (4 bytes). I cant make heads or tails out of how the date, time and real values correspond to the positions in the "SpulenTemp_DB".
 
The data comes in over the FTP link as a single line of text 170 charcters long, so it's no problem extracting it from the FTP storage DB and copying it as raw data into the first part of DB41.

I then take the date and time portion of this data, format it to the style required by the FC 91 STRING to DATE_AND_TIME converter (this is not a standard part of the S7 library - you have to pay extra for it!). This is the stored in a 22 character STRING in DB 41 called "Formatted_Text_D_T" starting at DBB170, i.e directly following the end of the raw data.

The extracted characters for the temperature are similarly stored in a 14 character STRING called "IST_1_S7_STRING" as required by FC 39 STRNG_R, starting at DBB218.

In the VAT I'm looking at the data one Byte at a time, but if you look, you'll see the byte numbers in square brackets at the end of the symbolic name, indicating which byte of the STRING each is.

You can only access the output from FC 39 by a symbolic name, and it must be in a DB (or local memory, which is not relevant here).
 
RMA

Looking at your VAT on the bottom right, you have a string at DB41.DBB220 - DB41.DB233. Although all the characters individually appear OK, you have them in the wrong place. Move them all up by two bytes, so that the sign now appears at DB41.DBB222, the leading digit now appears at DB41.DB223, and decimal point at DBB224 etc.
In the first two bytes you need to load the values I referred to in my earlier post. Give DB220 a decimal value of 14 (the total defined length of the string) and give DB221 a decimal value of 9, corresponding to the number of valid characters in the string at present, i.e. '+5.211000'

Try that and see if the conversion works. Will the string representing your real data always have 9 characters? If not you will have to adjust the second byte accordingly.

Ken
 
So in DB41.DBB220 to DBB230 you have the real representation of what looks like "+5.112 e3".
Maybe you lack a sign for the exponent i.e. "+5.112 e+3"

It just strikes me that this is an extremely crude way of transmitting a floating point value.
Cant you get the FTP data to be sent as a regular real i.e. 32 bits in 4 bytes (or chars) ?
 
Arrgghh, I'm too slow typing, and too quick to hit the 'submit' button before reading my own replies!

I've just realised your string starts at DBB218. Forget what I said and let me have a think. Now there's a rare expression!

Ken.
 
There is some confusion being caused here because the VAT ignores the two formatting Bytes at the start of the string. In fact the string as declared in DB41 does actually start at DB218. I'll hang the declaration of DB41 on the end of this.

As I'm pretty convinced that this is probably some absolutely stupid, trivial problem, can anybody suggest why the REAL to STRING conversion in NW 2 doesn't work. I'm pretty sure it will be the same problem.

As far as the STRING length is compared this is defined at 14 characters in the format ±n.mmmmmmmE±yy by the specs of FC 39.

s7_db41_1024.jpg
 
So DB41.dbb231 is a "-" minussign. I took it for a "."
Then the current formatting looks like this: "+5.1120000-e03"

But you say that the format should be ±n.mmmmmmmE±yy
It looks like you must swap the "e" and the exponent sign: "+5.1120000e-03"
 
Oops you're getting too fast for me here guys!

The file is coming out of the instrumentation PC in the lab (It's the FZR research centre at Dresden university where they are building a system to develope the world's strongest medium term (1 - 2 secs) magnetic field - 100 Tesla. This they intend to achieve by charging up some 480 odd capacitors to 24 kV giving 49MJ and dumping it with a bang (probably a very loud one! :D ) into the coils. The coils are cooled by liquid Nitrogen and we then need to wait for them to cool down before the next shot).

We were requested to make the transfer via FTP because that suited them better, I suspect they are extracting the data from an Excel file or something similar. Actually, it suits me fine as well, I'm no C++ programmer and playing with strings is no problem - and when I started on this a couple of days ago it looked like kid's play! :(
 
I thought you'd solved it there but looking at the VAT again the "e" is in DBB230 and the "-" in DBB231, so it's right enough.

I've just checked the FC39 help file (in case I'd misread it) and the exponent form is definitely e±xx.

Still stumped!
 
I'm fairly convinced that I've done the formatting correctly, I've been playing with STRINGs sind Lotus 123 V2 - and that's a long time ago!

I'm still convinced that if somebody can explain why the REAL to STRING conversion in NW 2, which I posted near the start, doesn't work, that will also lead to the solution to the real problem.

After all, it's hard to see what you can do wrong with FC 30, REAL to STRING - but it still doesn't work!
 

Similar Topics

Hello folks, Using AB RSLogix micro.. I have a 6 digit ASCII text string and Im looking to convert the 4 most significant digits to an integer...
Replies
2
Views
1,439
I have a Red Lion G310 that im programming with Crimson 2.0 I have a internal string Tag that needs to be retentive. I have a string text with...
Replies
6
Views
3,827
hello, i am new here and have this problem that have driven me crazy, i have a lot of string edits in one display to control all the string...
Replies
0
Views
1,246
Hi, I have configured a tag of string with length 6. Ie N16:1 to N16:6. When that string is displayed in panel view it is showing in reverse...
Replies
9
Views
2,767
Ran across a problem with the TwinCAT Real_To_String conversion today. I have found that if my real is 0.12345 it converts to '1.2345' It also...
Replies
2
Views
1,692
Back
Top Bottom