Sounds like a good project. The Click does not support the "Stage" programming like the BX PLCs do, but the Click can still do batching/ sequencing control like you will need. (the "Stage" programming just makes it easier to do batching/ sequencing). Their are many Click experts on this forum that can suggest multiple ways to accomplish your batching/ sequencing. One way could be to increment a counter when a sequence completes, and use this count value to enable/ disable rungs of code based on the actions required for that step.

As you develop your requirements, both in hardware and logic, you will get more detailed suggestions. For example: "drawing pelletized feed". A motorized rotary feeder? "a scale bucket say 20 lbs". Load cells with an electronic interface to provide a 4-20ma signal to the Click? "Then dump into a auger". Air cylinders triggered by solenoid valves to lift, move, and/or tilt bucket onto auger? With position switches on the cylinders? "go to 1 of 6 feed stations". What determines which 1 of 6 feed stations? The auger rotates to select the desired feed station? The auger is pulled into position using a winch and cable? With position switches at each feed station?

As well as determining the hardware to accomplish your actions, begin to develop a logic flow description. What outputs will be energized to accomplish what task and what inputs will be monitored to determine when the task is done, for each step of the sequence. Your hardware and your required control go together.

For example, depending on your application, you may need to consider additional controls for weighing the feed and moving to the desired feed station. Can the desired weight be obtained (within required accuracy) by simply on/off control? Is a 2-speed system required? (Fill at hi-speed until close to the setpoint, and then slow to reach the setpoint) Is a PID control required? Same questions with the moving of the auger to the desired location.

Not part of your question, but a suggestion: consider alarm conditions and actions, for example what to do if the auger does not move to the desired location within a certain amount of time, or the 20 lbs. is not reached within a certain amount of time. Consider a manual mode (or test mode) to allow manually energizing outputs. Consider safety devices to prevent personnel injury. For example, shut down auger movement is safety gate is opened. Equipment safety devices. For example, excessive auger movement switch to stop movement if feed station prox. switch fails.

Does your application involve:

• Each station can make a request for feed?
• Feed is dispensed to the feed stations in order of their request?
• How big of a buffer (how many requests are stored to memory) do you want while a feed station is being filled? 6? 10? 20? More?

If my explanation fits your application, I've done this before but not for feed stations. It was actually for coin operated player pianos, where the owner did not want all of them playing at the same time, but in order of requests.

Here's a way to think about your batch sequence as step logic. Forget the code for now, just nail down what happens at each stage and what triggers the next one:

The pattern K Price described works perfectly here — use an integer register as your Step number, and each rung checks Step == N to decide what to energize. When a step's "done" condition is met, bump the counter and reset your step timer. Every output is guarded by its step number, so things naturally shut off when you leave that step.

Todd's question about the request queue matters too. If multiple stations can call for feed at once, you'll want a small FIFO (first-in-first-out) buffer so requests get served in order. That can be as simple as a shift register of station numbers.