Encoder retention when power failure

Hello friends,

I am using Omron CP1E-N60DT1-D PLC with Pepperl Fuchs tvi50n rotary encoder 1000ppr. In CX-programmer 9.03.I need help for encoder value retention when power get fail.

I am able to count encoder values using PRV instruction on DM100 and can see values at A270 and A271.Encoder should move in both direction F/W and REV. Can you suggest me logic for encoder retention or any alternative encoder which will be configure with same PLC.

Thanks in advance

Instead of writing incremental encoder "supervisory" code (I've seen it done though!...) why not use a dedicated, EEPROM containing device, such as an absolute, multiturn encoder?
http://www.pepperl-fuchs.com/global/en/classid_363.htm

Is it a velocity or positioning application?
If it is just positioning, might as well pitch the incremental type feedback and use an absolute one; if you need velocity and positioning, use both type encoders identically "timed" within the system; your CPU controller has two pulse+direction on-board high speed counters (100kHz); one could be used for the incremantal device and the second one for the absolute encoder.
Power loss will not afect an absolute encoder's values since they are continuously written to the internal, non-volatile memory.

dmargineau said:

Instead of writing incremental encoder "supervisory" code (I've seen it done though!...) why not use a dedicated, EEPROM containing device, such as an absolute, multiturn encoder?
http://www.pepperl-fuchs.com/global/en/classid_363.htm

Is it a velocity or positioning application?
If it is just positioning, might as well pitch the incremental type feedback and use an absolute one; if you need velocity and positioning, use both type encoders identically "timed" within the system; your CPU controller has two pulse+direction on-board high speed counters (100kHz); one could be used for the incremantal device and the second one for the absolute encoder.
Power loss will not afect an absolute encoder's values since they are continuously written to the internal, non-volatile memory.

Click to expand...

Hi,

It is a Positioning application.Since, our customer has already purchased an Incremental encoder we cannot change it.

Your customer should avoid trying to reinvent the wheel....
Incremental encoders are used for velocity feedback applications and absolute encoders are used for feedback in positioning applications; they've chosen the wrong type of feedback and you should suggest the proper implementation.
You could continuously write the value of the incremental encoder driven counter to a non-volatile CPU memory address, however, I wouldn't expect any minimal data accuracy at power loss time since the system will most likely "slip" when de-energized.
Your customer will also have to create some sort of "Home Flag" (via additional field installed input devices)and manually or programmatically move the system to that position after the power failure; the commencement of the incremental encoder's values monitoring needs a precise position reference which will substantially increase the costs when compared to a simple encoder type replacement.
However, this is just my own opinion...

Can you suggest me ladder logic code for retention of encoder value by using same encoder even though power get failed??

Gibson:
Your customer should avoid trying to reinvent the wheel....and you should do the same.
Even if you have a copy of your position in your program, when power fails you never know what was the last position of your system.
An absolute encoder is the solution.

Hi

Could not agree more the answer is an absoulte encoder. I understand this is not the answer you want and that your costumer has bought the wrong type for the job, but two wrongs do not make a right. You are the programmer not the costumer and they will not thank you for given them a system that does not work right and it will be the programmer that is wrong in there eyes and nit the encoder.

Sometimes costumers are not always right

Donnchadh

Agree with all the above, there's really no "safe" way to do at all,
You could write logic around if encoder = 0 and not at home position then load last value and constantly move a valve into retentive memory bit but i wouldn't it's too unsafe for me.
The issue with that is slip or rollback if there's a brake failure before power down and depending on how you're code is written there's a huge possibility of slamming into either end of you're run and causing damage to the machine or anyone around.

Better idea is if encoder = 0 and not at home then they have to manually drive the VSD to the home position at something like 5hz and rezero.

as per MatsterAu
the cheap and nasty way of positioning is to use this type of encoder.
it can be quite accurate --- BUT ---
it must be returned to a HOME position - this can be quick if you allow for stopping by PE, PROX or Micro rather than attempting to rely on the encoder.
this was common practice about 20 years ago - a lot cheaper than Absolute encoders.
the trick is to home the encoder then count out to the set point.
use a slowdown point also if you so desire.
this is repeatable and reliable - provided the Home Position does not move. You normally need a configuration mark -
return to home move forward 100mm measure the diference and set the BIAS.