First Impressions - Panel View Plus 700

[BobLfoot 302]

Received my first PVP 700 last week and began to play with the software. 1. I must say the RSLinx Enterprise is no where near as user-friendly as RSLinx Classic. I even stopped to read the getting results booklet, well truthfully I skimmed it. That helped a little. 2. Tags and Shortcuts posed a whole nother issue. Did get my project running 2711P-T7C4D1 display with ehternet comms. I still get the feeling that my macros are sluggish in execution. Taks a full 3 to 4 seconds for the display to change from the time I toggle a bit in the plc. 3. Had a sudden crisis pop up where I needed to use the PVP 700 temporarily as a replacment for a PV600. Took no chances and read appendix B of the RSStudio manual all the way thru. Followed the Step by Step instructions and every thing ran 1st time except the alarms which where bit triggered. Finally read that section and deciphered the Rock_Latin. They should ahve siad don't use a tag browse directly to the target address. Now it is running until the exchange PV600 gets here. One down side is cost. PV Plus is more costly than old PV at list and on top of that we get less of a multipler reduction on PVP. Guess you gotta pay more for new technology. Doesn't mean I have to like it.

[BobLfoot 302]

SECOND IMPRESSION I jsut finished testing my project application on my development box. The target will be remote I/O. I tested the unit using Ethernet I/O from my PC and now have to redefine the tags to the RIO card. There must be a better way to do this. Ideas Gurus.

[rpraveenkum 5]

you refer this tech note before start http://rockwellautomation.custhelp.com/cgi...amp;p_topview=1

[rpraveenkum 5]

try this also http://rockwellautomation.custhelp.com/cgi...ated=1066881600

[BobLfoot 302]

Praveen your links show configuring the RIO as local, but my development PC has no RIO capability. And I get a fault from this config when I run the application on the development box.

[rpraveenkum 5]

Bob local tab configuration is to communicate rsview Me to controller can run same in development PC & Target tab configuration for Panelview plus device to controller use the config in target tab

[BobLfoot 302]

I understand that I must set the RIO definition up in the target tab and map my tags to it for the PVP to work. Here is my situation I have a PVP 700 with RIO, a PLC 5/80E and a development PC. I want to test my application on my PC by using ethernet comms to the plc and then place it in the PVP and use RIO comms. I see no way to achieve this without redefining all my device tags from ethernet to rio after testing. Anyone else haver a better solution? Can my 1784-PCMK card mimic a 2706-RN6 maybe?

[bikerdude 0]

bob, this kind of testing is necessary for a guy like me who makes mistakes all over the place & has to spend a ton of "de-bug" time on every PV project I do from scratch. That said... It is best to have all 3 devices on the same network while testing/editing. Whether it is Ethernet or serial or whatever. Preferably the runtime network type so you don't have to guess with the tag syntax structure. Preferable not out on the plant floor while everyone is standing around watching! I have read that the PCMK Rev.B will do RIO but I have yet to figure out how. I don't think the A revision will do it. I have used the laptop as a test station for the RSView Studio program with very little success. My last project had the PV & PLC on DF-1 & laptop on ethernet to both. Your PVP has Ethernet...right. I know the 5/80E has it. Can you setup the local tab as ethernet & the target tab as RIO? That is how I did it, I was able to edit either program while testing with both devices running their programs. Hope your project goes quicker than mine did. BD

[rpraveenkum 5]

Bob you use 1784-PKTX on Remote I/O not PCMK see this list Hardware Drivers supported by RSLinx Enterprise: * Ethernet * Serial DF1 to PLC-5, SLC-5, or Logix platforms * 1784-PKTX on DH+ * 1784-PKTX on DH485 * 1784-PKTX on Remote I/O * Virtual Backplane (1784-PCICS, 2711P-RN15B) * Serial DH485 (PVPlus/VV-CE) * 2711-RN6 on DH+ (PVPlus/VV-CE) * 2711-RN6 on DH485 (PVPlus/VV-CE) * 2711-RN6 on Remote I/O (PVPlus/VV-CE)

[BobLfoot 302]

SO the short answer is there is no way to test a Panelview Plus Remote IO Project on a development node you must move it to the PV Plus and test with "real" hardware. That said, I spent 4 hours last night doing just that and here is my opinion so far. PVP is a pile of junk!! Here is the application I am trying to create. 1. One display screen - YES just one screen. 2. Four Multistate indicators on the screen. Each indicator has 100 states. Internal Memory Variables STATE1, STATE2, STATE3 and STATE4 keep track of what state each indicator is in. 3. No Block Transfer I/O just a full rack of discretes. 4. I receive four input words from the PLC they are STATE, VAR1, VAR2 and VAR3 5. A macro loads STATE, VAR1, VAR2 and VAR3 into the proper STATE1 ... STATE4, ST1VAR1...ST1VAR3, ST2VAR1...ST2VAR3 or ST3VAR1..ST3VAR3 depending on the value of the new state. 6. The value of the Data changes each 150 ms. I cannot get PVP to execute a macro in 150ms. Seems to take longer. Also am seeing State 22 in the State variable but the PLC never sent a 22 on that output word. I think it is going to be necessary to craft a one shot bit of logic in my macros. Have an idea how to fix it all tonight. Will let you all know. BTW -- All this work is to make a PVP replace a DL40. I am coming to believe sometimes newer isn't better.

[BobLfoot 302]

Spent another hour tonight inplementing my One Shot Tag into the macros logic. I'd say it looks like this is going to work now. Will begin a side by side test with DL40 next week if resources are available to isntall the PVP. Here is what I wound up with. Macro 5 runs when One Shot is Off and Discrete Input Word from PLC does not Equal PLC_MSG_NUM Macro 5 loads Variables PLC_MSG_NUM, PLC_VAR_1, PLC_VAR_2 amd PLC_VAR_3 from their discrete input words. Macro 5 then sets One Shot ON. Macros 1 thru 4 run when ONe shot is on PLC_MSG_NUM is within the range of that macro to process. These macros load Variables Line_X_MSG_NUM. LINE_X_VAR_1, LINE_X_VAR_2 AND LINE_X_VAR_3 from PLC_MSG_NUM, PLC_VAR_1, PLC_VAR_2 amd PLC_VAR_3 respectively where X is the Multistate Indicator Line Number on the screen. {Note Macro 1 process line 1, Macro 2 line 2, etc} The macros then reset One Shot to OFF. The logic flow then becomes as follows: A. Input From PLC Changes. B. Macro 5 runs loading "PLC variables" and sets One Shot. C. A macro 1-4 runs and loads "PLC variables" into "line Variables" and resets one shot. D. The process waits for Step 1 to repeat. The "Line Variables" control the four multistate indicators. Works fairly well on my test bench.

[Nathan 7]

Bob, What data is changing every 150ms? It's increasingly hard to justify as touchscreen PC based terminals get cheaper and easier to work with. Your single screen application doesn't sound like it should be very hard to implement with any HMI package (except the 150ms part???).

[BobLfoot 302]

In the current DL40 application the 4 comamnd words of I/O address O:101, O:102, O:103 and O:104 change after a timer set for 0.01 timebase and vlaue of 15 is done. Now that should be 150ms, but the average scan time is 141 ms and the max scan is 185 ms. So it changes more likely evey 282 ms or worst case every 370 ms. These four outputs contain the message number and variable data items 1, 2 & 3 respectively. I've written the PVP app to peform the same function and once I applied a one shot so each new datum is processed only once it works great.

[paulengr 44]

I don't see any advantage to attaching the PVP as a slave to the PLC via Remote I/O. Why not just wire it in via Ethernet? If you put a small "dumb" switch between the PLC and the rest of the network such as one of the ones from Hirschmann (recommended by AB), then attach your PVP there, then you have effectively isolated the PVP from the rest of the network with the small possible exception of broadcast messages. Since a PLC is involved, similarly it seems nonsensical to directly access the I/O. Why not communicate to the I/O VIA the PLC instead of trying to share access/control? Even if you have a bunch of "stupid logic" that does things like: XIC <bit from Panelview> OTE <output bit> ...then later it becomes trivial to do interlocks, overrides, logging, etc.

[BobLfoot 302]

I thought about accessing the PLC over ethernet and eliminating all the DL massage logic. Turns out it was easier to write some logic in the PVP.