Retain Controller Data in an HMI tag (Allen-Bradley)

[Money4Nothing]

I have an application where I need to retain some data in an HMI tag. I'll explain my proposed solution, please advise if you think this will work and perhaps maybe a better way to implement it.

I have a Control Logix PLC control system (1756-L55), with lots of I/O, but of main concern are some Incremental Encoders. Part of this system are some HMIs using RSView ME (and RSView Enterprise). I am keeping track of an absolute position of a rack and pinion system using some incremental encoders (it would be nice to have absolute encoders, but the system is already constructed and its too late to change). I'm using POINT I/O 1734-IK encoder modules on ControlNet.

Here's the kicker: the PLCs cannot remained powered up at all times. They must be powered down for long stretches of time (due to other factors beyond my control). Of course when they power up, they reload their program from non-volatile memory with original tag values restored. There is no way I can remember what the last count of my encoder was in a controller tag. GRRRRRRRRRR .

So my solution is to use an HMI tag. I have an HMI tag whose source is the controller tag with the encoder's "Current Count" value. When the PLC shuts down, the HMI tag should retain its value (I am hoping). So I write a macro in the HMI, which executes when the minor fault code from the PLC is issued which indicates a project load from non-volatile memory. The macro sets the value of the 1734-IK "Preset Value" tag to the value of the HMI tag which hopefully has the last known encoder count. Then the macro further issues commands to inhibit the 1734-IK and reset its current count value to the preset value that I just loaded. Then viola, the Current Count is the same as just before the PLC was powered down.

Clear as mud?

Concerns:
I've never tried to set a controller tag to the value of an HMI tag with a macro before. I don't even know if that's possible. I'm also concerened that since the HMI tag is sourced by the module's "Current Count" tag, (whose value will be 0 on project load), that it will be reset to zero before my macro has a chance to write to the "Preset Value" tag. I'm also not 100% sure if an HMI tag sourced from a controller will retain its value if it loses connection to the tag server (i.e. the plc is turned off).

If you understand my dilemma at all and have any ideas or suggestions, please post away. I will be implementing this idea soon, and I'm fearful of a failure with no backup plan. I'd like to be advised that "yes it will work " or "no it won't, you're an idiot " so I can come up with another solution. *gulp* Thanks in advance.

$

[Gerry]

non-volatile memory on a L55?? - are you sure?
how will you know the encoder hasn't moved while power is off?
get the auxiliary battery option for the processor.

[jstolaruk]

Originally Posted by Money4Nothing

Of course when they power up, they reload their program from non-volatile memory with original tag values restored. There is no way I can remember what the last count of my encoder was in a controller tag.

This isn't right. You should only reload the program out of non-violatile memory if you loss battery power (for the ram).

[monkeyhead]

Go online with your PLC, put it in program mode, then open the processor properties dialog.

Under the non-volatile memory section, you can choose when the program is re-loaded. I have a machine based on Control Logix and ran into the same issue. I changed it to only load from non-volatile memory on demand. Now when the power is cycled the program is not reloaded. I learned real quick after I did a change that involved 40 rungs and it got wiped out after a brown out. Luckily I had the saved version on my laptop, but it still wiped out a bunch of relevant production data.

[Bruce99]

Not sure if this will help but I would save a sample of the encoder readings... say 50 tags... then transfer them at a regular interval to HMI tags or some other external source. (I would use DDE Rslinx Pro with Excel. Im not sure if the tag values are retained in Rsview) After a power cycle restore the last value. ( a programmed Macro will be required here). If there is a possible movement problem, then, after a power cycle, drive the positioners to the last position value after it is restored. I am sure there are tags that retain the last value in RSview. If this is true, then after the PLC is up and running transfer the last values into the PLC tags and drive the positioner to that last known value using the encoder as a feed back for reference. Problem... sometimes this is not possible for safety reasons. Problem 2 .. The PLC isnt the contol for the prime mover driving the device. You should not have to write any special code to write values to the processor with RSview. Once Polling is restored the values should be restored to the PLC if the right tags are used. I havnt used RSview for 5 years so I could be out to lunch here. Correct me if Im wrong.. This sounds like an intersting project.. Good luck..

[OkiePC]

What you need to have is a homing cycle. Move the rack to a limit switch and stuff a known value in there. Require that the operator home the thing before it is allowed to operate automatically.

If you don't home an incremental axis following power up, you can't be sure the axis hasn't moved.

Any other approach will leave you open to problems following power outages. These problem could simply be an axis that is "out of time" with the rest of the controls, or even safety issues and machine damage if there are no overtravel limits.

I like to use an existing overtravel limit for homing and not add extra devices to the machine.

JMHO
Paul

[Money4Nothing]

Thanks for the replys everyone.
Maybe I should have been more specific about the application. I am controlling leg elevating motors on a 3-leg offshore jackup oil rig to be deployed in the Persian Gulf in a few months. The encoders are on a leg motor, and basically tell me how high the rig is on its legs.

Originally Posted by Gerry

non-volatile memory on a L55?? - are you sure?
how will you know the encoder hasn't moved while power is off?
get the auxiliary battery option for the processor.

I have an M23 memory board, which contains a Non-Volatile EEPROM. I know that the encoder has not moved while the power is off, becuase the motors cannot start without the PLC to control them I cannot use a battery because the PLC will be un-powered for long periods of time (as in weeks or months....the PLC is only powered up when the rig needs to jack up or down), and the batteries will drain and continuously need to be replaced. There will not be PLC-savvy technical staff on-board the rig, and I don't need them to have to continuously monitor and replace batteries. In fact, I won't even have the batteries installed.

Reload from EEPROM on power up is the only option. I don't want to fly out to Saudi Arabia every time they need the project loaded into the controller to reset everything.

Bruce your suggestion is very good but I already have the system commissioned using RSLinx Lite. I think in my case its too late to implement a DDE solution (I have about 10 days to be up and running). I really want to do this without purchasing additional software or hardware. I want to find a solution using my current resources.

I have a sinking feeling that I won't be able to retain the value in RSView My backup plan is to purchase some 3rd party counters that have their own non-volatile memory, and let them interface between my encoders and my control system. But this will require addittional hardware and will cost me money on installation re-work.

Thanks again

$

[jstolaruk]

Originally Posted by Money4Nothing

Thanks for the replys everyone.
Maybe I should have been more specific about the application. I am controlling leg elevating motors on a 3-leg offshore jackup oil rig to be deployed in the Persian Gulf in a few months. The encoders are on a leg motor, and basically tell me how high the rig is on its legs.



I have an M23 memory board, which contains a Non-Volatile EEPROM. I know that the encoder has not moved while the power is off, becuase the motors cannot start without the PLC to control them I cannot use a battery because the PLC will be un-powered for long periods of time (as in weeks or months....the PLC is only powered up when the rig needs to jack up or down), and the batteries will drain and continuously need to be replaced. There will not be PLC-savvy technical staff on-board the rig, and I don't need them to have to continuously monitor and replace batteries. In fact, I won't even have the batteries installed.

Reload from EEPROM on power up is the only option. I don't want to fly out to Saudi Arabia every time they need the project loaded into the controller to reset everything.

Bruce your suggestion is very good but I already have the system commissioned using RSLinx Lite. I think in my case its too late to implement a DDE solution (I have about 10 days to be up and running). I really want to do this without purchasing additional software or hardware. I want to find a solution using my current resources.

I have a sinking feeling that I won't be able to retain the value in RSView My backup plan is to purchase some 3rd party counters that have their own non-volatile memory, and let them interface between my encoders and my control system. But this will require addittional hardware and will cost me money on installation re-work.

Thanks again

$

Your situation is quite clear now. Can there be a procedure implemented that the rig personal records the encoder readings (on paper) and when they power-up some months later that the encoder readings are verified and/or re-established if they don't match. This would require you to have tags available that could be basically an encoder offset that could be adjusted if the old and new readings don't match. Based on your description, this doesn't seem like it would be a burden to the customer.

[Money4Nothing]

Originally Posted by jstolaruk

Your situation is quite clear now. Can there be a procedure implemented that the rig personal records the encoder readings (on paper) and when they power-up some months later that the encoder readings are verified and/or re-established if they don't match. This would require you to have tags available that could be basically an encoder offset that could be adjusted if the old and new readings don't match. Based on your description, this doesn't seem like it would be a burden to the customer.

Thanks for the reply.

I have given the operators the ability to reset the encoder values with the current leg depth with a very simple prodedure on the HMI. However, the customer has requested that I provide this for calibration purposes only; they want the count retained on power up. Your suggestion was one of my first suggestions to the customer as well, but they shot it down

I haven't given up yet

$

[nswu1]

Ive ran into a problem close to what you have a few years back on a jack up barge. What I did to correct it loseing its place was wired the incremental encoders to remain powered all times. I also added radars(laser) on each leg as a back up.using height of deck to top of leg then sending analog ouput back to plc. I'll check around and see if I have any documentation or logic around anymore,it's been about 7 years since retrofit,and two hurricanes.

[OkiePC]

Ah...that's entirely different. Can't HOME the rig or you might drown somebody! Sounds like a perfect application for an absolute encoder. Probably not an option either right? Battery backup can be unreliable.

So my solution is to use an HMI tag. I have an HMI tag whose source is the controller tag with the encoder's "Current Count" value. When the PLC shuts down, the HMI tag should retain its value (I am hoping). So I write a macro in the HMI, which executes when the minor fault code from the PLC is issued which indicates a project load from non-volatile memory. The macro sets the value of the 1734-IK "Preset Value" tag to the value of the HMI tag which hopefully has the last known encoder count. Then the macro further issues commands to inhibit the 1734-IK and reset its current count value to the preset value that I just loaded. Then viola, the Current Count is the same as just before the PLC was powered down.

My experience is limited to RSView32 and panelviews. With panelviews it depends on how you are communicating how to accomplish this. With both it may be necessary to set a property in the tag database to cause the tag to be kept in it's current state when the application starts instead of reloading the tag start up value.

Hope this helps...

Another thing comes to mind: an auxilliary battery backup that should last for months unpowered. I think AB has one on the market and it should be possible to build a rechargable one. We used to use 6V motorcycle batteries on our old ISSC controllers...

[jstolaruk]

Maybe a little cheesy but how about a memory card read-writer that could be communicated to via CPU's serial port? something like this:

http://www.securetech-corp.com/mcr35v2.html



EDIT: actually I thought you could write with that. I was thinking along the lines of a SD or COMPACTFLASH device via RS232.

[jstolaruk]

Actually something like this:
http://www.star.net/people/~mvs/sdrvspec.txt

You've got a unique problem w/o a PC handy.

[Money4Nothing]

Originally Posted by OkiePC

Ah...that's entirely different. Can't HOME the rig or you might drown somebody! Sounds like a perfect application for an absolute encoder. Probably not an option either right? Battery backup can be unreliable.

You're 100% right, we should be using an absolute encoder. Unfortunately I didn't come into this project in a position to specify that. However, on all future constructions, its my plan to specify and insist on absolute encoders. I'm not in favor of any battery backup plan. The PLC needs to be maintenance free.

[lennox741]

Not sure if you still needed a work-around for this, but I had to work out something very similar to your situation. Let me know if you still need the help.