Agonizing over project architecture/paradigm, event vs state vs mixture - guidance, comments, experiences appreciated.

[wiebe@CARYA]

BTW. Thinking about the actual problem, not the architecture, I think the way you organised the steps makes it more difficult that it needs to be. Sure was a bit confusing for me at first.

Your step definition seem bit inconsistent. Defining it like this makes it easier:

Step: Move unit from S to X \ Step: Run program 4 on X

Step: Move unit from X to Y \ Step: Run program 1 on Y

Step: Move unit from Y to O \ Step: -

Now it's clear to see there are two kinds of states: transitions and actions. If you make sure the steps are executed in two phases, transitions and actions, it might be easier to think about the problem.

The sequence is now very simple:

For each step (in parallel):

   If unit present, do transitions

For each step (in parallel):

   If unit present, do actions

First cycle:

move unit0 S>X,

perform 4X on unit0

2nd:

move unit1 S>X, unit0 X>Y

perform 4X on unit1, 1Y on unit0

3rd

move unit2 S>X, unit1 X>Y, unit0 Y>O)

perform 4X on unit2, 1Y on unit1

[wiebe@CARYA]

---

@JÞB wrote:

You need more than 1 state machine Period.  You need to do more than one thing at a time so, a single loop won't do.

---

Guess that depends on how you define a state machine.

Enum\WhileLoop\CaseStructure? Didn't make one of those in the past 10 years. Don't need one let alone two for this either.

[JÞB]

---

wiebe@CARYA wrote:

---

@JÞB wrote:

You need more than 1 state machine Period.  You need to do more than one thing at a time so, a single loop won't do.

---

Guess that depends on how you define a state machine.

Enum\WhileLoop\CaseStructure? Didn't make one of those in the past 10 years. Don't need one let alone two for this either.

---

Actually, suggesting that the "Mover Data" contains an Enum of Moves as its first element in a cluster was just a cheap way to assign move priority

Pseduo code:

• Flush move request queue;
• Sort Queue Array;
• calculate "Move possible" (Destination Full as Bool implies Source Full as Boolean = Move Possible)
• delete the first T element from the queue array (stuff the rest back in the queue);
• operate the move
• repeat.

[wiebe@CARYA]

Did the attached LV2017 project during lunch last week. Actually, a bit longer then just lunch, about an 1..1.5 hour.

It's very primitive, I admit. Didn't even make a sequencer class jet, it would be my first candidate in line for refactoring. But not having a sequencer class show the principle of operation better.

The current sequence is crude. It simply does all the moving, then all the measuring. If the steps always take the same time, the longest will be the bottleneck, so it won't get much faster anyway. In practise, you probably need a more elaborate plan.

What the project shows is how the top level plan gets easier, when you make objects from the bottom down. So by abstracting the commands, the problem gets less complex. It wouldn't be hard to add command children or to implement real measurements. In fact (in a perfect world), you can do so without modifying the existing code (much). As long as you're honour the class's contracts (what they should do), your good.

I even though in some channel wires! Just to please Ben... But I must say, they do the job and are really fast to use in this way. Not sure if they scales up when the application grows though...

Anyway, I had fun doing it.