LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Structured Program Diagram

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.

Message 11 of 19
(1,794 Views)

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:

JSP.png

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 12 of 19
(1,770 Views)

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

 

EvunCapture.PNG

 

========================
=== Engineer Ambiguously ===
========================
Message 13 of 19
(1,760 Views)

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. 

0 Kudos
Message 14 of 19
(1,736 Views)

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.

0 Kudos
Message 15 of 19
(1,733 Views)

@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

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 16 of 19
(1,706 Views)

Hi, 

Thank you to everyone,

I think that there are two methods to draw Flowchart of "Summation /Division.VI"

Flowchart 3.PNGFlowchart 5.PNG

0 Kudos
Message 17 of 19
(1,672 Views)

@Emna20 wrote:

Hi, 

Thank you to everyone,

I think that there are two methods to draw Flowchart of "Summation /Division.VI"

Flowchart 3.PNGFlowchart 5.PNG


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.

0 Kudos
Message 18 of 19
(1,661 Views)

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.

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 19 of 19
(1,639 Views)