ARRAY to send speed set point to a dosing pump. SGCR dimension limitations - best practice?

A vendor supplied a spreadsheet of gpm vs. pump speed for chemical dosing (4-20A) output.  This results in a m x n = 210 x 2 with 210 values. First thought was use a SGCR, which limits me to 21 rows.  This would require 10 SGCR, which seems excessive.  I could decrease the resolution, and simplify it as it appears to be linear, but with a slightly different slope.  Anyone able to suggest the optimal way to build an  ARRAY, either via function blocks, CALC block or just stacking SGCR's?  Thanks in advance.

  • Initial question - Do you have feedback of pump output or not? If there is feedback, this can help. If this is a manual loader, that is different.
    My initial idea would be to compare two different methods:
    1- compare the difference between using all 210 values with the 20 values of the standard SGCR block. How far is the interpolated value from the SGCR from the corresponding value given from the intermediate values. You should be able to do this comparison in MSExcel very quickly.
    2- curve fit the data from the vendor into a polynomial expression. Again, using excel, compare the values from the polynomial to the data from vendor. The polynomial might give you a better fit and you can make the parameters of the polynomial changed by tune privilege so modificaiton would not require download.
  • Rather than stack 10 SGCR for all 210 values you could stack two SGCR, one for the slope and one for the intercept for each region. Dividing the spreadsheet plot into 21 regions should minimize the error. As DBacker mentioned, you could also do a polynomial fit and use a CALC block. The CALC block (and other structured text function blocks like ACT or CND) provide access to a variety of mathematical functions, including trigonometric functions.
  • I would use ARRAY type parameters for the curve and a CALC block with a WHILE...DO loop for the conversion.
    Here is a first pass at the logic in the CALC block:

    [EDIT: I copied and pasted this directly from DeltaV, but apparently this board interprets [ I ] as a lightbulb icon...anything displayed as a lightbulb is [ I ] with no spaces between. :) ]


    I := 1;
     
    IF 'IN1.CV' < 105 THEN
    WHILE ('IN1.CV' > '^/CURVE1'[I][1]) DO
    I := I+1;
    END_WHILE;
    'OUT1.CV' := '^/CURVE1'[I][2] + ('IN1.CV'-'^/CURVE1'[I][1])/('^/CURVE1'[I+1][1]-'^/CURVE1'[I][1])*('^/CURVE1'[I+1][2]-'^/CURVE1'[I][2]);
    ELSE
    WHILE ('IN1.CV' > '^/CURVE2'[I][1]) DO
    I := I+1;
    END_WHILE;
    'OUT1.CV' := '^/CURVE2'[I][2] + ('IN1.CV'-'^/CURVE2'[I][1])/('^/CURVE2'[I+1][1]-'^/CURVE2'[I][1])*('^/CURVE2'[I+1][2]-'^/CURVE2'[I][2]);
    ENDIF;

    The ARRAY parameter type is limited to 240 total values, so for 2 columns the max is 120 rows. You will need to use two 105 x 2 arrays; I assumed parameter names of CURVE1 and CURVE 2. Then at the beginning of the expression you need an IF statement to determine if the speed (assumed to be IN1) is less than the first speed in CURVE2 (here assumed as 105). The WHILE loop increments the index looking for the first speed value that is greater than the input. The GPM (assumed to be OUT1) calculation looks nasty, but it's just the GPM value at the index plus the fractional portion of the next differential in speed times the next differential in GPM.

    You may also want to add some checks to account for negative inputs or overrange values, but I think it should work.

  • You mention that it appears to linear. I would recommend that you chart these points in excel an throw a best fit line on it, usually dosing pumps are liner and you only need to compensate for a offset Y-intercept which can be accomplished with a scaler block. If it is not linear then you probably want to use the Keep it Simple philosophy and just use a single signal characterizer block. It never fails I get this "amazing" vendor information about what they are installing, but come start-up time and it preforms differently. Tweaking a single signal characterizer block with only 21 points is pretty easy, tweaking 210 values ...
    Also it would be good to know how accurately does the product need to be added? if your application does need to have "210 points of accuracy" you probably want to scrap this control philosophy and invest in a good flow meter, mechanical wear of equipment will get you off that accuracy very quickly using just output to the pump.
  • In reply to Mike Link:

    Mike makes a great point that a single Signal Characterizer can provide a pretty accurate curve with 21 variables, and is easy to maintain. One of the features of the SGCR is that the X axis value is also variable, so you can concentrate points near the more dynamic part of the curve and use fewer points for gentle or straight portions. Plotting the curve in Excel is an excellent idea. It may be that a simple polynomial would also give you an accurate conversion, and excel will show you that. Keep in mind that an Excel polynomial will use double precision floats, while the CALC block uses 32 Bit float, and this can result in some loss of accuracy with the polynomial. Make sure you check the expression across the entire serviceable range.

    If you find you need more than 21 points, it may be better to use a couple of SGCR blocks and avoid a lot of math. This ends up being quite efficient, and easy to maintain and troubleshoot. There are a couple of ways to do this I'm sure.

    Another feature of the SGCR is the reverse look up, in case you need it, say for a back cal connection. Using more than one SGC could make this more complicated, but something to keep in mind.

    If you have 210 Y values evenly distributed across the X axis, you could use a 1 X 210 Float array, and scale the X value from 1 to 210. Then you could find the two points in the array that frame the X value, and interpolate the Y value. That would be a bit of math, but keeps all 210 values in a single Array. You would lose the back cal reverse look up feature, but you would not need to iterate through the array to find the two data points of the curve for a given value of X. Note this would not work if the data points are not equidistance.

    I would try to keep this as simple as possible and if the curve accurately plots to a single SGCR, I would use that.

    Andre Dicaire

  • In reply to Mike Link:

    In situations where I needed to use an equation to define a curve because there were too many data points; I've used an equation development software package called Eureqa Formulaize (www.nutonian.com/.../). This software has allowed me to drop my data points into excel and use their engine to develop a best-fit equation. It has worked incredibly well on linear, non-linear, and even non-continuous functions.

    If you go the route of stacking SGCR or Arrays, you can use excel to manage the data points. If you enable the OPC add-ins for excel, it can read/write data points via OPC. This allows you to set up your spreadsheet in such a way that you can push all of the data points to the module easily.
  • In reply to Bill Tinley:

    Worked like a charm, thanks for sharing this code. Exactly what I was looking for.
  • This is just a different practice. We had the same issue and after testing different solutions decided that SGCR and CALC blocks were too problematic. That solution lacks accuracy, has high software maintenance and you are not able to changed the pump curve on the fly. Pumps really have a family of flow curves. Our solution was to run your spreadsheet through your favorite curve fitting program and generate a function. We created a custom function block using only the built in math blocks to get the best performance.