Forum Replies Created
I tried VNC but didn’t know I had to configure it on the PanelView. That’s probably why it failed to connect.
I’ll take a whack at it again with the VNC server enabled on the PanelView and report back here on the results.
Happy new year Fred.
I only have two Panel Views to deal with so I was looking for a quick and dirty solution (e.g., free) that would allow me to keep my lazy arse in the office and not have to walk out onto the production floor to update the network information on the things. (The original installers only put a bare minimum of network information on them.)
A PIDE’s output is an analog output that is used to drive a control valve or some other analog device by providing a 4-20mA signal. I’m not sure you will get it to drive what I am assuming is a solid state relay.
It never fails. Within a few hours of posting here, I figure out how to deal with the problem. I guess describing the issue so someone else can follow along clarifies things in my mind.
I ended up essentially what you suggested. I took the output of the GRT block and connected it to the ProgAutoReq input of the PIDE and to input of a Boolean NOT (BNOT) block. The output of the BNOT was connected to the ProgManualReq input on the PIDE. I confirmed that CVProg was still set to zero.
Now the operation is as follows:
When the tank volume is less than the set minimum, the output of the GRT is 0 (zero). The ProgAutoReq bit is set to 0 (zero), the ProgManualReq bit is set to 1 (one) and the CV is set to CVProg. Regardless of what the PV and SP are, the CV remains clamped at 0 (zero) and the valve stays shut.
When the tank volume rises above the set minimum, the output of the GRT is 1 (one). The ProgAutoReq bit is set to 1 (one) and the ProgManualReq bit is set to 0 (zero). The PIDE begins to control the valve (CV) based on the SP and PV.
From your spreadsheet it looks like you have addresses from both the .151 and .153 network Many-to-One NAT’d to the 10.136.0.36 address. I can’t really tell where your controllers are relative to the HMIs. Are the HMIs trying to communicate across the stratix to controllers on the other network?April 12, 2019 at 8:22 am in reply to: Limiting CV while maintaining controller in program mode #4000
This particular PIDE, under normal operating conditions, would not be set above 25%. But it’s good to know that if I ever need to change that, I’ll need to be aware of the condition you described above.
JimMarch 21, 2019 at 1:42 pm in reply to: Limiting CV while maintaining controller in program mode #3821
Turns out that I can get away with running the equipment in question while limiting the steam input to 25% all the time. I did this by setting the CV High limit to 25%.
I thought about doing something like what you suggested but I was holding out for a solution that wouldn’t require me to do any “switching.” I’ll implement this approach and see how it goes.
Just so I’m clear on the concept, you are running water through a heat exchanger into the tank. That water is being heated to a specific temperature using steam in the heat exchanger. The level of water in the tank is being monitored so as not to let the level get below the level of a steam sparger that is located in the tank. You are also using live steam to heat the water in the tank in order to maintain a specific pressure in the tank.
Does that cover it?
I’m having some trouble visualizing your set up. Would it be possible to provide a sketch of the physical set up showing the valves, etc.?
Would it not be possible to run the PID that controls the feed temperature valve in Override or Hand mode with a set CV, while monitoring the water temperature then switch back to Auto mode once you’ve achieved the water temperature you need for successful start up?
Thanks for the response. I actually stumbled across the help file about 10 minutes after I submitted my original post. Funny how it works that way.
JimNovember 16, 2018 at 11:08 am in reply to: FactoryTalk View Studio: Error Opening Project – Cannot Connect to Addin #3569
I didn’t think your Windows version would be the issue. I’ve had Studio 5000 on the laptop when it was Windows 10 Version 1703 and it’s made it through all the Windows 10 updates pretty much unscathed.
Post back and let us know how the WebRoot thing works out. I’m really curious about it given my past experiences with that software.
JimNovember 16, 2018 at 10:34 am in reply to: FactoryTalk View Studio: Error Opening Project – Cannot Connect to Addin #3567
I’m running pretty much the exact same set up as you are (Windows 10 Version 1803, Studio 5000 Vers 28 and 30) with the exceptions that I’m running FT Services Platform 3.00.00 (CPR 9 SR 10) and my laptop is up to date (11/13/18) on all applicable MS security/other patches. I don’t, however, have WebRoot installed on my machine. Nor would I allow it to be installed.
When I took over the task of managing the IT at my current job, all the machines had WebRoot installed on them by the service provider. It was an unmitigated disaster. The service provider wasn’t a lot of help when it came to fixing broken software (one of the reasons I was hired). The solution was to rip the software out by its roots (pun intended) which turned out to be no easy feat. It’s as bad as any virus I’ve ever had to deal with. In one case, I had to reformat a system’s hard drive to get rid of it since the removal process provided by the vendor didn’t work.
I understand your approach to white listing, etc., but I suggest you turn it around. Remove the WebRoot software and see if that fixes the problem. If so, then get the client to work with the WebRoot administrator to sort out what needs white listing, etc.
Just my 2¢
NATing is usually done when you have to hide the NAT’d network for addressing or security reasons. NATing will also (usually) keep broadcast traffic from traversing the NAT device.
Prior to “retiring” and jumping into my dream job at the distillery, I was the chief IT architect for a major aerospace contractor. One of the last projects I worked on was interconnecting a bunch of stand alone PLC networks and our business enterprise network. Both sides of the “house” had multiple concerns about doing this.
From the IT side, the IT security guys were horrified by what they saw in the PLC networks (devices that hadn’t been patched in years, stuff running on OSs like Windows CE and Windows 98, etc.) and had no desire to connect those networks to the business network without having some sort of control point (e.g., firewall) in between the networks and a plan for getting rid of the old, offensive systems/software.
The PCL guys, on the other hand, were terrified that connecting to the business network would reek havoc on the PLC systems by pushing out updates, flooding the networks with unneeded traffic, etc. They also expressed the same concern about people being able to access the PLC network devices.
The PLC network device access is a valid concern. A lot of the devices on a PLC network are implementing web based front ends that need to be secured. I’ve found that the PLC drivers aren’t used to having to manage the security of their network because they’ve always been stand alone networks. Reminds me of the 90’s when I first started integrating separate networks together.
This collision between Operational Technology (OT) networks (PLC networks) and Information Technology (IT) networks (business networks) has become a hot topic with the PLC and network vendors. AB, in conjunction with Cisco, has been pushing this topic a lot lately. Here’s a link to their converged network document.
You can address this concern with Access Control Lists on the devices doing the NATing, if they’re capable implementing ACLs. My approach at the distillery involves using a port on one of my firewalls. This approach allows me to maintain segregation between my PLC networks and the business network. I can also use the firewall to implement rules that allow the devices on the PLC network to communicate with the appropriate business systems and vice-versa.
The particular situation this is designed to deal with is an “oh crap” moment. Running the stills without the condensers being cooled will result in a pressure build up in the stills, not a good thing. The objective is to shut down the distilling process until the condenser pump is fixed. A by-product of shutting off the steam to the beer still is that all the mash in the still “drops” and we have to start the process over from the beginning.
I’m working on modeling the implementation now. Once I’ve tested and validated the approach, I’ll update my production configuration.
That should work so long as you don’t have devices on the private side of Stratix1 trying to communicate with devices on the private side of Stratix2.
Running NAT on the 5700 messes with lots of “normal” operational things. If you don’t need anything on/behind the switch to communicate the Internet, there’s really no reason to run NAT.
Yes. See attached.
Attachments:You must be logged in to view attached files.
Do you have NAT enabled on the 5700?