ajmc94
Member
Hi,
First time creating a thread!
Currently our clients 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. When they make requests via the HMI the action takes 1 second for actions, for which I found amazing for DH+ but the client finds it slow (Door open/close application). Client would like to replace the PC's before they die. I suggested PLC's as well, but no money for that.
So, the solution we provided was replace the two stations with Windows 10 machines, Convert the program from RSView32 to FTV Studio v12.0 and install a CLX gateway (4 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.
The problem we are seeing is that when requests are being made via the FTV studio HMI application (Client), 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 the delay is long before the action happens. 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
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 I have a ticket with RA and they are working on. They seem to think its a legacy hardware problem. They also are only testing with one CPU in a DH+ network instead of 10 PLC's. Any idea's would be appreciated! but they keep on testing with
I 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. The FTV application would write to an array in the CLX and the CLX would send a message to the appropriate PLC. Unfortunately this would require big time tag changes in the application and i'm afraid of the DH+ network not handling it well.
Thanks in advance!
First time creating a thread!
Currently our clients 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. When they make requests via the HMI the action takes 1 second for actions, for which I found amazing for DH+ but the client finds it slow (Door open/close application). Client would like to replace the PC's before they die. I suggested PLC's as well, but no money for that.
So, the solution we provided was replace the two stations with Windows 10 machines, Convert the program from RSView32 to FTV Studio v12.0 and install a CLX gateway (4 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.
The problem we are seeing is that when requests are being made via the FTV studio HMI application (Client), 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 the delay is long before the action happens. 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
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 I have a ticket with RA and they are working on. They seem to think its a legacy hardware problem. They also are only testing with one CPU in a DH+ network instead of 10 PLC's. Any idea's would be appreciated! but they keep on testing with
I 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. The FTV application would write to an array in the CLX and the CLX would send a message to the appropriate PLC. Unfortunately this would require big time tag changes in the application and i'm afraid of the DH+ network not handling it well.
Thanks in advance!
