Learning by Doing

[elevmike]

Arik,

that's what I suspected also, but havent had a lot of time to dig into it yet. Real busy with my own stuff right now. I'm just about to leave so let me get back to you on that..

 

[pstephens]

I thought this as a hollow shaft encoder?? If I'm correct the encoder is mounted on the idler shaft and teathered to the machine. The idler is applied to the wire via an punematic piston.

That's correct -- it's a hollow-shaft. See post #391 for details of the mounting configuration (2nd and 4th pictures). The idler is applied to the wire with a spring-loaded ball bearing. The idler is engaged whether the pressure rolls are on or not.

With regard to mounting with rubber grommets, if you have ever held one of these encoders in your hand, you would see how flexible the mounting springs are. Grommets would not substantially reduce shock transmission thru the mounting screws.

 

[pstephens]

After I review Paulas code I think the problem is with the high speed counter setup and the way the code was written.

So far, there doesn't seem to be a meeting of the minds on the counter setup, even from AD Tech Support. Arik, in your first email you said "What I have found you set your HSC to incremental mode it should be absolute." Then later on you said "...in the way you wrote the program it is not important if it incremental mod or absolute mode." Now you are still saying that the counter is setup wrong. You also keep insisting that "You must reset the counter evry cycle", when I keep explaining why it is not being reset each cycle, and even pointed you to specific posts in this thread where this was discussed, but you never addressed the issue any further.

You also said, "in rung 4 the counting will start with 10 pulses (that what you want?)". The anti-rollback provision was discussed extensively on this thread, and is also explained in the program comments.

Also, since replacing the encoder "solved" the problem, are you guys implying that having the incorrect setup code for V7634 can physically damage the encoder?

 

[Unregistered]

encoder problem

I don't know AD PLCs, but, it is absolutetly impossible that the setup (which only affects how signals are treated logically) damages the encoder in any way.

From drawings of and by disassembling similar encoders, I found frequently a disc of some film-like material carrying a sequence of black and translucent stripes. Thes marks are read by an assembly of a light source and light sensitive devices, e.g. photo diodes.
Now, if the shaft leans to one side, the disk mounted at it's end either gets out of the focal plane of the detectors or it touches the light detectors or other components, so they make scratches to the disc.
If the disc gets out of focal plane, the detectors may produces a "noisy" signal getting an amount of ligtht that varies around the switching threshold.
Scratches would produce additional signal changes.
Normally, the encoder should produce two signals shifted by 90 degrees. The PLC evaluates this in a way that if Input A changes from 0 to 1 while input B is 0, it counts forward, if input B is 1, it counts backward.
Mostly, it also evaluates more or all other combinations of transitions of one and corresponding state of the other signal.
So if there are extra signal changes from scratches or from light intensity changes around detector threshold, let' say on signal A, you would get:

A 0->1 while B=0: count up; this is the normal transition
A 1->0 while B=0: count down; this is faulty a transition
A 0->1 while B=0: count up; this is faulty a transition
A 1->0 while B=0: count down; this is faulty a transition
A 0->1 while B=0: count up; this is faulty a transition
B 0->1 while A=1: count up; this is the next normal transition
A 0->1 while B=1: count down; this is faulty a transition
A 1->0 while B=1: count up; this is faulty a transition
...
You see, counts from faulty transitions cancel out here. But as scratches may be much narrower than the normal spacing of marks and gaps and oscillations around the threshold may be much faster than changes from normal operation, this leads to much higher frequencies. The PLC will not be able to follow them all. Then, they cannot cancel out any more.
This may lead to the effect that your total counter, missing more "down" than "up" transitions, reaches a very high count.

 

[rsdoran]

I dont know enough to say anything about the counter setup but you know it works with a "GOOD" encoder or at least when the phase to X0 is working properly. Doesnt hurt to double check the program and see if it can be improved but I think the encoder was the problem, the fact that a new encoder worked properly more less says that. Once Icky gets the old encoder then you may get an idea of what happened. If it happens again then may want to consider a more shock resistant brand/model encoder.

Looking at the manual the shock and vibration ratings are not very high for that model, the medium duty models have the same specs.
http://web3.automationdirect.com/adc/Shopping/Catalog/Sensors_-z-_Encoders/Encoders/Light_Duty_Hollow_Shaft_(TRD-S_Series)/TRD-SH360-BD

At the xmas paper plant we had splice on the fly unwinders that didnt seem to have much of a shock factor but we had issues with the original encoders used. We ended up using BEI because of the shock/vibration rating, this manual shows a hollow shaft model: http://www.beiied.com/PDFs2/HS35_Incremental_Encoder.pdf

Of course there is a big difference in pricing, its hard to beat AD pricing.

 

[elevmike]

Also, since replacing the encoder "solved" the problem, are you guys implying that having the incorrect setup code for V7634 can physically damage the encoder?

No the setup wont damage the encoder, but it may effect the way the encoder increments the counts. As you are adding values to the data tables, you may have some unintended data "spill over", when certain data reach certain values causing very strange errors. You mentioned that there was some data values that far exceeded the known actual value. However since you've apparently zapped this data before saving it for further analysis, it's very hard to tell. I was hoping hoping hoping.. that all the accumulated values would be available for this, but it's not to be. Lack of an ocilisope to watch the encoder in action also adds to the mystery. If AD comes back to you and says the encoder is ok, then it's likely that your going to get another call from the billows-maker-guy when the accumulated data again reaches the magic values. If and/or when this happens, SAVE THE DATA!!!

You may think that you "fixed" the problem by switching the phases, but if the accumulator passes zero, the lower register will appear to be accumulating the count in reverse.

 

[pstephens]

Of course there is a big difference in pricing, its hard to beat AD pricing.

Ron,

Yes, that was one of two main reason why this machine could even be built. It was a case of either building it for what the customer could pay, or not build it at all. The other reason was that the customer found a machine designer who was willing to cut her rate to try and break into the controls ene of machine design.

I'm still quite pleased with how it turned out.

Paula

 

[pstephens]

Follow-up, and another question

Hi all,

Have been meaning to post a follow-up on the encoder issue, but things have been so busy lately (what with getting the new place ready for move-in, plus everything else), that there just hasn’t been time.

Icky checked out the encoder that I sent back to A-D. He said that it was D.O.A. (which is kind of weird, since it was "sort of" working -- although in reverse -- when I removed it from the machine). He also said that there appeared to be nothing mechanically wrong with it, and guessed that the problem may be due to a random component failure. At any rate, the machine seems to be working fine with the new encoder.

On another front, I had a discussion with Arik about the program itself. He believes that the fact that I'm not resetting the encoder's counter each cycle may be a problem, as in: when the high-speed counter’s register becomes full. I explained to him that one of the features of the control system of this machine was to keep track of accumulated material usage, and that the machine would have to process some 40,000 feet of material before the counter's limit was reached.

This was based on my understanding that CTA174/175 had a limit of 99,999,999, based on discussions with Mike, Eric, and perhaps others (see posts 188 and 598, for example). Arik maintains that this is not true, that it has a much smaller range. After doing some investigation, I see that the DL06 manual seems to confirm this.

On page 3-7, under Mode 10: High-Speed Counter, it states: “The counter counts only upwards, from 0 to 99999999.” However, on page 3-24, under Mode 20: Up/Down Counter, it states: “The up/down counter has a range from -8388608 to 8388607.”

The program is currently set up for Mode 20, since this is necessary to interface with an up/down counting Quadrature encoder. Early on, it was felt that the up/down counting feature would be needed to correct for overshooting the stop point. In actual use, this feature is never used, and I’m wondering if Mode 10 might be more appropriate, and give the higher count capacity.

Anyone have any thoughts on this?

Paula

 

[davidg68124]

Arik may have a point. You might consider resetting the HSC after every length is metered and take that amount and add it to another register for a totalizer. If I remember correctly, this is a shearing style operation, right? This approach would protect you from a rollover in the HSC logic as well.


David

 

[elevmike]

OOOPs!

Ok so the encoder wont count as high as initially presumed...So what. Stick with mode 20, (too many changes necessary and mode 10 wont allow/count mechanical rollback). It would be highly presumptious to think that your machine will never rollback or overshoot and correct.

As far as keeping track of stock: Reset the encoder/counter ONLY on startup. When the current job/run is complete, add the current encoder count to a unused Vmem that will keep track of unused/used stock. You can actually track stock indefenatly by rolling over the count into another Vmem to accumulate values higher then 99,999,999. Two Dword vmems could track stock as high as 9,999,999,999,999,999.

So I guess I was wrong about the encoder, OR it was damaged in shipping....I like to think that it was damaged in shipping..he he..

 

[elevmike]

I feel that resetting the count on each cut will result in a small totalizer error that will be accumulated for the total stock used/unused and run..etc.. this could add up to a significant value over time. I vote for resetting the encoder counter only on compleation of each job run.

 

[pstephens]

Thanks for the quick responses!

I hadn't thought of tracking the accumulated usage in a separate register. This will give me something to mull over today while I'm painting (Ughhh!)

Paula

 

[leitmotif]

Paula

Painting is good for the soul
ALSO good for getting rid of that shirt etc that still has "life" in it.

Dan Bentler

 

[elevmike]

Painting is good for the soul....

Dan,

Haven't you heard of the Agony & the Ecstasy? It's a long drawn-out terribly sad story about a guy who spent years on his back painting a ceiling, and never got paid for it...

Another painter (years later in France) kept eating his product and went nuts from lead poisioning, he then got the impression that he was hearing "voices" and hacked his own ear off.

Then even later...another guy from Austria liked to paint but then went nuts also, and started World War II over it...

I'll leave the painting to professionals....

 

[Eric Nelson]

On page 3-7, under Mode 10: High-Speed Counter, it states: “The counter counts only upwards, from 0 to 99999999.” However, on page 3-24, under Mode 20: Up/Down Counter, it states: “The up/down counter has a range from -8388608 to 8388607.”

Good to see you're checking the facts, Paula!...

I agree with Mike. Since your application has the possibility to move backwards, you really HAVE TO use an up/down counter. You don't want the PLC to INCREASE the count in BOTH directions!...

Unless the 8388607 limit won't cover your maximum counts between resets, then I'd leave everything as it is. It looks like the only 'problem' here is a defective encoder.

Thanks so much for keeping us updated!... :nodi:



-Eric

P.S. I think it will be a long time before we see another thread with phrases like "(see posts 188 and 598, for example)"...