Siemens Portal TRCV Instruction and setting String Length

I'm in the process of converting a program over from Step 7 5.4 to Portal 13...

One of the instructions being used is the TRCV instruction which returns data into a memory block.

The data being received is going into a section of a data block which is configured as a string...

The actual parameter in the TRCV instruction where the data is returned to is

P#DB12.DBX2.0 BYTE 254

which is returning characters, which form a string into the string starting at byte two of the string.

The TRCV instruction also returns a length as a Word, into MW128, so now I have the length of the string...

What I would like to do is to move the length of the string into

P#DB12.DBB1 if that nomenclature makes any sense. I'm trying to set the length of the string to the length returned by the TRCV instruction. That way I can use the standard string manipulation functions in Portal to parse the string.

However, I'm getting all sorts of data mismatch type of errors.

How do I set the length of string?

OK... Figured this one out on my own.

I added a field in my data block that holds a byte.

DB12 has a String [254] starting at DBB 0.

Then it has a byte starting at DBB 256...

I moved the word for the length from the TRCV instruction into the byte.

Then I used a BLKMOV instruction with the input parameter of

P#DB12.DBX256.0 BYTE 1

and an output parameter of

P#DB12.DBX2.0 BYTE 1

This moved the length byte at address 256 into the length of the string at address 2 of the datablock.

Everything seems to be happy.

Which PLC are you using in V13? Is it the same as in V5.4?

Assuming you are using a 300/400, here's the long version:
It actually returns the length as an INT, not a word. A WORD is the same as an Unsigned INT (UINT, 0-65535), not a signed INT (INT, -32768 to 32767). All take up 2 bytes, but the system may not let you switch back and forth, depending on your settings. It definitely won't let you directly send an INT value into a Byte, which is what the string requires.

The best/easiest way to convert an INT to a Byte is via the Move command. MOVE ignores data type and size, and just starts copying bytes over, starting at the LSB, until either the source or destination is full. Obviously, if you try to MOVE a DINT into an INT, the value of the DINT needs to be within the INT limits for the outcome to be as intended. Move works well with int/byte/word/dint, but if you try to mix those with REAL, then your result will be gibberish.

You probably don't need the P# in front of the DB12.DBB1. Making it a pointer only complicates things, and I don't think it would work.


Short version:
So if the TRCV block is storing the RCVD_LEN value in MW128, you would then use a MOVE to go from MW128 to DB12.DBB1.

Hah, I started typing that up, and then got called to do something else. I didn't check to see if there were more posts when I came back and submitted. Glad you got it working.

FYI, I don't think you needed to set it up as pointers with BLKMOV like you did. If you just used the regular addresses with MOVE, it should have worked as well.

Nothing wrong with the block move method; it just makes it a little harder to read.

I'm not sure how to address the length in a string without using pointers.

How do I do that?

You would just refer to the absolute address, which I think is DB12.DBB1. It might give you a warning that there is no tag there, but it shouldn't give you an error. You just need to watch out to make sure that data types line up, or you convert with the MOVE command.

Your right that it gives a warning... Using the blkmov does not give a warning.

I'll stick with the BLKMOV, because I'm leary about leaving a program with any warnings.

Warnings have been known to become errors when future versions of the programming software are released.

Thank you for the info though.

Oh... Almost forget...

It's an ET-200 PLC and I'm using Portal V13

Barry Kirk said:

Warnings have been known to become errors when future versions of the programming software are released.

Click to expand...

Excellent point. What used to be "are you SURE you want to do that?" can very well turn into "Nope, can't do that any more", because the developers are obviously much smarter than the user

If you were using the 1200/1500 (or the ET200SP/1500SP CPU I assume will get launched), then there is a way to do it "correctly" and easily. You can do it all symbolically, and not have to worry about the absolute addresses. In the 300/400 world (which includes the ET200S and ET200PRO), what you're doing is probably as good as any other method.

Glad you got it working!