Data-flow visual improvement

[Pnt]

One ugly way i usually have to code is  

A better way would be to be able to wire, a wire to every function.

This wire will carry data, but it will not pass them in the middle function. It will be a bump input-output, just to determine which function to be executed first. There should be an indicator, when this dump input-output is activated. It can be activated with right clicking on the icon.

 This wire should be able to be, a dump wire without any data so you can impliment this

The images way not be so nice, but that's the idea..

[crelf]

A similar topic is being discussed in this thread.  A method of enforcing dataflow while not forcing datapassing by having a new subVI/primative right-click option (Visible Items > Sequence Container) to force dataflow:

Message Edited by Support on 10-05-2009 09:55 AM

[altenbach]

Well, the "time delay" express VI contains error IO for better execution ordering ..... 😮 😄

[Tom_Hawkins]

I don't like this one (or crelf's) sorry, they seem to create a new bit of visual language we have to learn without really saving very much time and effort - how hard is it to drop a single sequence frame, which should be immediately comprehensible to any LabVIEW programmer?

I feel bad about pouring cold water on a well intentioned idea, but all these suggestions for extra features do need to be balanced against the need to keep LabVIEW simple for new users to get to grips with - and keeping it possible for even experienced programmers to understand each others' diagrams without too much head-scratching.

[crossrulz]

There is a simple solution to this:  give all VIs the ability to pass the error cluster.  That's what I did with my wait function.  I made my own VI that all it has in it is the wait function and error in/out terminals.  I've seen many people do this, just look at Bloomy's book.  Data dependency is what makes LabVIEW work so well, so use the error cluster to force your data dependency.  But once again, NI should have an error in and error out for all of their VIs, especially the timing VIs to avoid using the sequence structure with just a wait function in it as in the example by Pnt.  Even if the error is just passed on, have it there to force data flow.

[altenbach]

> There is a simple solution to this:  give all VIs the ability to pass the error cluster.

One of the strenghts of LabVIEW is the ease of adapting to multicore architectures. Many primitives (math, etc.) should be as fast as possible and should NOT have an error cluster because execution order should never be forced.

Excessive use of the error clusters would often linearize the code so it would only use one CPU core at any give time.

I agree that the delay VIs (and maybe some others) should have an error cluster, but most others should not.

> That's what I did with my wait function.

Yes, I did that back in LabVIEW 4.0. The icon had a nice image of a snail on it 😄

Message Edited by altenbach on 06-08-2009 12:42 PM

[waldemar.hersacher]

Or you can use the OpenG Time VIs.

[Pnt]

Making another vi (with error cluster) to use a simple one is not a nice solution. You will just fill your palletes with duplicate vis.

Anyway you are missing the point here.

The idea is to improve the way our mind is "seeing" the code.Imagine a big vi. Our eyes are keep tracking the wires to understand the code flow.Then appears a sequence. It spoils the way your mind is thinking. (at least mine!)I don't say sequences are not needed. But many times there can be a better way.Sorry for not having the time to write a demo vi. I will try.   Just a personal opinion.

[InfiniteNothing]

This is useful not just for timing VIs but other VIs that don't have error terminals like locals, globals, and control terminals. You can't very well wrap that concept in subVIs. 

Also, often you don't want to wire a subVI's error terminal if you want it to run regardless of errors. Currently, the solution is to to do some ugly wire branches and merges.

The wire should look different as well as the look of the connection. Maybe a green dot like the coerce dot.