WeakSauce

MrPLC Member
  • Content count

    3
  • Joined

  • Last visited

Community Reputation

0 Neutral

About WeakSauce

  • Rank
    Hi, I am New!
  • Birthday 10/26/81

Profile Information

  • Gender Male
  • Country United States
  1. PID

    an averaging filter is just an average of the last x samples where x is some number back. a low pass filter is just another name for the broader style of filters. Low pass means that only low frequency events get through. An averaging filter will weather a few high noise values by considering the values that it was at and taking a "vote" from all of them. That is a very simple way to do it but it's actually not going to work as written(I actually did that approach first but my incoming data was too noisy for this approach to work well). The proper formula for a two sample weighted average is going to be(using your nomenclature plus UV is updated value that becomes FV in the next time step) UV = (1-c)*FV + c*NV. You could do this for n values of history and weight them all different or some less and others more if you wanted to do a weighted average. but all the coefficients must add up to 1 or you will have a tough time getting an actual correct answer out of the system. If you want to learn more about that you can find it in all it's nitty gritty in a linear signals and systems book or a digital signal processing book. Edit: the concept here is IIR filters where the output is dependent on the recent output of the system as well as the input signal history. These tend to be less stable than a FIR filter which is one that depends only on the input signal because errors in the precision of multiplication on a PLC/computer will cause large errors in the output over time. A simple averaging filter is one that does not exhibit this behavior because there is only "clean" signals coming in and they don't recursively multiply themselves and cause output errors to accumulate. The approach that worked well for me was just a basic average function with around 100 samples. basically take an array of input values of length N and add them all up together and then divide by N to get the average value of the window of N. You slide the window as you go and things are all good it just removes the gaussian(or bell curve or normal curve) noise from the system. If the signal is actually changing very fast you should choose the number of samples to be smaller. Play around with the number of samples and you will see the difference in response time for fast changes in the value of the instrument. You are using compact logix so rslogix 5000 programming. There is an average that you can use right out of the box. you just give it an array and tell it how many samples to use. (it might even do weighted averages too if you are able to pass in a coefficient array as well but I don't know.) Good luck. Hope this helps!
  2. PID

    I would do a simple low pass or averaging filter on the input to the PLC. It will really smooth out the results but still be very accurate and fast as the scans are usually very fast and you can adjust the window size to be whatever you need. I had a terrible input from a weight transmitter that was fixed this way.
  3. There are a couple benefits to using stored procedures. They are compiled so they are faster after the first execution. (probably not too big a deal in the PLC arena.) They parameterize all variables that you pass into a procedure.(this helps mitigate against SQL injection attacks. Again, probably not too big a deal in the plc arena but it could be.) They also make things a little more secure with the credentials. you can just give a user the permission to run a stored proc and then if the username and password are stolen from the application there is less of a vulnerability. The user can only run the procedures that they are granted access to. They still can do damage but you know the full extent of the damage. For example, you have a salary table with hours worked as a column, that you join to a username table. You could create a proc that just queries how many hours were worked and relate that to a user. If you were doing this without procs, then the user would need select access on the salary table which if the username and password were stolen would let the person figure out how much everyone else is making.