How to split system task into operating system task

[BlogRahul]

I'm trying to figure out how to schedule tasks for an operating system here, but I can't figure out.

https://www.freertos.org/RTOS-task-states.html

Suppose  one Industrial situation where we need automatic system that remove empty and defective bottles from production line.

When the user presses the start button, the conveyor belt should start.

When the user presses the stop button, the conveyor belt should stop.

The green light should be ON when the conveyor belt is ON

The red light must be ON when the conveyor belt is off

The camera takes a picture when the optical sensor detects the bottle and sends it to the computer.

Vision software programs running on the computer take an image of the bottle and decide whether it is a good or faulty bottle and send the output signal to the serial port.

8 bottles can be placed from inspection point to rejection point. A length of conveyor divided into segments, one bottle per segment.

Encoder count pulse for segment.

8 bit shift register is used to know the position of each the bottle
on conveyor. Each bit in the shift register can correspond to one bottle.

Pusher checks the bit of the shift register and removes the bottle if it is defective.


I know it's not a real time system but it's just a learning exercise so I don't think it would hurt for example

I have to divide this project task into operating system tasks and I have to set priority for each task and I am asking for help to do it.

Please guide me on this topic

Edit link address

[tggzzz]

It is a real time system, and a hard realtime system at that. Real time doesn't mean "fast". Hard real time means that if an action is too late, the system has failed.

You should start by analysing the input events, processing and output actions. Then structure your analysis to use a finite state machine that accepts the events, processes them according to the current state, and outputs the actions.

[BlogRahul]

You should start by analysing the input events, processing and output actions. Then structure your analysis to use a finite state machine that accepts the events, processes them according to the current state, and outputs the actions.

How it would be start with list of tasks

Task : When the user presses the start button, the conveyor belt should start.

Task : When the user presses the stop button, the conveyor belt should stop.

Task : The green light should be ON when the conveyor belt is ON

Task : The red light must be ON when the conveyor belt is off

Task : The camera takes a picture when the optical sensor detects the bottle and sends it to the computer.  Vision software programs running on the computer take an image of the bottle and decide whether it is a good or faulty bottle and send the output signal to the serial port.

Task : Encoder count pulse for segment.

Task : Pusher checks the bit of the shift register and removes the bottle if it is defective

In this way I have tried to divide the system tasks into OS tasks

[tggzzz]

You should start by analysing the input events, processing and output actions. Be explicit. Then design your FSM.

Only after that think about how to implement it.

[rstofer]

Systems like the one described have been built for years based on PLCs.

One thing you have to deal with is the fact that a defect is imaged at one point in the motion but rejected at a later point.  One can imagine that several other items have been imaged in the meantime and any, or all, of them could be rejected.  This calls for a FIFO that stores the reject status of the items between image and reject.  The data circulates and is even perhaps modified as the items move down the line and that data value at the reject station determines whether to kick the item to the curb.

This type of system is harder to visualize (and implement) because actions are based on decisions taken some time back based on testing done even further back.

You also need some way to detect that the item is in the proper location and the proper orientation for the operation at each station.

The start-stop stuff is just fluff.  There also needs to be an Emergency Stop system set up.  Some way that protects the user from getting entangled with the machinery.  You will see cables surrounding a machine that stop the system when they are pushed or pulled.

It might be nice if the FIFO retained the state of items on the line for a subsequent restart.

Yes, there's a Finite State Machine in this project but it is complicated by the need for the FIFO and the number of items in transit.  When you think about it, you will discover that the FIFO simplifies the design by allowing each station to be designed separately.  The kicker station receives an item, looks at the action required in the FIFO and does whatever is necessary.  It doesn't need to know why the FIFO said 'scrap it' or 'pass it', it just reacts to the object in front of it and the data at the output of the FIFO.

The FIFO is where the magic happens.  The data in the FIFO moves toward the output at the same rate objects move down the line.

[BlogRahul]

You should start by analysing the input events, processing and output actions. Be explicit. Then design your FSM.

actually my main motive was to understand process state / task state as shown in following link
https://www.freertos.org/RTOS-task-states.html

I guess my current example is very complex to understand these concepts. I had feeling that by taking this example as refrence, may be someone will try to explain concepts

If It's necessary to design FSM to understand these concepts, then I will design a simple FSM for small project   

[rstofer]

If you want to use an RTOS then think of each station on the machine as a Task.  Think of all tasks as Blocked because there are no items on the conveyor.

Some external event occurs and kicks off Task 1 which loads an item onto the conveyor.  This action, when complete, starts Task 2 and goes to sleep until the station is clear and it's time to load another item onto the conveyor.  The entirety of Task 1 is to place an object on the conveyor, notify Task 2 and go to sleep.

Task 2 gets scheduled and it applies a label to the item. notifies Task 3 that the bottle is labeled (or not) and goes to sleep until Task 1 tells it to wake up.

Task 3 gets a notification from Task 2 that there is an item to process and it does its thing before going back to sleep.

The notification process is probably through semaphores (simple flags) or counters.  Maybe queues if items can stack up and have different downstream actions required.

Each of the tasks is quite simple and, in general, don't care at all how the item came to the station.  They only need to know that an item arrived and they are to take some action.

For machine control, the 1 ms clock of FreeRTOS is not a burden.  I would imagine that all tasks have the same priority and, once triggered, operate asynchronously.  There may be FSMs within a task to retain state when a task gets a little more complex.

The diagram is quite clear about how a task transits from Blocked to Ready to Running to Blocked...  The Suspended state may not even be used but, basically, it removes a task from the Ready list and the task will never be scheduled until the Suspended state is changed.

Remember, there may be a lot of Ready tasks but only one Running task (at any instant in time).  Each task, when scheduled to Run, will take up where it left off.  Given all tasks of equal priority, each task will get a 1 ms time slot to do whatever is required.  That may be quite complex internally but from the RTOS point of view, it's just a task that gets scheduled and runs for a while.

From a designer point of view, each task is a stand alone unit.  It gets scheduled, it runs until complete and then puts itself in the Blocked state waiting for another start signal (which may be a semaphore getting set by a preceding task).

You can check Amazon for 'FreeRTOS book' and there are several references that are going to be a lot more help than me.  I would try to model my machine using whatever techniques are in the book, all in code.  Tasks can 'delay' themselves for some period of time to model accomplishing the work.  There may be some back and forth between tasks because Task A can't kick off Task B if Task B is still busy.  There might not be a place to store the item.  ETA: So Task A can't complete and neither can Task (A-1) and all the way back to the beginning.

This gets to the problem of queueing theory - how much stuff can go through the line based on the slowest operation and how can I make a parallel slipstream to double the production at a slow task.

Interesting stuff!

Just for fun:

[tggzzz]

You should start by analysing the input events, processing and output actions. Be explicit. Then design your FSM.

actually my main motive was to understand process state / task state as shown in following link
https://www.freertos.org/RTOS-task-states.html

Ah. That's the XY problem https://xyproblem.info/

Just because you have a hammer, it doesn't mean everything is a nail. Using the appropriate technique is a key part of engineering (as opposed to tinkering).

[BlogRahul]

You should start by analysing the input events, processing and output actions. Be explicit. Then design your FSM.

actually my main motive was to understand process state / task state as shown in following link
https://www.freertos.org/RTOS-task-states.html

Ah. That's the XY problem https://xyproblem.info/

Just because you have a hammer, it doesn't mean everything is a nail. Using the appropriate technique is a key part of engineering (as opposed to tinkering).

I have designed FSM, Can you help me to understand process state 

 Run motor clockwise when sensor S1 is high
 Run motor opposite of the clockwise rotation when sensor S2 is high
 Stop motor sensor S3 is high

[rstofer]

You should probably define actions for every possible state of the inputs at every state.  What happens when the motor is running in either direction and S1 goes active.  If the answer is to ignore it, put a loop on both of those states for sensor S1.  If it should shut down the motor, draw the arc.

You seem to be stating that the 3 sensors are mutually exclusive and that only one will be active at a time.  What if that isn't true?

We do a lot of FSM work in FPGAs and the trick is to define every output in every state under all conditions (both branches of an IF ELSE structure).  Nothing left to chance.  Of course, there is a language feature to help which allows us to define a default value that applies whenever a specific output isn't being generated.

[tggzzz]

An event occurs at an instant in time. A condition occurs during a period of time. At any given time an FSM is in exactly one state.

I suggest you stop jumping into design, and understand FSM concepts first.

[Sal Ammoniac]

To the OP: is this a homework question? I've noticed that you've posted either the same question, or a variant of it, on several other electronics discussion forums.

[BlogRahul]

To the OP: is this a homework question?

This is not a homework assignment. I have come across many websites, tutorials, YouTube videos, but it is very painful that no practical example is given to clerify the defination of process state. 

[SiliconWizard]

Well, AFAIR, the FreeRTOS documentation explains this. Have you read it?

[BlogRahul]

Well, AFAIR, the FreeRTOS documentation explains this. Have you read it?

Yes I gone throug example plant control but I don't understand example in context of task state

https://www.freertos.org/tutorial/solution2.html
https://www.freertos.org/RTOS-task-states.html
https://en.wikipedia.org/wiki/Process_state

[tggzzz]

You are looking in the wrong place.

In general examples given for a particular product, of whatever type, will presume that you know the fundamental theory and want to know how that is embodied in the specific product.

So, don't look at product documentation. Do look at university courses, textbooks, etc; there are many sources online.

[rstofer]

Well, AFAIR, the FreeRTOS documentation explains this. Have you read it?

Yes I gone throug example plant control but I don't understand example in context of task state

https://www.freertos.org/tutorial/solution2.html
https://www.freertos.org/RTOS-task-states.html
https://en.wikipedia.org/wiki/Process_state

Let's try again...

A process, or task, performs a certain function.  It is simply a block of code (in the case of computer tasks) that needs to function from time to time to accomplish something but it doesn't need to run constantly so it can go to sleep until it is required.

There exists, in the case of an RTOS, a master scheduler responsible for getting these tasks started (or restarted) based on a list of tasks, their
priority and their state.  If a task is suspended, it will not be scheduled to run so we're done talking about that state.  Something has to change the status of a suspended task but it is external to the task itself because it won't be scheduled.  The scheduler still knows about the Suspended task but pays no attention to it.  Until its state is changed to Ready (available to be scheduled), nothing happens.  Initialization code might run from startup and suspend itself never to run again (until the next reset).

Looking again at the transition diagram, there will be a list of tasks in the Ready state.  These are Ready to be scheduled and will be changed to Running, one by one, in priority order, by the scheduler.  At every tick, the scheduler looks at the priority of the Running task and those in the list of Ready tasks and picks one to start (or restart).  Remember, tasks lose their focus based on a timer tick and may not be complete and might be the type of task that is never truly complete.

OK, the scheduler starts a task and allows it to run for one tick.  At the end of the tick period, the task might revert to Ready or remain Running, depending upon task priority.  If there is a higher (or equal) priority task Ready to run, it gets to run for the next tick and the previous task is marked Ready.

Tasks can also be Blocked - they're not Ready to be started.  They are waiting on an event of some kind.  Perhaps a character received on the USART and the event posted by the interrupt handler (puts the char in a queue).  The scheduler now has another Ready task to schedule, again depending on priority.  The task for serial input probably builds a line of text before it posts the line in a queue to an even higher level task which might interpret the line as a command string.  This command string could even be interpreted as an event to unBlock another task.

The task transition diagram and description is very specific and quite correct.   Just imagine some piece of code and think about how it would transition between the states and WHY.

You can imagine each task as an entry in a ledger.  The entry will have the task name, it's current state, a pointer to what it's waiting on to transition to the next state, the memory address of the next instruction in the task (remember, it was stopped at a timer tick, not necessarily completion).

Suppose you are the scheduler.  How would you handle a dozen different tasks such that each received the CPU resources it needs in a timely manner.  You can't overlook a task, task states change as does the priority (yes, you can mangle the priority) and external events happen all day long.

Take a long look at the transition diagram and ask yourself why each arc is there.  What does it do and why does it do it in exactly that way.  There are no random transitions, each is enumerated with great care.

Maybe this series of videos will help:




ETA:  Part 3 is very helpful!

[SiliconWizard]

Well, AFAIR, the FreeRTOS documentation explains this. Have you read it?

Yes I gone throug example plant control but I don't understand example in context of task state

https://www.freertos.org/tutorial/solution2.html
https://www.freertos.org/RTOS-task-states.html
https://en.wikipedia.org/wiki/Process_state

The link you posted, https://www.freertos.org/RTOS-task-states.html , explains it briefly but with pretty much all you need to know about this. It's not rocket science.

What you may actually need to learn first IMO is not specifically RTOS tasks in particular, but multithreaded programming in general.

[rstofer]

But if the application is a machine control, a central RTOS may not be the best implementation.  Each station runs its own process based on inputs presented along with objects.  All processes work in parallel in real time.  Whether an RTOS is useful seems debatable since it tends to serialize tasks.  I suppose you could just run all tasks in sequence but that's not the point of an RTOS.

There's a reason machine controls are built with PLCs.  In the simple version, the inputs for every station are read, outputs are computed for every actuator and in a single cycle all of the outputs at every station are set.  The compute process is fast compared to the machine motion so everything really is being done in parallel.

As to shifting status from station to station, many PLCs have shift registers which can shift status to downstream stations - like reject the item at the Reject station because it wasn't detected as full at the filling station before the capping station before the labeling station.  Things like that.

For machine controls, a diagram of the product motion through the process is imperative.  It can be spread out on a huge whiteboard (or really big piece of paper) or it can use columns in an Excel spreadsheet.  More information is better...

Consider a single item moving down the line.  What happens at each station, what sensors trip, which actuators activate, how long does the operation take, etc.  Now what happens when there is an item at every station?  There is no substitute for knowing how the machine is supposed to work.

A typical move, drill, paint and rivet operation might look like:

Position part (control elsewhere) -> Level panel -> Clamp Part -> Drill down -> Dwell -> Retract Drill -> Position paint dispenser -> Dispense paint -> Retract paint dispenser -> Position rivet inserter -> Insert rivet -> Retract rivet inserter -> Clamp over rivet head -> Upset rivet -> Retract clamps -> Wait for next Position Complete.  Rinse and repeat until the fuselage panel has a whole lot of rivets.

This machine had no clocks, it was totally asynchronous logic based entirely on limit switches and such.  It used a stepping switch to change states and a barn full of ice-cube relays for the logic.  A long time ago, before PLCs.

One way or another, you need to know every single step of the operation.

And, yes, it can be done with an RTOS but there are examples of uC PLCs that might do a better job.  When it comes to harsh environments, a real industrial PLC is the way to go.