Siemens S7 Concatenate

Hello All,

I have a little problem that I need some help with.

I have got a 17 digit number coming from a supplier. It's basically a barcode number.

Now what I need to do is strip that number down and place it in a DB, with each number taking up a CHAR as shown in the picture SSCC.

Than again, the other way around, I need to take the CHAR's in the DB and concatenate them to make a 17 digit number.

I have looked around and can't really see a way to do it.

Preferably done in ladder, but I understand if it can't.

Cheers

Mark

This is part of the iec blocks in the Standard Library in Step 7

FC2 CONCAT
Description
The function FC2 concatenates two STRING variables together to form one string. If the resulting string is longer than the variable given at the output parameter, the result string is limited to the maximum set length and the binary result (BR) bit of the status word set to “0".

Parameter Declaration Data Type MemoryArea Description
IN1 INPUT STRING D, L Input variable in format STRING
IN2 INPUT STRING D, L Input variable in format STRING
RET_VAL OUTPUT STRING D, L Combined string
You can assign only a symbolically defined variable for the parameters.

I saw that, but it looks like it can only concatenate 2 strings.

I need to concatenate 17 CHAR's from a DB, and those 17 CHAR's can be anywhere in the DB, but will be sequential.

Cheers

Mark

Do you have SCL?

I did this by cheating a bit...

A STRING data type is just a bunch of characters where the first 2 bytes are the total string length and the actual number of bytes in the string.

So basically I'd do a BLKMOV from the beginning of the CHARs into the 3rd byte (byte 2 - because bytes start at 0) of the STRING.

So if your STRING address starts at DB 10.DBB 0, move your CHARs into DB10.DBB2

MarkNightingale said:

I saw that, but it looks like it can only concatenate 2 strings.

I need to concatenate 17 CHAR's from a DB, and those 17 CHAR's can be anywhere in the DB, but will be sequential.

Cheers

Mark

Click to expand...

You need 17 concatenate blocks after each other or loop.

sigmadelta said:

I did this by cheating a bit...

A STRING data type is just a bunch of characters where the first 2 bytes are the total string length and the actual number of bytes in the string.

So basically I'd do a BLKMOV from the beginning of the CHARs into the 3rd byte (byte 2 - because bytes start at 0) of the STRING.

So if your STRING address starts at DB 10.DBB 0, move your CHARs into DB10.DBB2

Click to expand...

This would be my approach as well.

Thanks for all the replies so far.

I will have a play.

LD, yes I do have SCL available to me.

Cheers

Mark

sigmadelta said:

I did this by cheating a bit...

A STRING data type is just a bunch of characters where the first 2 bytes are the total string length and the actual number of bytes in the string.

So basically I'd do a BLKMOV from the beginning of the CHARs into the 3rd byte (byte 2 - because bytes start at 0) of the STRING.

So if your STRING address starts at DB 10.DBB 0, move your CHARs into DB10.DBB2

Click to expand...

Can you elaborate a little bit on this please?

Cheers

Mark

Sure. The STRING data type can be 1 to 254 characters. The byte 0 contains the overall length of the STRING and byte 1 contains the actual number of characters in the STRING.

Bytes 2 to 256 contain the characters. Of course you will start your character sequence at byte 2. It doesn't make sense to start it later than that.

So you can move the value 17 in byte 0, the value 17 in byte 1, and your 17 characters in bytes 2 to 18.

sigmadelta said:

... So you can move the value 17 in byte 0, the value 17 in byte 1, and your 17 characters in bytes 2 to 18.

Click to expand...

Here is an example in TIA*, using a Serialize/Deserialize pair as a clunky** proxy for BLKMOV in Step 7.

The elements of Char array dbb.chars are the initial stripped data from the barcode (in this case '@aBcDe') with a two-character prefix as a placeholder for the Maximum and Actual lengths; the data in the prefix are ignored.

In OP's case the value of dbb.tx_len would be 17, and the length of the dbb.chars array would be 19 (= 17 plus the two-character prefix).

* if this was being done in TIA, there is a Chars_TO_Strg instruction to do it in one step.

** I suspect the BLKMOV in Step 7 would eliminate the intermediate Byte array, which Byte array a requirement for Serialize/Deserialize in TIA.

MarkNightingale said:

Can you elaborate a little bit on this please?

Click to expand...

TL;DR

PLC data are laid out PLC memory as a linear stream of bits.

A tag name is not a value. A tag name is a machine- and human-readable lookup key to an object that tells the PLC compiler three things:

• Where (i.e. the address at which) to look for the first bit associated with the tag name
• How many bits to look for at and after that address
• How to interpret that group of bits

Say there are 32 bits starting at the address implied by tag name A_tag like this:If we assume address increases left-to-right, MSBit-first and MSByte-first, then that could be

• 32 Booleans, either separate or in an array, seven of which are 1 and the rest 0, or
• four SINTs(USINTs) with values, 63, -128(128), 0, and 0, or
• The start of an invalid string (maximum length is 63, but the actual length is 128).
• Two INTs or UDINTs with values 16256 and 0, or
• a UDINT or DINT with value 1,065,353,216, or
• a single-precision floating-point (REAL) with a value of 1.0, or
• the beginning of a user-defined type,
• etc.

Usually a tag name such as A_tag can be associated with a particular data type and a value dependent on the last operation that wrote to its bits.

But instructions like BLKMOV in Step 7, and like Serialize/Deserialize in TIA, and like COP/CPS in Allen-Bradley WhateverLogix/Studio, treat tags as addresses to a stream of bits of a particular length. These instruction just move the bits, and do it with minimal regard for whether e.g. it makes sense to move a float's bits into a string object.

@sigmadelta called it cheating, presumably humorously. I call it thinking about tags, memory, and bits the same way the PLC compiler thinks about them.