Step7 - Problems with FC5 - DI-STRNG

[L D[AR2P#0.0]]

Peter - In your example FC8, if you L LB4 this will give you the max length of the string.

 

[L D[AR2P#0.0]]

From the Siemens help on string data types:

Note:

If the contents of a string are changed by the user program, the byte "actual length" must also be written or updated so that the string can be displayed by the programming device.
If a temporary variable of the data type STRING was defined, the byte "max. length" must be written with the defined length before using the variable in the user program.

 

[PeterW]

Peter - In your example FC8, if you L LB4 this will give you the max length of the string.

So your saying that even though the next TEMP is at the expected position, the actual string length has not been set in the variable and therefore could overwrite any variables after it if you have an length error in the following code.

Don't have the facility to test run at the moment so will have to remember that.

 

[RolfB]

Roy,
I've test it with PLCSIM and
as Peter say in post #9,
it works directly without problems.

regards
Rolf

 

[RMA]

Current state of affairs

After a lot of playing around yesterday, using "cut-and-paste" to be sure I had the correct names, I managed to persuade FC5 to accept my DB String as its RET_VAL parameter. In order to be sure that I wasn't having any curious effects from using a TEMP for the DINT, I parked it instead in a Marker DINT. I then added a check that the BIE Bit was not being set to "0" - the only error message that FC5 delivers - it wasn't. I then preloaded the DB String with a, b, c,.... etc. to check whether anything was being written at all and this morning it's still there.

So the current state of affairs is that FC5 is being fed with a value of L#41 (for example) according to the VAT display of MD1004, there is no error from FC5 - BIE Bit is = "1" and the RET_VAL String is not being overwritten.

And I haven't a clue as to what's going on!!!

Cheers

Roy

 

[L D[AR2P#0.0]]

Sorry to be a pain, but whats the BIE bit ? Also, how are you monitoring the output string ? The actual value of a string cannot be displayed when monitoring a DB (I always use an array of characters if I want to view the string from the DB).

 

[RMA]

Sorry Simon, I don't know what the BIE Bit is called in English - it's Bit 8 in the Status word (see Rolf's Post 19 - "UN BIE" is exactly what I'm also doing) .

I'm viewing the individual Bytes of the DB String in a VAT and they aren't being overwritten.

 

[L D[AR2P#0.0]]

OK, its the BR (block result) bit.

 

[L D[AR2P#0.0]]

Looks like we've reached the stage where you need to post the code so we can run what you are running......

 

[RMA]

You beat me to it - according to the FC5 help file this Bit gets cleared if the target String is too short for the result of the conversion. There are no other fault indicators - unfortunately!

 

[PeterW]

have tried converting a constant like rolf to see if it can basically work and record the DINT that you are trying to convert, maybe it is too long

 

[RMA]

Looks like we've reached the stage where you need to post the code so we can run what you are running......

Here it is, even remembered to switch to English mnemonics!

Search for "WTne" as label to the relevant code.

have tried converting a constant like rolf to see if it can basically work and record the DINT that you are trying to convert, maybe it is too long

I'll give that a try and see what happens (according to the VAT the value was L#41, though, which shouldn't have been too long. Even if it was, the BR Bit should have been cleared, and it wasn't).

Cheers

Roy

 

[RMA]

Forgot to add the DB.

Here it is.

 

[RMA]

Further Info

I added a new Variable in DB1 - a one-Bit String (not particularly useful, I agree), this ought to provoke an error given the input value of 54 as shown in the screendump (yes, I have switched the display to decimal instead of Hex).

The check of the BR-Bit immediately after the FC5 call shows the BR-Bit still = "1". To be on the safe side I also set a memory Bit if the RLO is true and this Bit also did not get set. It almost looks as if the FC is not being called, but as in the screen dump, the input value is clearly visible.

 

[PeterW]

Silly question, have you loaded FC5 into the PLC and is the software fault OB loaded?