Looking for examples of cooperative multitasking hardware projects

[Aristos Queue]

I am curious if anyone has any examples of projects they have worked on that meet ALL of the following requirements:

1. Two hardware (real or simulated) elements, each working on its own task
   
2. Some reason why the two parts cannot both be working at the same time at any moment
   
3. Some element of interaction between them at some point in their operation.
   

A contrived example:

I have two digging machines, both drawing power from the same battery. The battery provides only enough power to move one digger at a time, so the two diggers have to take turns digging. Each digger is digging its own independent hole, but the dirt they dig up is being put on the same truck, and there's only room for one digger at a time at the truck.

In this example, each digger is running its own program, and you can't really sync the two programs to a fixed point because the amount of time needed to dig each hole -- the rocks encountered, the size of the hole, etc -- may vary greatly. So to timeshare, you have to pause one digger at whatever point it is at to let the other digger proceed for a bit. When each reaches the point in the program where it wants to put dirt on the truck, it has to wait if the other digger is already at the truck. Your cooperative multitasking has to realize that there is no reason to pause the digger at the truck because the other digger cannot proceed, but if the other digger is still pulling dirt from the hole, you might pause the digger at the truck to give the other digger some run time.

I know this is contrived. More commonly, you would just have two hardware processes that run in parallel freely and only sync up at their point of interaction. I am specifically looking for examples in hardware of the type of cooperative multitasking that we have to do in software on systems that have only one CPU and do not support multiple threads.

Anyone have any projects they can describe? Any vibration limitation systems (i.e. running both machines at the same time creates too many vibrations)? Power limitations? Etc?

[ShaunR]

It's common in parallel testing on production lines (if I get what you I think you are asking).

For example.Say you have 10 fixtures but you can only test 2 simultaneously (because that's all the hardware you have).

When one test completes, it moves to the next non-tested fixture. In between changing from one fixture to another, all tests have to wait so that the switch MUX can re-route to the probes of the next fixture so any test in progress has to reach an arbitrary completion point (finish its current measurement) before the other test set can move on. If fixture "1" fails (i.e the overall test time is is also variable - failure results in a reduced completion time) then it must move to "3". It can only do so when the test set at fixture one has finished its current measurement (once test set "1" has moved on, test set "2" it will continue). Additioally. If "3" also fails, then it moves to "4". If fixture "2" then completes, it must ignore fixtures 3/4 since they have already been tested and move to "5" and so on.

[todd]

Motors manipulate devices. Instrumentation measures the devices. Different types of device data collection and different types of motor movements have different timespans and different requirements for synchronization. Currently, I use a left-to-right flow along with notifiers to synchronize things. I've been trying to figure out how to have the devices' drivers and the motors' drivers message each other. Is that vague enough?

[Tim_S]

A dial where one PC controls testing on both test stations and monitor the load and unload stations. PROFIBUS and DAQ cards are common to all stations. The stations on the dial are asynchronous.

[0_o]

Simulate the car's differential that drives the wheels:

Differential frequency clock for each wheel:

The clock triggers each wheel's rotation but the frequency and power depends on the state of the other wheel. Moreover, it doesn't matter if the wheel got the trigger if it doesn't have the resources.

Each wheel is an actor driven in parallel over the same resources with its own conditions.

If they both get the same resources one wheel might drift when it can't keep up in turns or when it has to deal with more friction.

If one wheel will get all the resources we might get into a lock condition or with a car that drives pointlessly around and around.

1. 2 wheels = 2 hardware

2. They can work at the same time but not independently. Coupling is the more general case I think.

3. If one wheel is blocked the available resources for the other wheel are changed. Besides that, with the car differential turned off (truck with one wheel digging into the sand) the wheels can't move independently.

The benefit of such a simulation is that you could easily detect problems by observing that your car has some jigger and can't handle some terrain.

This might also be practical for electric cars.

[Aristos Queue]

ShaunR -- Yes, that's the sort of puzzle I'm interested in.