Old Version of RSView32

What was the last version of RSView32 to use a master disk
and what was the last OS it would run on
Thanks

RSView32 version 7.60 switched to FactoryTalk Activation, according to Rockwell Automation Knowledgebase Article 471100. So the last version to support EVRSI would have been the previous release, 7.50.

According to the Rockwell Automation Product Compatibility Center website, the latest operating system on which RSView32 7.60 was tested and supported was Windows 7 Professional SP1 32-bit.

RSView32 relies on a 32-bit database engine, so it does not work on any 64-bit operating systems.

The "last version that supported EVRSI" was 7.50 and it was only tested up to Windows XP SP3.

While there are a handful of "no known issues" flags on the Product Compatibility site related to Windows 7 Enterprise and Windows 7 Home Premium, I would not rely on those.

I currently have RSView32 v7.60 running on Windows 10 Enterprise and activated under out tool kit. Only things I had to do was change the install directory to anything other than c:\program files or c:\program files (x86). Then just change the comparability settings on the rsview32.exe to WinXP SP3 and Run as admin. Works for me...your mileage may vary.

Cheers

Hi,


Steveb55 - When you installed it did you get any OBDS errors? From what I read, the tag server is on a 16-bit service and that is the main limiting factor to installing RSView32 on a 64-bit system.





I do realize that I am replying to an old thread but, when times get rough! Has anyone else had success with running RSview32 on a Windows 10 machine? I do realize that it's not compatible.

Has anyone else had success with running RSview32 on a Windows 10 machine?

Click to expand...

I recommend Windows 7 32-bit... on a real computer or Virtual Machine.

We have run RSView32 only 32 bit Win7 machines with very little issues. I totally understand the need for support of legacy systems, but I find that anytime someone is referencing master disk it’s to get around Rockwell licensing, why not upgrade?

Firstly, sorry for the delay in getting back!

Initially this was the solution provided. We were to upgrade their system from RSView32 to FTView v12.0. Unfortunately, there is huge latency between requests and actions.

Their currently setup has a DH+ Network (57.6 k) which has 10 PLC-5's (of various processors from a 5/40 to 5/11 and two XP stations running RSView32 with 1784-PKTX cards. Currently when they make requests via the HMI the action takes 1 second, in which I found amazing for DH+ but the client finds it slow (Door open/close application). Client would like to replace the PC before they die. I suggested PLC's as well but no money for that.

The solution we provided was replace the two stations with Windows 10 machines, Convert the program from RSView32 to FTV Studio and install a CLX gateway (7 slot chassis with a 1756-ENBT and 1756-DHRIO) into the DH+ network. The the Ethernet portion is two Win10 hooked up to a un-managed switch which then connects to the 1756-ENBT. 1756-DHRIO was added to the DH+ network and is the last node of the network, in which I've moved the resistor.



Problem we are seeing is that when requests are being made via the FTV studio HMI application, after starting the client file, requests take 2-5 seconds and after running the application for awhile it seems that the application takes 8-9 seconds. Worth noting that there is no errors in the diagnostic list. We could see the set command execute in the diagnostic list but delay is so long. Even when viewing the data monitor in RSClassic. I really don't think it's the application but rather the gateway the limiting factor.

Solution we've tried to fix the situation but did not succeed so far, are the following;

-Removing auto negotiate and fixing everyone at 100 Mbps.
-Switching FTLinx to RSClassic gateway back to FTLinx (at RA request) for the communication path
-Use Direct referencing instead of HMI tags (which does improve by 0.5-1 seconds but would require ~170 macro modifications and still doesn't achieve that 1 second needed)
-Play with the displays refresh time
-Play with poll rates and packet sizes

As usual the business people sold this as a "quick conversion" and "up and running in no time" but we are over budget and they are pointing to me as the problem.

Currently have a ticket with RA and they are working on it but they've hinted they think its a legacy hardware problem. Any idea's would be appreciated! Was exploring the idea of trying the RSView32 on a windows 10 machine but still can't get it running. I wanted to remove the CLX gateway from the equation and use the RSView32 application and 1784-PKTX in the Win10 Machine. Now I'm thinking of putting a CPU in the CLX gateway and letting the CPU message the PLC-5's and create tables and the FTV application would write to these tables but would require big time tag changes in the application

Thanks in advance!

When communicating over DH+, never use FactoryTalk Linx. You can’t control
How fast the OPC topic pings the PLC for data.

Always use RSLinx and setup an OPC Topic. Set Max packets to 10. Default is 20 which is more than the PLC can handle through normal connections.

I don’t remember the exact terminology, but once you go over 10 connections the HMI has to use implicit connections to write to the PLC. If the HMI doesn’t get a response it will start sending several more write requests and this backs up the PLC.

If you want to keep response times down this is how you must set your OPC topic.

If you use FTLinx it will ping the PLC so often the PLC can drown and become completely unresponsive.

If you have multiple HMIs or Scada systems data logging, you’ll need RSLinx Gateway or Professional and then everything will need to use the topic setup on your gateway. Otherwise you will drown the PLC and the network with data requests.

RSView32 took all this a step further and would let you set the update time for every tag, so that mission critical tags like alarms or stop commands would take priority. You lose this with FTView but it’s still decent response time if you use RSLinx.

Also I’ve found the Prosoft Gateway is a whole lot more compact and cheaper than the 1756-DHRIO which is now obsolete. It’s been extremely reliable and has ran a very large 5/80 system for years now.