09-11-2019 06:51 AM
I would take all 3 leaders back to the same point.
Effectively it won't matter, but it is clearer in documentation that once an event has been handled, control will loop back to the entire event structure to handle the next event.
It is difficult to model an event structure perfectly in a flowchart. Flowcharts imply a serialization of those comparisons. Also, it gives the appearance that the code is cycling through the comparisons constantly even when no even is happening. But in reality, the code pauses at event structure and waits until an event happens and is added to its queue where it jumps directly to that event case and handles it. If multiple events are in the queue, it will process them in the order they were received.
I don't know how you would precisely model that behavior in the flowchart. I would have all lines return to the top, and perhaps put some other shape around all those comparison to indicate all those "comparisons" are inherent in a single structure. Remember also that Timeout is a possible event in an event structure, and would be another branch the code could take. I would add a branch for that at the bottom (assuming that the timeout event exists), and note what the timeout interval is.
09-11-2019 08:58 AM
Isn't there an alternative way of writing a choice where the option is written on the arrow? That'd more correctly model a waiting event structure, but if the choices are many it'll quickly be impossible to manage. Something like this:
09-11-2019 09:28 AM - edited 09-11-2019 09:31 AM
Yamaeda has the closest but I would add an arrow looping the Event Structure back to itself for the Timeout case.
Similar to what a State Machine Diagram looks like
09-11-2019 10:42 AM - edited 09-11-2019 10:46 AM
Ha! You also need to add FIFO buffer of events to this flow chart.
PS That is the reason why all flowcharts before Yamaeda are not correct - in case of multiple events the decision is made what has been added first, not what is the first in the flow chart.
09-11-2019 10:44 AM - edited 09-11-2019 10:48 AM
An event structure does not follow dataflow in the conventional sense and thus cannot really be approximated with a flowchart that easily. It queues up events event if dataflow has not reached it (or if it can never be reached) and if the event is set to lock the front panel, the VI will lock up potentially forever. An event structure is also a one-shot deal and does not intrinsically loop, you would require it to be in e.g. a while loop to approximate some of the diagrams above.
Seems like a meaningless exercise. I would focus on overall program architecture instead. An event structure is just a small (and often misused) part of the code and deals mostly with user interactions.
09-11-2019 01:18 PM - edited 09-11-2019 01:19 PM
@Alexander_Sobolev wrote:
Ha! You also need to add FIFO buffer of events to this flow chart.
PS That is the reason why all flowcharts before Yamaeda are not correct - in case of multiple events the decision is made what has been added first, not what is the first in the flow chart.
Well sure but the level of detail in a flowchart is up to the programmer.
So the internal working of the Event Case like the Event Queue doesn't need to be on this level of the flowchart because that is a basic understanding of how Event Structures work. Just like the Process1, Process2 process blocks would contain code not shown on this Flowchart.
But if you were to flowchart the Event Structure itself, (instead of a program using an Event Structure) then yes that would have to be shown.
@altenbach wrote:Seems like a meaningless exercise. I would focus on overall program architecture instead. An event structure is just a small (and often misused) part of the code and deals mostly with user interactions.
Yes, but fun as I haven't done any flowcharts in years
09-12-2019 06:23 AM
Hi,
Thank you to everyone,
I think that there are two methods to draw Flowchart of "Summation /Division.VI"
09-12-2019 06:41 AM
@Emna20 wrote:
Hi,
Thank you to everyone,
I think that there are two methods to draw Flowchart of "Summation /Division.VI"
The first one more clearly represents the event structure. Note that you only need the Timeout loop if you are actually using the timeout, and if there's no code in the timeout loop then there is really no need to use the timeout.
09-12-2019 09:21 AM - edited 09-12-2019 09:23 AM
The more I think about this the more I think a "Flowchart" is the wrong approach.
A "State Diagram" would be the proper way to diagram programs based around an Event Structure.
An Event Structure in a While Loop is basically a State Machine.