FT View ME, Advice on User created Sequence

_Dock_

Member
Join Date
Sep 2015
Location
KY
Posts
508
I have an application where I need to have 5 different tasks (simple functions like air cylinder up/down) be user/operator configurable. I also need to be able to save and store the operator created sequence, and be able to read or have a unique identifier for the sequence.

My mind is telling me to use the Recipe functions but i really dont have much experience with them so im not sure if this is the best route....

For example

1) run cylinder 1 in/out for 6 seconds with a cycle rate of 120 cycles/min
2) run cylinder 2 down for 3 seconds
3) run cylinder 3 up for 5 seconds
etc, etc, etc.

then save the configuration and give it a numeric designation or a string tag.

Anyone have any ideas beside the recipe functions?
 
Do you have any feedback from the cylinders, or just the outputs to the solenoids? I would use the feedback from position or velocity instead of timing if I had the choice.

I think recipes would be the easiest to implement, but I have never 'recorded' a recipe or had to edit one
 
I do have a feedback I will use that to do the cycle with my own logic, the timing is basically just there for the operator to give me a baseline for the logic to work off of.

Ideally I would have 6 or so drop down lines so the operator could select a function, enter the timing for each, then execute the sequence based on the order of the drop downs. Im not sure if this is achievable with the recipe or not.
 
Let me count the ways.....

There are many ways to skin this cat. No matter which you use, the cat will still be bald.

Many questions need to be answered by you before meaningful advice can be given:
  • Sequences follow the pattern of Action - Wait for Transition - Next Action -- Wait for Next Transition -- etc. You're post talks about the actions, but not about the transitions. Are you waiting for each cylinder to reach position before going onto the next? Is it just time?
  • Do you ever do two things at once (diverge & converge the sequence) ?
  • Does each step always control the cylinder rate? Is each cylinder's rate controllable?
  • Can the sequences be paused / aborted? Are there recovery concerns from mid-cycle stops / crashes?
  • Is the number of steps fixed or open-ended? Is there a realistic maximum number of steps that would be programmed.
  • How many different "recipes" do you expect to have? Can they be given unique enough identifiers to differentiate between very similar (but critically different) instructions?
  • How often are downloads made to the PLC? If a recipe is stored in the PLC, then a download would lose any recipes created/edited since the last upload/save.
  • Are there (or will there be) multiple HMIs or Production Lines that will need the same Recipe list?

To make the recipe function in the PV work, you basically will be downloading a bunch of numbers to the PLC. The PLC then has to know what each number means.

What I would probably do, if this is in a ControlLogix processor, is not to bother with the Recipe thing. Not that it's bad, mind you. I just like to know how things work, and tailor them for my needs.

I'd make a UDT of what a "step" needs (Cyl#, Direction, Rate, Time), then another UDT with header info (Name, ID) and an array of Steps. Then an array of THAT UDT which is the cookbook, plus an Edit and Active recipe, which is copied to/from the cookbook.

But that's me.

The key to success is how to present things to the operator. Forget completely about how you are going to program it. First and foremost -- THINK LIKE AN OPERATOR. What info does he need to know to do his job? Don't confuse him with facts; give him what HE THINKS he needs to know, and little else.

Possibly the biggest hurdle in rolling-your-own recipe engine is interacting with the operator to select a recipe. Do you select by name (are they unique?) or by number? If by name and you don't have many, then it's fairly easy to set up a popup or multistate selector that is populated with the strings linked to tags in the PLC. If you've got a lot of recipes, then maybe that Recipe Manager will be better at the heavy lifting, or you need to have the operators enter by number, and hope they know which number is which.

It's usually a good idea to separate your recipe editor from your running recipe. Whether a recipe can/should be editable once it's been selected to run is another question you should know the answer to.

The rest is just the mechanics of programming. Figuring out the design is where the effort is.
 
Answers are below... I am aware of UDT's but dont have much experience with those either, maybe I need to do some research to see if I can make that work.


There are many ways to skin this cat. No matter which you use, the cat will still be bald.

Many questions need to be answered by you before meaningful advice can be given:
  • Sequences follow the pattern of Action - Wait for Transition - Next Action -- Wait for Next Transition -- etc. You're post talks about the actions, but not about the transitions. Are you waiting for each cylinder to reach position before going onto the next? Is it just time?
    Mainly time based but would end at a extend or retract position even if the timer expired.
  • Do you ever do two things at once (diverge & converge the sequence) ?
    Yes, same different functions can overlap during the sequence
  • Does each step always control the cylinder rate? Is each cylinder's rate controllable?
    not all steps require a rate change
  • Can the sequences be paused / aborted? Are there recovery concerns from mid-cycle stops / crashes?
    sequence can be aborted which would require a manual recovery but it wouldnt be difficult, sequence can be paused which is basically a temporary stop or feed hold
  • Is the number of steps fixed or open-ended? Is there a realistic maximum number of steps that would be programmed.
    not really, each sequence would have a max/min on the time sequence and rate, operation would continue after each sequence has completed its assigned duration
  • How many different "recipes" do you expect to have? Can they be given unique enough identifiers to differentiate between very similar (but critically different) instructions?
    would probably only need about 5 different configurations, it would be ideal to name them with a string designation so it is easily identified by the operator
  • How often are downloads made to the PLC? If a recipe is stored in the PLC, then a download would lose any recipes created/edited since the last upload/save.
    not that often but ocassionaly a functional update or bug removal is required, wouldnt this be negated if the recipe was saved to external memory?
  • Are there (or will there be) multiple HMIs or Production Lines that will need the same Recipe list?
no, one PVP per machine, however it would be nice to save configurations that we develope for the customer to run and add them as a "Factory default"

To make the recipe function in the PV work, you basically will be downloading a bunch of numbers to the PLC. The PLC then has to know what each number means.

What I would probably do, if this is in a ControlLogix processor, is not to bother with the Recipe thing. Not that it's bad, mind you. I just like to know how things work, and tailor them for my needs.

I'd make a UDT of what a "step" needs (Cyl#, Direction, Rate, Time), then another UDT with header info (Name, ID) and an array of Steps. Then an array of THAT UDT which is the cookbook, plus an Edit and Active recipe, which is copied to/from the cookbook.
care to elaborate a little more on this? I think I follow you but not for sure. Are you saying UDT for each actuator for time and rate,
then a UDT that compiles all actuator UDT's together to start stop the sequence like an overhead manager?


But that's me.

The key to success is how to present things to the operator. Forget completely about how you are going to program it. First and foremost -- THINK LIKE AN OPERATOR. What info does he need to know to do his job? Don't confuse him with facts; give him what HE THINKS he needs to know, and little else.

Possibly the biggest hurdle in rolling-your-own recipe engine is interacting with the operator to select a recipe. Do you select by name (are they unique?) or by number? If by name and you don't have many, then it's fairly easy to set up a popup or multistate selector that is populated with the strings linked to tags in the PLC. If you've got a lot of recipes, then maybe that Recipe Manager will be better at the heavy lifting, or you need to have the operators enter by number, and hope they know which number is which.
having the ability to uniquely name 5-10 configurations would be best

It's usually a good idea to separate your recipe editor from your running recipe. Whether a recipe can/should be editable once it's been selected to run is another question you should know the answer to.

The rest is just the mechanics of programming. Figuring out the design is where the effort is.
 

Similar Topics

Hi everyone We have a basic Trend template to trend around 10 analogue inputs. Its on a separate trends page and basically scrolls real time data...
Replies
0
Views
1,220
Hi, I'm a fresher with a degree in automation. I had applied for job at an MNC. Today, I got a response saying that a sales position is...
Replies
7
Views
2,977
Hi, I am currently developing a HMI to replace an old screen that is no longer available to purchase. The plan is to connect the panel view to...
Replies
3
Views
2,289
Good Evening , I would like to develop a large HMI to display information in our mixing room. I was thinking of using a large LED screen ...
Replies
8
Views
4,883
Hey Guys, I have a program for some sprayers on my auto line. Its written except I need to add an adjustment and I have tried several ways but am...
Replies
27
Views
3,969
Back
Top Bottom