Dataflow issue

[CoastalMaineBird]

You need to read _____

There are certainly some bad examples in there.  But there is also this example of why dogma doesn't work.

The "problem" is the upper version, the "solution" is the lower version.

The beginner who is learning this stuff might not notice that the "solution" took away the display indicator of the position.

The beginner who is learning this stuff might not realize that the "solution" requires him to hook up another wire in EVERY SINGLE ONE of the other event structures(I have an event structure with 110 cases - maybe this code does too).

Somebody tell me why this "solution", that requires 109 wires in other cases, is better than the "problem" case.

[CoastalMaineBird]

I would still argue that a state machine, even if it is effectively sequential, is a better approach simply because it is very easy to modify the flow. A stacked sequence is not. In addition, it is much easier to wire data through a state machine as opposed to a stack sequence with sequence locals. Applications regularly require change. Why not use the more flexible architecture which facilitates change better?

I have nothing against state machines, I have used plenty of them, and they are certainly useful and flexible.

But they require more effort for the simple cases.  Their existence doesn't mean that a less-flexible tool is "evil" - that's my point.

[altenbach]

---

@CoastalMaineBird wrote:

The "problem" is the upper version, the "solution" is the lower version.

The beginner who is learning this stuff might not notice that the "solution" took away the display indicator of the position.

The beginner who is learning this stuff might not realize that the "solution" requires him to hook up another wire in EVERY SINGLE ONE of the other event structures(I have an event structure with 110 cases - maybe this code does too).

Somebody tell me why this "solution", that requires 109 wires in other cases, is better than the "problem" case.

---

• The "problem" makes no distinction between controls and indicators and overuse of locals muddles that distinction even more. If you want a "live" display indicator, place the terminal in the innermost location. No local needed.
• There are two easy solutions for the problem of wiring 110 other cases across:

1. linked input tunnels
2. feedback nodes (They can be local to one case)

• none require much effort.

[Yamaeda]

@Coastal I'd probably use your 1st version with the locals if i have lots of Event cases, but not that in neither you need the Sequence frame. 🙂

Sometimes you need to jail and fence some code, but like in life it often is healthier with more freedom. Bad analogy ...

/Y

[Ben]

---

@CoastalMaineBird wrote:

You need to read _____

There are certainly some bad examples in there.  But there is also this example of why dogma doesn't work.

The "problem" is the upper version, the "solution" is the lower version.

The beginner who is learning this stuff might not notice that the "solution" took away the display indicator of the position.

The beginner who is learning this stuff might not realize that the "solution" requires him to hook up another wire in EVERY SINGLE ONE of the other event structures(I have an event structure with 110 cases - maybe this code does too).

Somebody tell me why this "solution", that requires 109 wires in other cases, is better than the "problem" case.

---

A) No GUI updates required (Correct can iterate at usec iterations while GUI version will most likely be in msec).

B) Data is clearly private to the loop and unsuspecting noob can not grab a copy (and introduce a race condition) without knowing.

C) Linke tunnels will save on wiring all of those events.

and being the kermudgion I am, controls and indicators are ways to get values from users or display values to users so I urge developers to look at them as I/O routines. Wires are memory locations.

Take care and keep having fun!

Ben

[CoastalMaineBird]

A) No GUI updates required (Correct can iterate at usec iterations while GUI version will most likely be in msec).

Well, if I take all the controls and indicators off of ANY front panel it will execute faster, but not be very useful.  You're assuming that the user can get by without seeing this number.  Maybe yes, maybe no. If YES, then you're certainly correct.  I didn't make that assumption. 

B) Data is clearly private to the loop and unsuspecting noob can not grab a copy (and introduce a race condition) without knowing.

True.

C) Linke tunnels will save on wiring all of those events.

It might save on the CONNECTION time of all those wires, but it doesn't save on the space needed for them.

[Mark_Yedinak]

---

@CoastalMaineBird wrote:

A) No GUI updates required (Correct can iterate at usec iterations while GUI version will most likely be in msec).

Well, if I take all the controls and indicators off of ANY front panel it will execute faster, but not be very useful.  You're assuming that the user can get by without seeing this number.  Maybe yes, maybe no. If YES, then you're certainly correct.  I didn't make that assumption. 

---

However a solid design architecture will separate the UI from the processing tasks. Therefore your processing can occur very fast and effeciently without being impacted by UI events. The UI task can run slower and take the performance hit since  (such as from usec to msec) since this really won't impact the user. It could significantly impact the processing though.