AB PLC5 to PV1000+ with RIO

[stushe]

Hi team -
I have a problem ive persisted with for two days now , to no end. with power up , all is working fine ...so you ask ..whats wrong then ?? - well , its what happend when i reycle power on the panelview 1000 plus , is the issue .
OK - PLC5-15 B/J is what the testbed is. PLC5-30 i think is the destination in the real project. For now - I know that this problem is not the only installation that shares the same issue .
I have to use Remote I/O .
It is working perfectly to PLC5-15 with Block Transfer , using BTW & BTR . We are pretty sure its set to text book settings , and no overlaps or strange layouts are configured . As I said , with powerup , ALL is perfect ...messages , numeric writes / reads , words , bits ..all switch .
BUT - if you cycle the power on the PV1000+ ..the PLC READS with the BTR function , and over writes the previously loaded data fields with 0 ( zeros ) ...and this cannot happen . I have fields that i wish to load in my Panelview ..to configure/store in the PLC ..for process values . The screen works perfectly while powred , but recycle it , and no data is retained . I do not want to use Discrete I/O , although , this also does exactly the same , ive tried it already. The reason is that no I/O is being stored in the PV1000ie unless you use Memory tags , which can be ticked as Retentitive/Retain.
Does anyone know where the setting is so that the PV1000+ will act like a normal touch screen , like any normal provider makes ....ive never come across this before ever in 20 years.
The tricky bit is done , Block Transfer , and Remote I/O setup is running . Its just when you cycle the power ..like imagine a power failure on the screen , its restored , and all the process SETvalues are lost ...like written to zero in the PLC ..this is because the PLC5 is using BTR ..and reading the values in the PV1000 ..and finds them to now be cancelled or initialized to zero or initial state . Got me stumped ...I have found something that reads identical to the problem on a Panelview1000E... using Remote I/O ...but this is a PV1000+ ...using Remote I/O . I cannot be sure that the same configuration applies using RS View or manually setting a function in the terminal ( screen ) itself . Any ideas guys ?

 

[MichaelG]

No Idea Yet

If you can attach a copy of the program
If no, then at least a pdf of the BTW BTR rungs

What are your PV+ Settings? All Un-ticked retentive/retain?

Questions
If BTR is executing and the other end is not responding does it default the values to 0
Does this occur as the PV+ comms comes online?

 

[stushe]

I will post a copy of the lines in the morning .. im lights out now ( actually - i lie ..im in a motel wishing i could watch the F1 in turkey live .. but i have no sky tv here !!
So i watch online schedule .

Both BTR & BTW have diff read and write data fields aswell as contol words . Also the function blocks are double interlocked with Bit 15 if i recall to stage the reading / writing in sequence . i post something tomorrow .
All fields work correctly UNLESS , you repower the screen ..then you have to re enter any set values in the screen for any data that is a READ value from Screeb back to PLc ..another words ,.. any value you WRITE in the screen , thats read from the PLc . But as we know ..AB do it the otherway around..and its BTR that you use ..as its READ from panelview . the PLC N files 32 wds im dumping from the BTR is being wiped the oment comms come up on the PV1000+.
Thanks for wanting to help m8 - i appreciate it . I am omron freak ..with some GE fanuc experience , with Proface & AB micrologix experience ...not Panelview ! but already learned plenyt sofar in 2 weeks with RSview.
Cheers Stu

 

[Ken Roach]

The answer is essentially "that's just how it works". The values of both the Input and Output tables for RIO are contained in the 2711P-RN6 module, rather than in the FactoryTalk View ME application, and are cleared on power cycle.

FactoryTalk View ME has the ability to save the values of its internal Tag Database as Retentive Values, because it has access to the nonvolatile CF cards in the terminal. The 2711P-RN6 module doesn't have any nonvolatile memory of its own.

RIO has been difficult to implement on the PV+ since Day One and RA has discontinued support for it in the v6 hardware.

You're going to have to work around this aspect of the system somehow.

If it were my project, I would use separate PLC-5 data files for the process variables and the BTR/BTW data. Use COP or MOV instructions to place the process variable values into the BTW file so that they can be displayed in the PV+ terminal, and use the Enter Handshake function and COP or MOV instructions to move valid data values from the BTR file to the process data registers, using PLC ladder logic.

You could also try to use HMI Memory Tags and a Startup Macro to move the data from the retentive HMI Memory tags into the BTR data, but I'm not as confident in that method from a startup/boot sequence standpoint, and you'll then have to use macros everywhere to move data from the HMI Memory Tag to the BTR Tag or BTR Alias Tag.

 

[stushe]

Unbelievable - but thanks for the clarity

Thanks for the confirmation / heads up on the 'state' of play . We have no option to continue at present but use the PLC5 & RIO . I have indeed experimented with macro's ..YES ..I did use ineternal tag ( mem and ticked Retain value ) .this worked perfectly , then i used macro button to update. It retained the value in the screen , and when i activated the macro it loaded the internal to Block Transfer , then updated the PLC. I did have no fix for using the macro on startup ..the reason seems to be that the Macro is activated on startup before the RIO is ready ..so it causes a Screen Error . Also this is true when you use the macro to transfer the internal Mem tags ( retentitive ) ..and make the BT tags = the interanl tags on the Initial Screen ..( done by macro ) . This doesnt work either perhaps because the RIO is still being executed ..so if the macro doesnt work , the BTR ends up loading zeroes as you now tell me is un avoidable . The copy / move funtion seems to be delaying the inevitable . If you cycle the power and the screen values are lost ( because no memory ..) ,,and only Internal Mem tags are reatained , the you still have the same issue . To train operators that the NEW replacement screen does this issue , over a tired 1400 ( that does support this function i need ) ..is a bitter pill to swallow . How did this happen ..when an older product line did do the correct proceedure of storing values. Are there special flags or tags available in the PV1000plus that can ve used to detect a Powerup cycle ? like a First Pass / Scan flag in a PLC processor ? ...because id like to use that in a macro script trial . I mean , crudely ..whats needed , is to WRITE to the READ fields in the PV on first comms establishment ...to update from the PLC , and reload the old settings that were present in the PLC , before t decides to replace previously loaded values to (0) Zero . This factory i have here has got about 6 PV1000plus on RIO ,..they all on PLC5 ..and originally had 1400's and Mimic / P B display panels on RIO . The 1400 does the same problem until you change a setting in the terminal for RIO function . I was very hopeful that all i needed to do was change the same setting in the newer screen ..but its not available ! Cheers Stu

 

[stushe]

Macro usage & Keypad function

Well , heres is my work around that i did get working last week .
1st - Use Internal Mem tags for Numeric Display + Keypad Entry for the SV's used in the PLC process .

2nd - Use macro to transfer / make BT RIO address tags EQUAL Mem Retentitive Internal addresses ( used in Numeric Keypad Entry points ) .

3rd - place a MACRO button on the screen , and lable it PRESS to UPDATE NEW VALUES .

Now - the works , but unless the operator uses the UPDATE , we are stuck with internal values being changed / updated only ..and the BT READS remain old values ..and will be ZERO if the screen has been cycled .

So one protection i can think of , is for machine process to check for a value in a word used in the BT transfer area that the PLC is updated in with BT READ function ...and check that it has a valid value ..any value BUT ZERO . This will proove that the screen has not been cycled without a valid update taking place . So - no machine process can take place without first accepting the Alarm ...and pressing the reset for this alarm will activate the macro . The macro of course will transfer the internal addresses to the PLC and process can resume .
ie ..if N7:0 = 0 then MOV message .. Message will say Power / Comms has been restored PRESS RESET BUTTON TO CONTINUE ...
When new value is loaded ( Along with all other tags mentioned in Macro used, then PLC processes can continue .

Also for this Macro updater to be seemless ..I need to be able to place the UPDATE macro fuction under the keypad ENTER / RETURN button . But tests have prooved that the Macro invoking button do not get activated with another button ontop of it .
Can this problem be solved also ? I do this with other screens also ...but PV doesnt like it so far...what am i doing wrong?
Cheers Stu
​

 

[Ken Roach]

Stu, I was "present at the creation" for PV+ and I've long since gone hoarse asking rhetorical questions about why it works the way it does. I'm also reviewing two competitive products and gaining an appreciation for some of the things the PV+ does well or simply that take more time and effort on other platforms.

I still think that handling Numeric Entries in PLC logic is the best plan. Accept that the BTR target data table will be zeroed out when the PV+ is rebooted.

A typical Numeric Entry object will have four Connections:

1. A Connection to a word in the BTR data table for the value entered by the operator.
2. A Handshake connection to a bit in the BTR data table or the discrete data table to indicate that the operator has entered a value and pressed Enter.
3. A Handshake Acknowledge connection to a bit in the BTW data table or the discrete data table to acknowledge to the PV+ that the value has been accepted and the Scratchpad or Keypad can be closed.
4. A Connection to a word in the BTW data table to display to process value.

In your machine logic, you're going to use either a completely separate data table to hold your process values, or use the BTW Source data table.

You'll need a rung of logic for each Numeric Input that will copy the value in the BTR data table into the process variable data table when the Handshake is high. That rung then also copies the process variable value into the BTW data table, and sets and holds the Handshake Acknowledge bit high until the Handshake bit goes low again.

 

[stushe]

thanks

Hi Ken - firstly , let me thank you personally for tryning to help me accept what i cannot change ...heheh sounds like a creed to stop drinking ! ...LOL
OK - i understand exactly what you are saying here above ...
Question ... for a Numeric Entry Input ... Can I load 2 tags at once or can only one be used . I have a cunning plan if this can be done .
Stu

 

[stushe]

Sorted .com

Thanks Ken ...we done some conditional transfers from BT buffer and made Nfiles that the buffer dumps to just a buffer and thats that . The real SVs are now copied / moved conditionally if within limits . Also the Numeric Written value that is displayed at the point of the Keypad entry ( pasted under neath the Keypad entry point itself ) ..is pointing to the REAL SV N file ..so its there as a reference ..so no longer does it show zero after boot - it shows the working value , which is conditioanlly updated .
Thanks again Ken ...

 

[stushe]

dead simple - thanks

Thanks Ken and co for the ideas ,its pushed me to do it the new way . We have re worked the entire documantation and created new Nfiles for the Temp Keypad SV's ...and all works perfectly . Since i was wanting to keep things transparent , i have created a new BTW ..and write back anew block that shows the new process values that are limit tested before transfering from the Temp Keypad . Again - thankyou
Stu

 

[Ken Roach]

I'm glad to hear you came up with a programmatic workaround that is straightforward, reliable and tested. Thanks for posting the followup.