Re: [foxboro] Storing many values

Some people would call this a recipe management application, but you could have 
a script make om calls and store the values in a file (pass a new file name to 
the script for each new grade). Use another script to write the setpopints for 
a grade before you batch.
 
You could also use a spreadsheet whose cells contain the same om calls. Run the 
spreadsheet after each batch and store the values.
 
If you are keen on database applications  ... well, if you can do the 
spreadsheet, you can do a database. You might even capture the setpoints with 
the historian and take a snapshot of them at the end of a batch.
 
There is software you can buy, but it doesn't sound like you have a budget of 
$K+.
 
*K

        -----Original Message----- 
        From: David Johnson [mailto:DRJohn@xxxxxxxxxx] 
        Sent: Thu 6/30/2005 6:45 PM 
        To: Foxboro@xxxxxxxxxxxxx 
        Cc: 
        Subject: [foxboro] Storing many values
        
        

        Hello all,
        
        I have been asked to allow the operators to store a group of setpoints 
for
        a particular grade.  Something along the lines of "everything is running
        just right, next time we run grade X let's use these setpoints".  No
        problem with that, but where do you store the data?  It needs to be
        captured on CP upload and be there whenever a save-all is restored, the 
CP
        reboots, etc.  There are 3 setpoints for control loops and 30 grades.  
So I
        need to store a minimum of 90 floating point numbers somewhere.
        
        I can think of a couple of ways to do this, but I was wondering if 
anyone
        has a candidate for the elusive "best" way.  The options I thought of 
are.
        
        1)      IND blocks with no sequence code.  Each block is a place holder 
for
        15 setpoints.  GR_01TO05, GR_06TO10 ... GR_46TO50.  About 10 blocks if I
        take this tack.  And I'm not sure how many CP resources that will 
consume.
        
        2)      MATH blocks. 8 REAL INPUTS per block so GR_01_02, GR_03_04 ...
        GR_29_30.  For a total of 15 MATH blocks (assuming no grades are 
allowed to
        split a MATH block).
        
        3)      REAL (data) blocks. 1 per setpoint.  GR_01_A, GR_01_B, GR_01_C 
...
        GR_30_A, GR_30_B, GR_30_C.  For a total of 90 blocks.  I would think 
these
        are very low overhead blocks, made for this type of application.
        
        
        So the question is what makes the most sense when trying to maintain
        something like this. Fewer blocks with less description and presumably 
more
        overhead per block, or more blocks with more description, but a lot of
        blocks to scroll through with select.
        
        Let me know what you think,
        
        David
        
        "An utterly fearless man is a far more dangerous comrade than a coward."
        Starbuck, Moby Dick
        
        
        
        _______________________________________________________________________
        This mailing list is neither sponsored nor endorsed by Invensys Process
        Systems (formerly The Foxboro Company). Use the info you obtain here at
        your own risks. Read http://www.thecassandraproject.org/disclaimer.html
        
        foxboro mailing list:             http://www.freelists.org/list/foxboro
        to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
        to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
        
        

-- No attachments (even text) are allowed --
-- Type: application/ms-tnef
-- File: winmail.dat


 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: