Skip to Content

support.automation.siemens.com | Technical Forum | Sunday, September 14, 2025 12:31:20 AM

Print

EQ_String problem

Created by: Zaxis at: 6/27/2008 10:26 AM (10 Replies)

Rating (1)

Thanks 1

Result pages:: |; 1 | 2; |

11 Entries

Entries per page: 10 | all

6/27/2008 10:26 AM	Rate (0)
Zaxis Posts: 7 Rating: (0)	I'm communicating through a CP340, I then split and move string-data to DB-values. Then I want to compare the received value with a known value. Herefor I use the EQ_String function from the IEC-library. The problem is that when I compare two different strings I get '0' as return value, but when I use the same variable on both inputs, then it still stays '0'. What I did then was connecting the ret_val to e.g. M20.0. The function was activated but I could change the value with a VAT, normally the ret_val is a written output so normally the value that I set up in the VAT should be overwritten instantly, but that is not the case. I tried using the NE_String function but the same problem here. Is there a logical explanation for this? Kind regards
Zaxis Posts: 7 Rating: (0)
Suggestion To thank Quote Answer

6/27/2008 11:25 AM	Rate (0)
Aret Posts: 2348 Rating: (265)	Could you post your test code here ?
Aret Posts: 2348 Rating: (265)
Suggestion To thank Quote Answer

6/27/2008 11:44 AM	Rate (0)
Zaxis Posts: 7 Rating: (0)	I hope this makes things clear a little more. And then I use e.g. NE_String to compare two identical strings. Normally this would give 0 (because they are equal), but when I modify the value of M20.2 to 1, it stays 1. The value is not overwritten by the result of the comparison. (also tested it with EQ_string but same there) Attachment NE_String2.JPG (918 Downloads)
Zaxis Posts: 7 Rating: (0)
Suggestion To thank Quote Answer

6/27/2008 3:21 PM	Rate (1)
Aret Posts: 2348 Rating: (265)	Function is really called? Can you see this CALL on monitoring block? Redownload it to PLC from library
Aret Posts: 2348 Rating: (265)
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users zazzoup

6/27/2008 4:40 PM	Rate (0)
Zaxis Posts: 7 Rating: (0)	When I looked in monitoring the whole block is green, so there shouldn't be any error processing it. I clicked on the block in the IEC library and choose "overwrite" so this should be the correct block. Maybe I could post my example-project if that should be helpfull. Kind regards
Zaxis Posts: 7 Rating: (0)
Suggestion To thank Quote Answer

6/27/2008 5:24 PM	Rate (0)
Aret Posts: 2348 Rating: (265)	I'm sure it could^) Please note 1MBismaximumfilesizeyoucanuploadhere.
Aret Posts: 2348 Rating: (265)
Suggestion To thank Quote Answer

7/1/2008 9:23 AM	Rate (0)
Zaxis Posts: 7 Rating: (0)	This is the testversion that I used. FC41: In network 3 are the Find, EQ_string and NE_string that gave problems. M20.1 and M20.2 are the bits that I could set and reset without being overwritten. I also tried using just 1 network with the EQ_string function so that it won't be influenced, but still not the result that I wanted. Attachment test.zip (546 Downloads)
Zaxis Posts: 7 Rating: (0)
Suggestion To thank Quote Answer

7/1/2008 11:14 AM	Rate (0)
Zaxis Posts: 7 Rating: (0)	I think I have found the cause, allthough I find it very strange. I copied the FC's from another PC (straight out of the library) and then overwrote the ones I had in my program and now it seems to work (if I manualy overwrite M20.1 then it is automatically overwritten by the function), then I used the block out of my library and it was working also. But the most irritating thing is that I'm not sure what the cause was , because the blocks were green, indicating that they should work correctly, but they didn't. And now they do fine. Maybe somebody can give me a reason for this strange behaviour. Kind regards, Nick
Zaxis Posts: 7 Rating: (0)
Suggestion To thank Quote Answer

7/1/2008 8:13 PM	Rate (0)
Thijs Posts: 121 Rating: (16)	If a called block is green it only indicates that the RLO? is true. This makes the block turn green when monitoring. Try youre self //Green SET SAVE //Grey CLR SAVE
Thijs Posts: 121 Rating: (16)
Suggestion To thank Quote Answer

7/2/2008 9:53 AM	Rate (0)
Zaxis Posts: 7 Rating: (0)	@Thijs: it is true, as you mention, that the color of the block has nothing to do with the value of the RLO. But what I mean is: IF the block is green then the block is processed and therefor giving the correct RLO. This means that if I should set or reset an output of a processed block, the output should be overwritten by the block. But I've been thinking what could be the problem. Maybe it could be that I added the block from the library to the project, and then accidently opened it. Then you get a warning and an empty FC appears, and maybe I saved and downloaded that block (with no actual processing in it). But this would be rather strange because I tried with two different functions (EQ_string and NE_String) and both gave not the correct returnvalue. I hope this was a one-time problem and I hope it never happens again .
Zaxis Posts: 7 Rating: (0)
Suggestion To thank Quote Answer