Saving and Retrieving High Speed Counter Values

Hi guys,

I'm wondering if this is possible. I have a machine with two different 3600 count encoders wired into a 1771-VHSC plugged into a PLC 5/40e processor. First encoder is for "machine position" and it goes to counter 1 on the VHSC. The rollover point is 3599 counts, but there is also a shaft-mounted flag and a prox which "resets" the count every machine cycle. The second encoder monitors a turret which makes a complete cycle every 6 machine cycles. It goes to counter 2 on the card and it also has a flag and a rollover point of 3599 counts. The values for the card are BTR'd into two separate integers for each value, a MSD and LSD, so for instance 3516 counts or 351.6 degrees would be read as MSD 3 and LSD 516 at N7:103 and 104 respectively.

We have issues with this machine on power outages or maintenance shutdowns if the machine is not brought to the "zero" position of both encoders before power is turned off or lost, because both encoder values will zero wherever the machine happens to be whenever power is cycled, so we have timing issues until both encoder flags come around and reset everything.

What I'm wanting to do is move the values for each encoder into "safe storage" integer values continuously while machine is running. Then use a first pass bit to move the stored values back into the BTR destinations for the counter values. Would this work, or would the stored values be overwritten by a "zero" value from the encoders on power-up? I was hoping someone here had done something similar so I would have an idea if this could work before I implemented it on the machine.

Thanks for reading and replying!

Cheers,
Dustin

I am not sure this would help you, because I assume the rotating masses would coast to a stop after the power loss. So, they will not be in the position they were when you captured the Encoder Values. Maybe some code to creep the sections back to a home position?

Stu....

What I'm wanting to do is move the values for each encoder into "safe storage"

Click to expand...

Really dont know but I would think add to not move to. Its somthing to think about?

I think your only chance would be to add an offset between the encoder values and the rest of the logic. Stash the encoder values into a storage register every time the /DN bit for the BTR goes true.

The 1771-VHSC is definitely going to have zero values after a power cycle of the chassis it's hosted in.

If it's truly a "power loss" situation, your odds of success are low. If the power is turned off after the machine is stopped, this approach might work.

I am not sure this would help you, because I assume the rotating masses would coast to a stop after the power loss

Click to expand...

A ups could solve this?

sthompson said:

I am not sure this would help you, because I assume the rotating masses would coast to a stop after the power loss. So, they will not be in the position they were when you captured the Encoder Values. Maybe some code to creep the sections back to a home position?

Stu....

Click to expand...

Actually the machine has air over hydraulic "fail-safe" brakes, so it won't go far. Power losses are fairly rare in any case. It's being able to lock the machine out without a LOT of jogging that I'm worried about. To get the turret around to home position at a "creep" speed could possibly take upwards of 15 minutes. As far as power outages, I'd be be ok with values that were possibly 3-5 degrees off rather than half a cycle off. It can really cause a lot of headches for both techs and operators.

Ok, if the stopping point is fairly consistent, Ken's suggestion might be the way to go. Capture the Encoder Values, then add a known offset for the stop distance to it, then write it back at power up. Obviously, there will be more to it than that, making sure this is done before things are allowed to move etc. However, you know the machine, and we don't.

Stu...

Stu, Ken,

So are you guys saying that the VHSC will "allow" a MOV or an ADD of the stored values, supposing that the execution occurred before the first scan of the BTR?

The BTR is actually the first rung of Ladder 2, so I could put the XIC S:1/15 then MOV instruction first before the BTR, then the next rung after have an XIC BTR/DN move the encoder values to the storage register(s). Does that sound viable?

I will bow to Ken's greater knowledge on this. I haven't used the 1771-VHSC, or looked at the Manual. However, I would think if you write the Value to the VHSC Card Registers, it would start with that Value.

Stu....

bce123 said:

A ups could solve this?

Click to expand...

"ups"?

Hmmm...after reading the manual a bit, I'm wondering if I will have to use the BTW to the VHSC on the first scan and write the stored encoder values to the proper counter presets, then have the presets go back to zero when the rollover bit(s) or gate reset(s) go high.

I'll have to play around with this a bit.

Thanks for the help guys, good stuff.

Cheers,
Dustin

Let us know how it works out.

Stu....

ups.....Uninterruptable power supply. If you have power to the encoder and plc, If only for a minute this could solve the problem of drift at mains power loss. Also I belive an absolute encoder would fix this. I have an upcoming encoder project I will try and test your logic on next week when I get the hardware in as I belive it is sound in theory.
Best regards, Steve

sthompson said:

Let us know how it works out.

Stu....

Click to expand...

Well I finally got access to the machine and a few minutes downtime to download a new program, and I'm happy to say that the program works exactly as intended, the encoder values come right back up after a loss of power.

I set-up an 8-slot rack on the bench with a VHSC card on it and hooked an encoder up to it and played around with it until I got it to work.
Attached is a copy of the .RSP file that I used on the bench before incorporating the changes on the running program, in case the screen shots are hard to read.
I originally tried to use the New Data bits in the BTR data file to OTU the preset enable and clear the preset values, but the processor never did see a true condition of that bit. I think that has something to do with the BTW New Data Ack bit resetting the New Data bit before the processor has time to scan it as true. In any case, I was able to just substitute the GRT instruction, which works just fine.
Thanks again for all the help and advice on the project.

Cheers,
Dustin