Hello,
Continuing from previous locked post for same topic:
Step7, Kevin:
I did what you said. I moved the data from Char array of incoming serial data into another DB with String data type. I moved one byte at a time using SFC20.
Using variable table, I am able to see all the data in newly created string DB 103. I changed the item path accordingly on ignition but no luck. It still shows NA.
Attaching two pics for the same.
Anything out of box you see there ?
Thanks
Vishal
What are the values of bytes 0 and 1? If those are zero, the driver won’t be able to interpret the string at all.
When you create a string variable in a datablock, Siemens will automatically generate those values. It looks like from your VAT table that you just created another array of chars, which is fine, but you have to trick the driver into thinking it’s a string. So, set DB103.DBB0 to 254 and DBB1 to whatever your expected string length is going to be (it might even work if you also set it to 254, I’m not sure). I am not sure about the Ignition syntax, so Kevin can verify that.
Step 7,
I did create a string variable with 254 length. I used SFC20 20 times moving one byte at a time and for display i used character on attached variable table.
Having said that, for the heck of it, i tried entering 254 in item path for string length instead of desired length of 3.
[G-arm]Db103,String0.254
And boom, I see all the characters on ignition. Phewwwwwwwwwwwww !!!
I think i will have to store incoming data by spliting in different strings and call the entire string lengths for diff items. (or is it always supposed to be like this ?? )
I think this will work.
Thank you Step 7. 
It would not have been easy without SFC20 direction 
Regards
Vishal
You only need to call SFC20 one time. It gives you the possibility to copy large blobs of data in a single call when you use pointers. For instance, if I wanted to copy the two 100 byte strings, I could do something like this:
CALL SFC 20
SRCBLK :=P#DB102.DBX 0.0 BYTE 100
RET_VAL:=MW10
DSTBLK :=P#DB103.DBX 0.0 BYTE 100The “BYTE 100” is where you would set the number of bytes.
If I were doing it, now that you see what needs to be done with defining the string length, I’d go back to the orginal char array and prepend the two string length bytes in front of it and change the address in Ignition to trick it into thinking it’s a string. That way you wouldn’t need SFC20 at all. There are a dozen ways this can be done though, so whatever works.
Step 7,
I finally have it working the way I wanted.
I’ll explain what i did. Some one else could use it too…
I wanted to parse the serial data coming into PLC so that I could write the parsed values into different items in database through ignition. Incoming data was ASCII and i used SFC20 ( block move) to move it to another DB which had string variable. This way Ignition can look at STRING rather then ASCII.
I have all my data coming in DB102. ( Array of “char” data type)
Moving data into DB103 DB104 DB105 using SFC 20. All three DB’s have a string variable defined for length X.
Now, you can directly use the Db103 Db104 and DB105 addresses into ignition’s item path and it works like a charm.
Note: Initially, I started with one DB 103, with three string variables that stored three values. However, ignition would not show any value. Only N/A. For some reason, it would not work with multiple strings in a same DB. 
I saved the data in diff DB’s and it worked Ok for me.
There will be many ways to do this. above is one of them.
Thank you very much Step 7 for guiding me on this issue. Highly appreciated 
Eg:
DB 102: Array of Char type: 101.234 456.765 145.675 1
Use three SFC20
DB 103:String variable: 101.234
DB 104:String variable: 456.756
DB 105:String variable: 145.675
DB 106:String variable: 1
Item path:
[G_arm-opcua]DB103,STRING0.8
[G_arm-opcua]DB104,STRING0.8
[G_arm-opcua]DB105,STRING0.8
[G_arm-opcua]DB106,STRING0.1