Polling data from S7-300 OPC UA server

Hello there,

I have a siemens plc polling data over serial from a gage. values coming into PLC are in “char” data type. I had initially set up a transaction group using Siemens OPC DA server and had an item.
S7:[G_arm]DB102String0.5,1
The above polling would return value: abc.d which was perfect.

Now, for the same machine, I am trying using OPC UA module. I added the plc from OPC UA Devices list and it shows it is connected. I add an item with the path:
[G_arm_UA]DB102String0.5,1
The field for value shows " N/A".
I tried diff combinations
[G_arm_UA]DB102C0.5,1
[G_arm_UA]:DB102String0.5,1
[G_arm_UA]DB102String0.5
Nothing worked.

I can always use DA server but I will be installing the same in other plants. I do not want to install those Siemens OPC softwares when I have easy UA server access.

Any help would be greatly appreciated.

Thanks
Vishal

The syntax for addressing items on the Siemens PLC is described here, in the Ignition User Manual. Please give it a read.

You’ll want something like “[G_arm_UA]DB102,STRING1.5”, depending on where the string starts in memory and the length you want to read (I can’t tell from the addresses you posted).

Kevin,

I referred to the following line in manual. I did not see any " , " between I and String.
ISTRING24.50 A String of length 50 starting at offset 24 in the Inputs area.

Your example does show " , " it. I am going to try and let you know.

Thanks
Vishal

Kevin,

I still do not see any values. It displays “N/A”

I used:
[G_arm_UA]DB102,STRING2.5

I am capturing 5 characters starting at byte 2 in DB102.

One thing: My Data block in plc is set up as CHAR data type and under item in transaction group, i have String selected. I am not sure if that makes a diff.
I have same setup working fine in OPC DA server, so i doubt it makes a diff.

ANy thoughts ?

Thanks
Vishal

One thing that comes to mind is the wacky way Siemens handles strings. There is a Siemens string format, and then there is everything else. Siemens strings require a two byte prefix that decribes the max string length and the actual string length. I have worked with other software where they were treated as two distinct data types, so one would be used for Siemens strings, and the other was used for char arrays (which I prefer) or strings passed from other devices.

It’s a stretch, but maybe the Ignition driver is treating this as a true Siemens string and is depending on the two byte formatting. Just as a test, create a Siemens string in a DB and point to that and see if it works.

Step7: Yes, we’re expecting the Siemens String format. I missed that you’ve just a char-array in there… Not sure what to do about that…

vdesai: The comma is there when addressing a DataBlock; for the other data types you won’t see it.

I think you will have to think about adding support for raw strings (most other OPC software handles them). Most Siemens programmers use char arrays rather than strings because Siemens strings are kind of clunky when it comes to coding around and monitoring them, plus there is a limit on the length.

Vishal, I think your best short term solution is to create a string in another data block, and use SFC20 to block copy the data back and forth to your char array. That way, your exixting code wil continue to work, and you can still use the Ignition driver.

Step 7,
Thank you very much for the help. I will try doing that some time later in the evening.
Whats weird is the same setup works with OPC DA server under Ignition. It reads the characters properly even when defined as strings.

Also, i releaised about two byte string definition when i set up items under DA server. I simply called for data item path to look 2 bytes before my actual data address. That was a simple solution.

I am trying to convert the ASCII to HEX in siemens as another solution to work with ignition. Will spend some time later on it.

Thanks again :slight_smile:

Kevin,
Thank you for the help.

Let you guys know if it works.

Thanks
Vishal