PID Loop Issue

[Evilbeard]

Evilbeard, I can't tell what your traces are supposed to represent in that shot as there are no legends and no y scales visible.

My first thought is you maybe have something wrong in your diameter calculation - not the math, but the update speed. If your web is thin it runs fine, but if thicker it gets behind. Are you counting spindle revs and multiplying by film thickness or footage by thickness to get area, adding core area and then getting the diameter or...? If you don't update the spindle ref from diameter build fast enough you will get behind. Thicker film can be a much faster build rate. It looks like you are incrementing about once a second unless that is just your trend sample rate (I don't recall if you can set that and it is late, late after a very long day. Any chance your diameter checks after stopping but you didn't really get the info to the drive fast enough while running? Build at core should be faster, but ramping to speed can reduce that early build rate?

Mike, the picture is so large that it scrolls to the right. You can see the y scale on the right. I'm calculating diameter using the area method. I'm doing it with a few simple math boxes, and it's performed on every scan. The incrementing you see is the acceleration of the line, I update the speed every second with my little deltas I calculate in the accel/decel subroutine.

as far as the traces go, they are as follows.

Top Pane

White - Dancer Position
Red - Dancer Setpoint (this is actually inaccurate in this trend, I had manually set it to 42, this is displaying the memory location value, MY BAD)
Aqua - PID Output
Yellow - Roll Diameter

Bottom Pane

Red - Secondary Speed (on a scale of 0-100%)
Yellow - Base Speed Reference to the Rewind (this is the calculated speed I use before it's trimmed)
Aqua - Speed Reference to the Rewind (after being trimmed and combined with the PID output)

Evilbeard -- your dancer position instability seems to cause, rather than result from, the CV oscillation.  If so, that would imply there's still some issues in the process.

Also, in the middle part of the trend, the PID output is dead flat, when it should be trying to reset.  Since DM PID is dependent, increasing either P or I should make it more aggressive.

I'd still be interested to see what P-only would do, but you're going to need a stable process for that.  I will tolerate transient instability better.

I apologize. The red line in the top pane is inaccurate. It was looking at the vmemory location of the dancer setpoint, but I had overridden it and set it to 42 manually. It should be down in the middle of the PID output there. It's misleading. I'll try to get you guys actual trends with accurate data when I return to my computer in an hour or so.

[Mike Nash]

I missed the image getting whacked (old eyes and zoomed in too much.) Change trend time divs to match the seconds will help too.

Unless something is loose, the dancer swing looks like too much integral action. Big slow swings getting progressively worse. Proportional gains too high usually have a higher swing frequency. But as Controls Guy says, increasing the gain also increases the integral action so I would want to go up on Gain but increase the Reset value (longer time, slower response.)

So after playing with the simulator, I am having trouble getting anything that looks real similar to your trends. I have a diameter calculator that comes into play though and it can contribute to instability.

However, this once a second reference update thing... does this include with the trim, i.e. you only change the reference once a second period? I can get real ugly looking stuff trying to emulate that.

[Evilbeard]

In further investigation, it shows the PLC was slowing the drive down. The yellow line trending down shows the Base Speed on a slow decline. We found that we were having more communication issues. The drive was getting down to 17.0Hz and just sticking there. It wasn't going any further, despite the PLC showing that it was sending smaller numbers. I've wired the speed reference to the rewind to be analog from an analog output.

However, I'm having some more issues. My analog seems to have lost its mind. The dancer, despite being scaled to 0-4095 (12 bit), jumps to like 15000+, and is showing up as erratic. If I go and move the dancer by hand, it showed a smooth curve from 0-4095. I moved it from one input to another, same thing. I changed the scaling to 14 bit, cycled the PLC from run to program and back, and then it showed me 0-4095. I put it back to 12 bit, and I'm getting negative raw numbers. Putting a meter on the input, I never see negative numbers. It's even hooked to a programmable signal conditioner that only puts out 0-10V, so I'm having hard time believing that it's the physical input.

What could be causing me this issue? Anyone have any ideas?

[Mike Nash]

I can't get into DMD right now, but try viewing the analog input cast as unsigned. WX0:U for example.

You didn't mention which card you are using.

[Evilbeard]

I'm using an f2-8AD4DA-2.

[Mike Nash]

I read it as the only resolution needing the unsigned is 16 bit. I don't know what is happening on your issue.

[Controls Guy]

If it were a 4-20ma AI, they set the MSB on open circuit, which then looks negative and large magnitude, so it could be a loose wire, but I don't see how that can happen with 0-10V.

[Evilbeard]

I think it's noise. After running the analog output wire to the drive, the analog card has been acting super wonky, though. I removed the output wires to the drive completely. I started pulling analog inputs off one by one to see if they were causing the issue. When I was putting one back on, I noticed it's output changed. Multiple of my input were scaled wrong, as they were changed from 12-bit to 14-bit. Nothing I could do would change the raw number I saw on WX1 and WX2. I just ended up having to change my program to scale to 14 bit instead. *shrug*  I even had WX2 display a raw number in program mode, and then go immediately to 0 and not change at all when the PLC was in Run. I verified with a meter than it has 1.10VDC on it. I searched the program for all instances of WX2, and there was only one, my scaling function for display on the operator panel.  I just don't know. I ended up moving it to another input and it works just fine now.

I made sure all the unused inputs were jumpered together and they were tied to DC common. I pulled a new wire from the signal conditioner (it takes the potentiometer on the dancer and converts it to 0-10V and I've verified it's working properly) all the way to the analog card. I made sure to route it around any power wiring to eliminate noise and terminated the shield on ground. Nothing seems to help this. Something to do with the drives/motors has to be causing the noise. I don't get the issue with the dancer input when they aren't running. I just don't know what else to look into.

Here's a link to the short data set I could get. The first one is the one I started with (the dancer creeping problem) and the second one is the dancer input issue. 0% dancer is film slack. 100% dancer is the short accumulation on the dancer.

[ADC Product Engineer]

Just to throw this out there.  Using analog voltage signals with drives is rarely a good idea.   4-20ma signals are incredibly more noise immune and less likely to cause these sorts of issues.

[Controls Guy]

I second what ADC PE says about ma vs. voltage signals.  I always default to ma over voltage for any app, unless the instrument is simply unavailable in ma.

Back in the old days, you might use voltage to transmit a speed or torque setpoint to a drive designed to take one from a pot with no process input per se, but even then you could do the same with a 0-20ma signal and a shunt resistor, which would be preferred.

Even if I were hooking up to a pot-only input today with only a 4-20ma signal output available (no 0-20ma IOW), I'd still put a signal isolator next to the drive and do 4-20 for the whole distance and 0-10 or +/10 just the last foot.

[Evilbeard]

We isolated the noise, and found that it was coming from the Ethernet that I set up to control the EDRVs. If you started the drives with the keypad, the dancer was clear of noise. If you started the line with the EDRVs using the Ethernet, it was noisy. I used today to wire up all the drives to analog speed references and discrete operation command. The dancer noise issue was eliminated. I don't know why it would be in the Ethernet. I had a Stride switch, which was grounded (at the power lug as well as the case) and going to the Ethernet port on the DoMore CPU, I wouldnt' think it would create that much noise.

[Evilbeard]

Once I got the noise out of the system, everything went swimmingly. I tuned the loops a little, and got everything working. I had to make a few tweaks in going from the EDRVs to analog signals, but otherwise, it was smooth sailing today. Here's what it looks like running production at 425 FPM.



I just wanted to thank everyone for their help and patience. It's been a learning experience, and the next time I tackle a project, I think it'll go much smoother.

[Controls Guy]

Awesome!  Glad you got it working good.   

Nice video too.