OPC servers

hipoint2

Member
Join Date
Jan 2006
Location
Cold Pa
Posts
45
OK I am trying to get a handle on this whole OPC server and client thing and how it works with HMI software. From what I understand a OPC servers job is to communicate a PC to a PLC correct? And what the heck is a DDE? From what I have been reading many people make a OPC servers to comm. with a number of brands of PLC's. What if a person wanted to make a few screens with VB would he need a OPC server to be the middle person? Wow this stuff is getting crazy. One more thing can a person install a OPC server like RSLinx on a server and be able to use that on many PC's with one install? Thanks
 
Last edited:
DDE: Acronym for Dynamic Data Exchange, an interprocess communication (IPC) system built into the Macintosh, Windows, and OS/2 operating systems. DDE enables two running applications to share the same data. For example, DDE makes it possible to insert a spreadsheet chart into a document created with a word processor. Whenever the spreadsheet data changes, the chart in the document changes accordingly. http://en.wikipedia.org/wiki/Dynamic_Data_Exchange

It is basically a method to for data to be shared i.e. plc data can be inserted into a spreadsheet.

OPC(OLE for Process Control): http://en.wikipedia.org/wiki/OLE_for_process_control


Those should help, there is a link at the bottom of the OPC page to a tutorial.
 
The OPC client is part of, or a module in, an HMI software package. The OPC client requests data from an OPC server, according the way it has been configured for update rates and requested tags.

The OPC server is a program that runs on a Windows box. The OPC server can be on the same PC as the OPC client or a different PC, as long as the PCs are networked and can communicate with each other.

The OPC server has an internal "driver" which is responsible for communicating with the field device (PLC). The internal driver has to be specific for the field device, talking the PLC's protocol on a hardware link that is compatible with the PLC.

It is possible to do your own HMI with VB, but if you want to use the features of OPC, then your HMI would have to integrate an OPC client into it, in order to talk to an OPC server. That's the main attraction of OPC: OPC servers talk to OPC clients and vice versa. Developing your own HMI with the requisite support issues is an economic choice, vs buying a commercial HMI package that has an OPC client module (which most do nowadays).

Both OPC servers and OPC clients need to have a tag data base configured.

OPC is intended to replace DDE; for a variety of reasons, one of which was robustness. OPC clients communicate with OPC servers using Microsoft's DCOM (between PCs) or COM (on the same PC, but DCOM?COM is not the serial COM port, rather COM is Component Object Modeling, a aeans of tunneling data between databases..

Dan
 
Thanks guys on the tutorial it cleared alot of stuff up. So I guess what your saying is that RSLinx is both a OPC server and client?
 
RSlinx really acts as an OPC server. RSLinx Gateway can connect as a client to other RSLinx installations through (using DCOM directly I believe), but it really isn't acting as an OPC client in that case either.

Going with the Rockwell example, RSView would be your OPC client (ignoring the fact that Rockwell uses their own "optimized" communication instead of OPC when going Rockwell/Rockwell). The path would be RSView->RSLinx->PLC.

Worth mentioning that DDE is a really old Microsoft technology, DCOM, which OPC-DA is based on, is a bit newer and more complicated, but still old, technology.

OPC-UA (unified architecture) is on its way. It will use: XML, web services, and other cool features to be very cool. In the meantime OPC-DA is the best you've got.

As far as multiple PCs accessing one OPC server - typically vendors create their own client/server distributed model to address this problem. Wonderware - Intouch 9, Rockwell - RSView 32 or SE, at Inductive Automation we use an SQL database and Web deployed approach. All of these technologies are more solid technologies for PC based distribution than the DCOM based OPC-DA.

Hope this helps
 
I have a question about OPC client's...

I have a Unitronix OPC server... My WinCC flexible runtime sistem is a client. The OPC server comunicates with 2 Unitronix PLC's and with my Runtime...

Now I wan't to now if I let's say force an Output to be ON on the PLC, and the PLC has it's own program that works in the background... Will the output be ON ("1") or will it stay OFF ("0") beacouse the PLC is telling the Output to be OFF ("0")

The OPC server says to me that it has sucsessfuly writen the value "1" to specific address.... but nothing happened when I checed the state of the output...
 
I would guess that the best you would get would be the output on for a maximum of one scan before it is overwritten again -

Just because you write something successfully doesn't mean it stays that way - you have done the SCADA equivalent of a duplicated coil .

If you want to "force" outputs like that , make sure that you internally map them first , so that you can "disconnect" them from the internal logic , but it is better not to , you see a few posts here where someone can't work out why a bit is being switched on , and it turns out that it is the HMI/SCADA system .
 
NoName said:
I have a question about OPC client's...

I have a Unitronix OPC server... My WinCC flexible runtime sistem is a client. The OPC server comunicates with 2 Unitronix PLC's and with my Runtime...

Now I wan't to now if I let's say force an Output to be ON on the PLC, and the PLC has it's own program that works in the background... Will the output be ON ("1") or will it stay OFF ("0") beacouse the PLC is telling the Output to be OFF ("0")

The output will turn on (at least the bit will turn on), BUT if the next PLC Scan turns off the output,..The Output is turned off. If you are watching LEDs on the output module, chances are you would never see the output turn on, because it would be turned off so quickly.

NoName said:
The OPC server says to me that it has sucsessfuly writen the value "1" to specific address.... but nothing happened when I checed the state of the output...


THe PLC probably turned off the output before the communications had a chance to read the on state.



If you want to see if your OPC client/servers are running, I'd suggest testing with a bit or output that are not in the PLC Program. That way it would just be the OPC controlling that output-not the PLC.
 
If you want to play with an OPC server, you can download the software from the Kepware web site. The software is free but you have to pay for the drivers. The Kepware people are running up front when it comes to OPC development and they are major players in the OPC Foundation.
 
So basicly what I will have to do is set a memory bit in the PLC, and alter the program in the PLC so that when this memory bit will be set to "1" the output will be also ON ("1").
Otherwise I can just monitor the state in wich the output is in, nothing else...

Am I right???
 
Yes and no - you can turn on the flag , but if anything else is trying to write to the flag or the output , then nothing will happen . You would be advised to be very careful doing what you are doing on a running machine - setting a flag that you haven't cross referenced could have unpleasant consequences .

You need to pick something that is not being used before doing external writes .
 
Last edited:
I've managed to sort out the problem...

I've taken a peak in the program that controls the PLC. I examined the code, and found out wich bit sets the output ON. Now I'm setting that bit to "1 and of course the output turns ON as well. :D

If I wouldn't taken a peak in the existing program I couldn't have done this...
When I asked the programer that wrote the code for the PLC if I could get a symbol table, the code,... anything... he just said this is not his problem,and that I've got tu figure it out for my self.
So I went ower his head... Not nice but... it had to be done.
 
Glad you resolved it , but reading your last suggests that this could have ended up with bent metal had you got your addressing messed up !
 

Similar Topics

Hello, I am trying to connect kepServerEx v5 in parallel with RSLinx Classic lite but kepserver will not connect to the PLC if RSLinx is active...
Replies
4
Views
2,068
Anyone have any good alternatives to Kepserver? We've used Kepserver for the last 15+ years as the OPC server to go along with some custom...
Replies
19
Views
6,463
Hi everyone. i am about to start a project using for the first time mitsubishi's MCWorks64. I read the documentation and it includes OPC server...
Replies
3
Views
2,305
Sorry about the title, it's hard to sum up my question in succinct enough form. In this system I'm designing, there will be a PC running OPC...
Replies
0
Views
1,550
I use RSLinx Enterprise in FactoryTalk View SE to retrieve tag value from CompactLogix PLC as follows; 1. I use RSLinx Classic to connect to...
Replies
0
Views
3,173
Back
Top Bottom