? - access RSView tag device address using VBA or external app?

First let me post the reason. I need to have RSView interact with an external application tying the alarms to an external logging application. What I need to do is have RSView pass the info on what alarm has been double clicked for another app to take action. The most important thing to get this to work is to pass the date & time of the alarm along with the the tag that caused this to happen. At first I tried using RSOPC gateway, but this has proved to be the most unreliable way to spend $2000. I currently have the other app using RSLinx OEM to get data from the PLC. This would work if I named the tag exactly the same as the OPC device address to the data, however I have several cases where a HMI tag needs to be used due to things like scaling or min/max . . .

Is there any way that I could have a VB script based on an event in RSView that would look up the device address for a given FactoryTalk tag? RSSQL is not really an option for something as simple as this because the costs will get astronomical. RSOPC gateway was barely cost effective, but won out because it kept us from buying RSLinx OEM so its total cost was only $1300.

I would be your best friend / father your child / wash your car / etc. if you can help me with this.

Please?

When an alarm is triggered, you can handshake back to the controller. You can record the current time and date when an alarm is acknowledged at the controller. You can track the trigger and its value. You should be able to track everything you need at the controller and serve to your current OPC clients.

As far as I know, RSView ME can only function as a client to an RSEnterprise server. I don't know how to track events in RSView using VB scripts.

Good luck.

$

Sorry to drag up an old thread, but I'm just coming into the same problem myself. If I understand it correctly, after shelling out a large amount of money for RSview SE and a 10 client licence, I don't actually have an OPC server that my IT department can write simple code to extract data from. To make the leap over to the business network, I will require either RsSQL to interface with an SQL database, or RSLinx Gateway to allow our IT guys to write some custom code. I thought RSlinx Classic was the OPC server, but I know belive that it will only serve data to Rsview Clients. I can't believe I have to give more money to Rockwell, can someone advise if there is a better way.

RSLinx Classic is a general-purpose OPC 2.0 Data Server. The OEM, OEM Single Node, Professional, and Gateway licenses all serve OPC data to any local OPC 2.0 Data Access client. RSLinx Gateway is the only license that will serve data to a remote OPC data client.

There was a special low-priced RSLinx license called "RSLinx for RSView" that only served OPC data to RSView32 clients. It was never bundled with RSView SE, and only sometimes with RSView32.

Usually RSView SE uses RSLinx Enterprise as a FactoryTalk data server and leaves OPC out of the picture entirely. RSOPC Gateway will open up the FactoryTalk LiveData service to OPC clients, both local and remote.

You've already spent a lot of money; don't be reluctant to ask for an explanation of what was provided from the guys you spent it with.

Wow, I didn't know I was still subscribed to this thread. This is going to be extremely complicated how I got to this solution so hold on.

I found a workaround that was barely acceptable to me. I figured out that all the tags in RSView are kept in a file called tags.db in one of the folders under documents and settings - all users - rsview SE. (I am not so sure about that either as I haven't worked on this in a very long time.) I tried opening this file in every conceivable database program but nothing could recognize it. After hex editing it and looking for anything recognizable or that I could cross reference with another known database, I determined it is a Watcom SQL 4.0 database, circa 1992 or something like that. It turns out that this was a very useful and well regarded SQL server for that time period in certain circumstances. Unfortunately, this company ceased to exist in 1996. I tried buying about 10 books off ebay about using watcom databases, hoping that the software included with one of them would have an odbc driver, but none of them did. After researching this a lot further, I found that watcom's IP was sold to sybase I believe and they have a program called SQL Anywhere. It did come with an ODBC driver, so I did try this to connect to the DB but it requires authentication. I should also mention that when you install RSView it does install an ancient Watcom ODBC driver that was obviously written for windows 3.1 but it didn't work at all and would crash on 3 different computers we tried it on. Installing SQL Anywhere made this driver work again for some reason. Later because it was discovered that NERO 6.0 CD burning software was causing problems with a very advanced in-house application we uninstalled it, and I think that this magically made this driver work again. (It's been almost a year since I've touched this so I may be wrong). Back to the authentication, we were able to intercept the calls to the ODBC driver and determined that the username was "MMIUser" so one of the first passwords I tried was "MMIPass" and amazingly, it works. We can now pull this Database into any ODBC aware software such as Access and get all the low level stuff. I believe that this driver and login info works for all of the RSView SE databases such as the alarm log. We were then able to see how any tag was created, what all of its parameters were, and therefore import the tag database into our software program and recreate anything that RSView does on our own by emulating the processes that RSView has going on. This along with figuring out how to hack interprocess communication to work within an ActiveX control embedded inside RSView allows an amazing level of two way communication and interaction between RSView and external programs.

Since it's been almost a year since doing this I may have gotten a lot of details wrong, so post if you try to do something here, or if something needs more description and I'll fill you in some more.

Wow, that's awsome detective work. Want a job as an RSView developer ?

I was just replying to the thread-renewer who was surprised to find his RSView SE installation without a remote OPC Server.

Thanks for the update !

vjasko said:

Wow, I didn't know I was still subscribed to this thread. This is going to be extremely complicated how I got to this solution so hold on.

I found a workaround that was barely acceptable to me. I figured out that all the tags in RSView are kept in a file called tags.db in one of the folders under documents and settings - all users - rsview SE. (I am not so sure about that either as I haven't worked on this in a very long time.) I tried opening this file in every conceivable database program but nothing could recognize it. After hex editing it and looking for anything recognizable or that I could cross reference with another known database, I determined it is a Watcom SQL 4.0 database, circa 1992 or something like that. It turns out that this was a very useful and well regarded SQL server for that time period in certain circumstances. Unfortunately, this company ceased to exist in 1996. I tried buying about 10 books off ebay about using watcom databases, hoping that the software included with one of them would have an odbc driver, but none of them did. After researching this a lot further, I found that watcom's IP was sold to sybase I believe and they have a program called SQL Anywhere. It did come with an ODBC driver, so I did try this to connect to the DB but it requires authentication. I should also mention that when you install RSView it does install an ancient Watcom ODBC driver that was obviously written for windows 3.1 but it didn't work at all and would crash on 3 different computers we tried it on. Installing SQL Anywhere made this driver work again for some reason. Later because it was discovered that NERO 6.0 CD burning software was causing problems with a very advanced in-house application we uninstalled it, and I think that this magically made this driver work again. (It's been almost a year since I've touched this so I may be wrong). Back to the authentication, we were able to intercept the calls to the ODBC driver and determined that the username was "MMIUser" so one of the first passwords I tried was "MMIPass" and amazingly, it works. We can now pull this Database into any ODBC aware software such as Access and get all the low level stuff. I believe that this driver and login info works for all of the RSView SE databases such as the alarm log. We were then able to see how any tag was created, what all of its parameters were, and therefore import the tag database into our software program and recreate anything that RSView does on our own by emulating the processes that RSView has going on. This along with figuring out how to hack interprocess communication to work within an ActiveX control embedded inside RSView allows an amazing level of two way communication and interaction between RSView and external programs.

Since it's been almost a year since doing this I may have gotten a lot of details wrong, so post if you try to do something here, or if something needs more description and I'll fill you in some more.

Click to expand...

Wow. Your hacking skills are impressive!

Thanks for the replys, I'm still trying to get over the fact that a modern big dollar SCADA system doesn't come packaged with a fully functional OPC server.

spencerthedog said:

Thanks for the replys, I'm still trying to get over the fact that a modern big dollar SCADA system doesn't come packaged with a fully functional OPC server.

Click to expand...

Why?
For one thing, there is nothing saying that you are going to use XYZ's SCADA system with XYZ's Controllers.

But beyond that, why should extra functionality be built in to a product, where it isn't the prime focus of the product, and is better offerred as an option?

Using View32 or View SE, you do have access to VBA scripting, which can use ADO to access just about any kind of database you might want. Why isn't that sufficient for light-duty tasks or inter-process communications?

Using View32 or View SE, you do have access to VBA scripting, which can use ADO to access just about any kind of database you might want. Why isn't that sufficient for light-duty tasks or inter-process communications?

Click to expand...

It's been almost a year since I've used SE, but I do not believe that the VB functionality has access to ANY tag data at all unlike other SCADA packages. I also preferred to use windows messaging because it is much more efficient, is a lot easier to use with many different processes that all talk to each other, and there is no polling or monitoring that has to go on - as soon as a message comes in a command gets executed right away. What we were working on was an alarm viewer replacement with much more functionality so we needed access to a lot more RSView data then what RSView was willing to share so I went with the above workarounds.

RSView does have tag access using VB, but yes, I agree, if you are writing your own alarm summary, you'd probably want to do something like vjasko.

Vjasko - please check PM