Speed, Tension & Dewpoint - Data Collection Inquiry

[ZestyMozzarella]

Hi everyone, got a Siemens S7-1200 collecting data off one our furnace lines. I'm getting some interesting activity I'm working on cleaning up in our data collection. I was wanting to discuss what I'm seeing and whether anyone else has some thoughts to add to my ideas.

My first of two topics would be dew point collected and seen here:



Been collecting a 4-20mA signal from a hydrogen analyzer. This signal in a cyclical fashion seems to have a spike every so often. Doesn't appear to be happening at the LED screen and meter of the unit itself but it's recording in real time in the PLC which then sends over to IBA (a historical data collection unit). This could be happening in the PLC or the IBA data translation but usually in the past, it always come down to actually happening in the signal. Has anyone else ever witnessed such cyclical actions in signal collection and have any advice at what the culprit might be? Lines are shielded and ground attached, so I suspect it's not noise. I could establish a MAVG I suppose but as always, there is a fine line between MAVG and actual real time responsiveness that has to be respected. I'm asking the Analyzer company as well but figure individuals here may have run into similar issues and have some good perspective / advice on the matter.

My other issue is in speed collection seen here:



The speed on one tube collecting off a high resolution digital encoder via modbus TCP/IP appears to have a lot of noise at the start of a run but then mellows out. I do have an averaging function with a window size of about twenty, but that window would fill far faster than the time this takes to settle. Chain slip, tension issues, bridle issues...a lot of things can be ruled out because it doesn't happen once running after the first few minutes. I'm wondering if I'm seeing some noise in the motor circuit itself, the drives produced coming up to speed but the noise lasts for a little while before tapering off which I find odd since it's not abrupt like I would expect. Perhaps my resolution is too high...I'm thinking about lowering it since it's like a few thousand PPR and likely overkill on their defaults...collect some more data and see but curious if this speed trend sparks any obvious insight from other individuals in the field.

The signals on mA are set to (weak cycle) for smoothing as well...I've considering upping these a little to perhaps handle some noise but I need to respect real time circuit sensitivity to actual change as well.

As always thank you and appreciate everyone's perspective and feedback!

 

[drbitboy]

Dewpoint: Something is happening at 35minutes past the hour, exactly at one-hour intervals; it's hard to imagine this is random, like it's hard for Sonarman Jonesy in Hunt for Red October to think the sped-up recording of the "quiet" sub is a natural phenomenon. You say it's properly grounded so it's not electrical noise, and I have no reason to doubt you, but as sure as God made little green apples, somewhere in that plant something is happening every 3600s to cause that. At least it's easy to know when to set up trend to get some higher time resolution data to characterize the spike's dynamics. Think about the process: perhaps there is a door opening or an unrelated sample being taken or a purge or blowdown starting that affects the actual reading, and there is nothing wrong with the instrument.

You could also filter out such data using a thing called a "<something*>-resistant mean" algorithm, that recursively performs statistical analysis on the past N samples, then remove samples that are "anomalous" based on some criterion (e.g. more than 2.5σ above the mean and/or trend; you can do "above" because you know ). But such a filter is a kludge; better to characterize the spike and find the real reason, and apply a better filter (e.g. don't take data between :34 and :36 every hour).

* I forget the name, but we used it for some spikey spacecraft data a couple of decades ago.

 

[drbitboy]

Tube speed: what is controlling the speed? How was that controller tuned? Could mis-tuning be introducing the noise? Are there tuning parameters that can be changed?

 

[ZestyMozzarella]

That is what's tough about the speed. It's just an AMCI digital encoder that my Siemens 1200 Modbus TCP/IP command samples every one second then goes through a 10 sample averaging LGF function for just additional smoothing purposes. The encoder sits on a rubber bridle that is controlled by old Ratiotrol DC drives to a DC Motor (180VDC).

It's just odd because I don't see obstruction to the bridle or odd movement and even in data it's not abrupt...it's lasting 45 minutes before settling...not abrupt like you would think from tension issues, jerks in the line or bridle...very odd oscillation to eventually settling. Doesn't happen on the far bridle either and they're side by side. Going to look at PPR and encoder settings to make sure they're identical and no odd settings are present within them. It's a long period of time with no visible sign in the line that I have witnessed...if settings are the same, perhaps I need to replace the encoder.

It also made me think about noise in drives or signals with motor where noise from the motor and circuit itself has to be grounded at the casing sometimes...was making me wonder if I actually should try attaching a ground cable to the case of the encoder...perhaps? Don't think I should have to but the thought did cross my mind as an experiment.

 

[ZestyMozzarella]

Some updates for future observers on these issues:

For dewpoint, I tried moving the input cycles from weak (4 cycles) to medium (16 cycles). This noticeably cut the noise by about 50%. I watched the Hydrogen Analyzer for about an hour as the spikes were happening every 45 minutes. Figured maybe a pump, switching power supply or something was causing it. I couldn't find anything in the circuit as a culprit. Each side of the shield was grounded properly. As such, I started thinking about other processes in the building and I was reminded of another circuit I built 5 years ago in the past for another department where I took a 4-20mA signal and converted it to 10VDC for a National Instruments board signal. I recall in the design, I used filtering caps to keep the signal clean...well...you know what filtering caps are good for? Filtering! I stuck a 63V 100uF capacitor across the proper orientation of my S7-1215C Siemens PLC analog input and wahlah! I beautiful smooth curve, no noise and all the live fluctuation of real time change still intact from the analyzer (good sensitivity). No more spikes!

For the speed, we tested both drives without any material present on the line, so just encoders reading feedback on their respective bridles rotating. This means no tension or takeups are involved...nothing mechanically beyond the rolls affecting speed. Sure enough...no spikes are present in the speed so we know the Maxcess tension system or something about the takeups whether it be tension problems, chain slip, load issues or what...is causing these oscillations in the speed reading at the start of runs. This also probably eludes to diameter of the takeup and weight load having an impact on the aggressive start and eventually tapering off, so the line mechanically definitely needs to be looked at. At least we know the encoders are good and the PLC reads properly!

Appreciate the feedback and confirming some suspicions. Always good to leave the resolution for future readers! Onward to the next problem of which there are many...always heh. No lack of amusement in manufacturing!

 

[MaxK]

One silly question:
Why are you filtering the signal?
What do you want to achieve in the end?

 

[drbitboy]

[late to the party, and the problem is solved anyway]


It's nice that the filtering cap worked, but the source of the dewpoint spike is still a mystery.

... Each side of the shield was grounded properly. ...

I am no expert, and I am not sure what is meant by "side of the shield," but I think most folks here recommend grounding only one end (side?) of a cable shield.