Announcement

Collapse
No announcement yet.

Recipe Database

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Recipe Database

    I have a customer in the medical field that wants be able to select, edit and save recipes for mixing medicine with a recipe database style chart. I presented the cmore recipe database to him and he thought it would be to complex when using a possible 94 different values per recipe. Has anyone created your own recipe database before in the plc?
    i am currently using a Productivity 1000 P1-550.

  • #2
    Hi dknieder,
    The first question is how you want to display and edit the recipes?
    What did he not like about the CMore?
    You can set up the recipe array (database) in the P1000.
    https://accautomation.ca/productivit...ctions-part-1/
    You will still need the CMore front end to be able to modify and change the recipe.
    Other alternatives would be to use a separate software package like AdvancedHMI. This is a VB.Net package that will communicate to the P1000 using Modbus TCP or Modbus RTU.
    https://accautomation.ca/productivit...communication/
    In this case, a computer running AdvancedHMI would be used as your HMI. Since this is written in VB.net and runs on Visual Studio, a connection to a database is very easily done. (Access, SQL, etc) The editing of the database would be done through AdvancedHMI and then the recipe that you want to run would be transferred to the PLC.
    I hope this helps you out.
    Regards,
    Garry
    _________________________________________________
    Garry
    ACC Automation
    https://www.accautomation.ca
    Connect with us on Facebook: facebook.com/accautomation/

    Comment


    • #3
      Originally posted by dknieder View Post
      I have a customer in the medical field that wants be able to select, edit and save recipes for mixing medicine with a recipe database style chart. I presented the cmore recipe database to him and he thought it would be to complex when using a possible 94 different values per recipe. Has anyone created your own recipe database before in the plc?
      i am currently using a Productivity 1000 P1-550.
      Yes.
      In your case, allocate 94 arrays - or some arrangement of 94 array types (1D or 2D arrays). You choose the datatype.
      Use an INTEGER as the recipe number. It will then be able to point to all entries of the selected recipe.

      If we had an idea what datatypes of items need to be in your recipe, we could provide a bit more info. (I am not asking you to provide proprietary/IP/secret.... info)


      I know this can be done. The image below is from a ProofOfConcept recipe editor EDITOR! (yes an editor editor) The project is EA7-T12C and P3-550.
      It is a bit overkill for what you need, but it does show that large, complex recipes can be edited/maintained in the PLC.



      Click image for larger version  Name:	RecEdit.png Views:	0 Size:	225.3 KB ID:	130162

      A bit of info about the image above can be found here
      Last edited by kewakl; 04-08-2020, 12:13 PM.

      Comment


      • #4
        kewakl That is nice looking. There is a name, version number, a few binarys, and the rest are integers. They also wanted to display only recipe rows that are selected in a configuration page. Any feedback or info would be greatly appreciated.

        Comment


        • #5
          Can you post a cmore project with internal tags? Just the datatypes, and a unit descriptor (like pressure/temperature/time...)
          - no project-identifiable info needed.
          just for a general layout.
          ----- I'm trying to get an idea of format and amount of data PER recipe.
          Have to worry about showing specific rows some other time.

          Comment


          • #6
            TagDB.CSV Here you go

            Comment


            • #7
              If we consider what the PLC has to do to handle your recipes, we can begin to build a presentation of the recipe editor.
              Somehow, your plc must keep all entries for each recipe bound to each other. The index of the arrays will be the recipe number.
              Example: (assuming all recipes have the same format)

              Recipe Number S32_000001

              Recipe Name STR_000001
              Entry 1 AR1S32_000001
              Entry 2 AR1S32_000002
              Entry 3 AR1S32_000003
              Entry 4 AR1S32_000004

              Use S32_000001 as the index to all of the arrays listed above.
              If S32_000001 has a value of 17, then each array above will point to some piece of your recipe #17.

              Considering your mid-sized HMI and your large recipe entry count, you may want to 'segment' your recipe editor by some measure of your process/documentation.
              94 entries on one screen would require a very small font.
              Depending on how you need to handle it, you can page through the recipe on the same screen or you could build a separate screen for each 'segment' of your recipe.

              The prose below assumes LOADING, EDITING and SAVING -- ONE recipe at a time.
              ---since we do not yet have a recipe editor format, this is subject to change---

              Loading a recipe.
              When you navigate to your recipe editor, you need to load the data from the PLC to the HMI.
              You probably do not want to edit directly the recipe STORAGE. This would not allow you to compare your EDITOR values with your recipe STORAGE values.
              So, when you navigate to your recipe editor, or while in the recipe editor you change the recipe number that you need to edit - or change pages of a multi-page recipe,
              copy the relevant recipe STORAGE tags to a temporary EDITOR tags in the PLC - have those EDITOR tags bound to the screen text/numeric/checkbox entries.

              Detecting a change.
              Every scan, or on some interval/event, you want to compare the values in the EDITOR to the values in your recipe STORAGE. If there is a difference, indicate that on the HMI and enable a SAVE button.
              If you use all arrays in your recipes, this can be as simple as a series of NEQ contacts that (if one or more equate to true) turn on an RecipeEntryChanged bit.
              If you get creative,you can indicate WHICH entry has changed.

              Saving a change.
              Whenever an edit is made, you can save it by copying the EDITOR's values back to the recipe STORAGE. IF all entries are tied to the arrays (by using the recipe number as an index) then a couple CPD instructions could handle this. It is up to you whether every individual edit (TO ONE RECIPE) must be saved, or just a bulk save when the editing of the recipe is complete.

              Clear 'RecipeEntryChanged' after a Load/Save
              This could be automatic - whenever the procedure described in 'Detecting a change' section above finds that there is no change, any indications of a change should disappear.


              Bitfield entries.
              Bits can be packed into an element of an array to keep all binary recipe settings in one TAG. This array element will still be bound to the Recipe Number.
              Unfortunately, at this time, PAC does not allow iterating through the bits in a word -(i.e. you cannot use a TAG to point to the bit in the word.) so they will need to be hardcoded.

              Enough for one post.

              Comment

              Working...
              X