Philip Wilkie

Well i dunno...I've got 15 different PV+ apps going out there, all at V3.2 and once I set them going they are all running fine. I don't think the problem is with the PV+ hardware, nor do I think the issues people are having is with the actual HMI functionality, which is really just a blending of RSView32 and Classic PanelView. Sure it isn't a full-blown HMI like RSViewSE is, but that is not what ME was targetted at. The majority of issues that I have seen in KnowledgeBase and on forums seem to be related to the FactoryTalk database, RSLinxEnterprise and the underlying aspects relating to the Microsoft OS.What I think has happened is that RSI have not fully appreciated how many issues were going to arise when something as closely and complexly coupled to the Windows OS was released into the real world. What may well have worked ok in the labs, has clearly run into issues in the real world, given that virtually every PC out there is different in some way. It's all a bit of a shame really, because underlying the obvious grizzles there is a nice product.

The scheme you have pictured should work. In order to help you we need more information about what is happening: 1. What are the Ch0 and Ch1 Comms LED's doing on the processor that is not communicating? 2. What are the LED's doing on the NET_AIC+? 3. Is that NET-AIC+ powered on? 4. Are you certain that every address node on each network is unique? 5. Are they all set for the same baud rate? 6. What is the "Max Address" setting for all the PLC's and drivers? 7. Have you swapped all the cables and parts one at a time to ensure there is not a hardware fault?

Contr_comm, Thanks for the update. The original question had me scratching my head looking for a GSV instance that might do the trick, and the tech note I originally listed was the first one I found when searching KnowledgeBase. Question. Could I also extract the IP information for other nodes (eg a PanelViewPlus) that exist on that network?

InTouch editing is done in the offline mode...and must be compiled before the Runtime Viewer will reflect the changes, whereas RSView lets you edit most components (except Channels) with the Runtime running concurrently and no "compile" process required. All I can say is that in your original post all you could manage to say for all your "years" of experience was that RSViewME/SE was "crap'. Well that is such an erudite and helpful comment isn't it? It was just leading with the chin. I've been in the automation field since 1981 myself, but I limited my background to my work as an independent contractor in the last 5 of them. Far too often I have seen people slag off products as you did without giving specific reasons...just a blow-off rant....to cover for the fact they probably didn't do their own job properly. Yet it in my experience, almost all the problems I have ever had with a product were of my own making; lack of familiarity, failure to read the help files, checkout the release notes, the Knowledge Base, or phone Tech Support or some combination thereof. I've only once in my Internet life slagged off a product, and that was after doing the 5 day official Training Course, (where the Training Officer said it was crap), 4 months of struggling with it, and finally making it go despite all the obstacles. At the end I had 14 pages of typed notes detailing bugs and deficiencies that justified me calling it "crap". (It was not a Rockwell product and nor is it relevant to name it here.) My point is that if you are going to "get on your soapbox" and you do not back your claims with facts...then someone like me is going to call you on it. Fair enough? Overall I've made 15 different ME projects go just fine and once I got my head around RSView Studio's way of doing things...it really is just a combination of RSView32 and PanelBuilder Classic, with some limitations due to the relatively limited CPU horsepower in the PVPlus...then it all worked just fine...and very efficiently I may add. Your "crap" comment simply doesn't correlate with reality here buddy. Maybe you could consider the purpose of this site is to be a little more helpful than that?

Add the PowerFlex to the CLX IO tree. You should be able to find the exact drive under "New Modules" when you rightclick on the relevant CNet icon. This will create in the processor tags ALL the IO required for all the status/commands and reference/feedback data that you need. There is no code example required. It is that simple.

This Knowledge Base note tells you how to do it for the 1756-ENBT: Obtaining Ethernet IP information from a 1756-ENET I think this method will also work for the L32E. If it does then: This MSG will pull back the IP Address for the LocalENB port and place it into a Processor tag. From there it is simple to display it on the HMI. If you create the HMI in the IO tree then it will be easy to create another MSG routed to the PanelView port, and pull back the IP info for that port too.

Yes it can be done with digital tags. Create the new tags as local "memory" tags. There is no limit on how many of these you can create. Now create a new Derived tag file. Derived tags can be device tags or memory tags. A derived tag is an analog, digital, or string tag whose value is determined through the evaluation of an expression. An expression can be simply a tag name or it can be an equation made up of tag names, mathematical and logical operations, special functions and If-Then-Else logic. The current value of a derived tag is written to the tag's data source. What you want to do is take the packed analog tag from the PLC and break it down into multiple memory tags in RSView using the derived tag file. This AB KnowledgeBase note tells you how to create the expressions: Bitwise Tag Operations Importantly it at the bottom of the note is outlines some of the resource issues that can arise if you overdo this method.

Always hilarious to see some underskilled techie post a rant the first time he uses a product and demonstably fails to either seek help nor understand what he is doing. I've used RSView32, RSViewME/SE, and Wonderware on multiple projects over the last 5 years. They all prove stable and worked just fine IF you ensured that you had read all the instructions. Every single problem I have ever run into, in the end proved to be something I was doing wrong. I've got an RSView Studio liscence at Ver 1.0 and all versions except 3.0 and to some extent 3.1, have proved perfectly ok. I've currently got 15 different PanelViewPlus projects at Ver3.2 running without missing a beat. And several of them are quite substantial applications with some very complex screens. The RSViewSE project was on one of the largest sawmills in the world. It was running a fully patched Ver3.1. They had some issues at the outset, but RS came through with all the required fixes. This again is a very large system...and it works pefectly well. The problem that most people seem to run into with RSViewME/SE is getting their heads around setting up the comms. The whole point they struggle to get is that the local Engineering PC and the taget PanelView and the download paths, can be in a large CLX system all be quite different. Some people never spot the fact that from within the local RSViewME Studio, you can open up a local copy of ME Runtime, and connect to the PLC processor....and run the entire project EXACTLY as if it were running on the PanelViewPlus. Or you can simply test single screens directly from with RSView Studio....all WITHOUT have to compile the application and download. Again I wonder how Mr Bishop failed to see how useful and powerful Direct Tagging is, or if he used Local Messaging, Parameter Files or Structured Tags. Once again I have to conclude that slagging off a system you have only used once, and barely understand...simply reflects more on the person opening their mouth, than any credibility they bring to bear on the topic. RSView32 is a very mature and stable product, with plenty of power to handle very large systems. The largest I have worked on had 24,000 tags to four CLX processors with redundant servers and 6 clients. Screen updates were always less than 1 second and in the three years I looked after it, I never had a single unplanned failover to the secondary server. But again, we planned and structured these systems with an understanding of how to make the most efficient use of the system resources. Amateurs who blunder into these things make a mess of them. My only big grumble with Wonderware is that it is still compiled code. Unlike RSView32 you cannot edit a project while it is running. The Archestra comms structure is the best aspect, as it gives excellent logging of all the system and comms status. It seems a much more recent piece of software than the rest of InTouch.