Addressing a PLC variable via OPC

Decamber

Member
Join Date
Sep 2008
Location
Middle
Posts
14
Hello,

I'm trying to set up a Wago 750-842 to an OPC server in order to read and write to a variable in the PLC, from the computer hosting the OPC server.

The idea is to make it possible for anyone to change the scale factor (a REAL) of a load cell. I will write a Win32-app for usability.

The problem is that I can't access the variable. In WAGO-IO-PRO32 I have declared the variable like this:

maxvikt AT %MW1: REAL:= 30000;

The OPC server I use is WAGO OPC Server and the client I have for debugging/monitoring purpose is Matrikon OPC Explorer.

Despite all manuals I have, I can't find a working address for accessing my variable.

Any clues??
Thanks in advance
 
Hejsan Decamber.

A little bit of experimenting can probably sort it out.
You need an OPC Test client (the Matrikon OPC Explorer will be fine), and the Matrikon OPC Server must run, and preferably connected to the WAGO PLC.

Depending on how the test client works, you may have to browse for available OPC Servers. So in the test client select the Matrikon OPC Server.
Then continue to add OPC Items. Again you can probably browse for available items. Select the available OPC Topic+Item.

In the end, you will look at something that is formatted like this.
ServerName:[TopicName]ItemName

ServerName is fixed, and is the one the Matrikon OPC Server uses for a WAGO connection.
TopicName is setup by you in the configuration of the Matrikon OPC Server.
ItemName is the Symbol (if available) or the absolute address.

So in the end it could look like something like this:
WAGO:[MyPLC]maxvikt
WAGO:[MyPLC]%MW1

edit: I dont work with WAGO, so I dont know if the Server name is WAGO or not, and I do not know if you must add the "%" in the address or not.

In this way you also test if the OPC connection works at all.

When I use a Siemens OPC server, it looks like this:
S7:[CDR]HMI.Item_3
S7:[CDR]DB10.DBW20
"CDR" is a connection I have setup in the OPC Server.
HMI.Item_3 is a symbol from the PLC program representing DB10.DBW20
 
Last edited:
Hallå Jesper,

Thanks for the reply. I'm afraid, though, that it didn't help too much. :) You see, in the OPC server I use (Wago OPC Server Modbus/TCP) you can't enter neither the symbolic name nor the address (of the PLC). It's a completely different syntax: dddddd (decimal) or 0xhhhhh (hex). The initial digit determines the modbus/tcp table and can take a value of 0, 1, 3 or 4; the other digits determine the address starting from 1.

Looking at the modbus/tcp table I find that 4 indicates Output Register and 3 Input Register. I can however not find out how the addressing correlates with the PLC addressing.
 
Hej igen.

Aha, so you use Modbus TCP. Yes in that case it makes sense that the addresses in the OPC Server displays in Modbus style - basically just some numbers.
You probably need to use a special library in the WAGO PLC to exchange data via Modbus TCP. There is no direct relation between the PLC addresses and the Modbus addresses. You have to program it in PLC code.
It makes sense that it is that way.

I just went to WAGO's own website, and they also only offer Modbus TCP for their own OPC Server.
Is this the reason why you have chosen Modbus TCP ?

Does there not exist an OPC server that connects directly to the address space of the WAGO CPU ? If that is the case, I find it very odd. I guess you can go online with the WAGO programming software to view addresses freely while online. So why should an OPC server not be able to do the same ?

edit: The way the addresses display in the OPC test client is exactly the same way you must address them in your application.
 
Last edited:
I just thought of something.

Maybe Beckhoff is a viable alternative for you.
Wago and Beckhoff are very similar, as they started to develop their products together and then parted ways. There is a rumor that Beckhoff and Wagos bus terminals are compatible - at least those that use K-bus.
And I also think that the programming softwares for both Wago and Beckhoff is based on CoDeSys, so it should be easy to migrate between them.

And Beckhoff definitely have an OPC Server that gives access to the address space of the CPU.
 
Sorry.
Previously I answered based on that I thought you use a Matrikon OPC server.
But you clearly stated in the OP that you use Wago's own OPC Server for Modbus TCP.
 
Thanks again for the replies, Jeppe.

I forgot to mention that my questions regard Modbus TCP, but luckily we managed to clear things up. :)

I see what you mean. And I went to the library manager in WAGO-I/O-PRO 32 and found a library entitled etherTCPmodbus.lib. It seems to contain functions for Modbus/TCP communication.

Now I only have to find out how to implement those functions.

You're right, by the way, about Beckhoff and CoDeSys. I think we have some Beckhoff's at work. Perhaps we have the OPC server somewhere as well.
 
I went through the wago documentation some time ago and here is what I came up with for our 750-842 project. If it doesn't help you, maybe someone else might need it in the future.

Using the ModbusEthernet_04.lib, as a modbus/TCP server, and everything(memory and modbus comm) as 16 bit integers.

Start Address to beginning modbus point as in the pdf
%MW0 = 0x3000
Convert to decimal
0x3000 = 12288
Add one because most modbus clients start at 1 and wago starts at 0.
12288 + 1 = 4X:12289


Max Global Address
%MW4095 = 0xFFF
Start + Max Address
0x3000 + 0xFFF = 0x3FFF
Convert to decimal
0x3FFF = 16383
Add one
16383 + 1 = 4X:16384
 
exabmorgon: Thanks for the reply. The library you mentioned didn't work in my case, but I'm sure it will help someone.


The original problem is now solved. The solution was quite simple. Declaring a variable at an address of, for instance, %QW256, makes it accessable on the modbus address of 300257. It works this way:

The PFC variables IW and QW have a reserved address space of 256 and up. ModBus OPC client you access it by the modbus address, which follows the syntax: Xnnnnn; where X indicates a Modbus/TCP table number and the n's is the address. Since Wago starts an address at 0 and Modbus begins with 1, you need to add 1 to the address specified in the PLC program.

This explains why an address of %QW256 is accessed on the modbus address 300257.


As for retentive variables, you declare them as this:

meaningoflife AT %MW1 : WORD:= 42;

It's accessable on the modbus address 312289.
The manual states you can use the address %MW0/312288, but that gave me a "bad configuration" error in Matrikon OPC Explorer.
 
Last edited:
Hej igen Decamber

Do you know this website ? :
http://www.opcconnect.com/
It seems to be the best place for everything regarding OPC programming.

Btw. I see that you want to make a Win32 application.
If you are programming for a Windows platform, and you right now must take a strategic decision about how to do it, why dont you consider .net in stead of Win32 ? I would not choose Win32 for a project that could potentially last a decade for example.
 

Similar Topics

I have a system using Rx3I CRU320 redundant CPU with Proficy Machine Edition Software. In the hardware configuration of each CPU module, under...
Replies
14
Views
389
Hi All Working with Tia v16 on a PLC 1515F I am getting older by the minute, beating on indirect addressing for a DB I have a DB with 65 row of...
Replies
7
Views
3,787
Hello I read your info about modbus addressing with %MW register. I have a PLC with registers PLC ADDR: MW4513 and the machine constructor write...
Replies
4
Views
7,114
Hello guys, This works: L P#DBX 30.0 LAR2 But I need "DBX 30.0" to be input parameter to the function. I made pTag variable with data type...
Replies
19
Views
6,389
Greeting, I am doing some investigations on which driver(s) support tag based addressing (eg. Pump001_Running) rather than DB or Modbus based...
Replies
4
Views
3,745
Back
Top Bottom