Automatic Error Merging

[ragglefrock]

There's a really cool feature with Dynamic Data Type that allows you to merge signals really easily on the block diagram. Ignoring the fact that I never actually use DDT, here's how it goes:

If you wire a DDT directly onto another DDT wire, LabVIEW automatically inserts the Merge Signals function instead of producing a broken wire. Pretty cool.

It would be even cooler if LabVIEW would do the same if you wire two error wires together. LabVIEW could insert a Merge Errors function that actually scales to the number of error wires to be merged. It's very common to have parallel operations that both have error outputs that need to be merged. This would provide a very easy way to do so. It also seems possible since the error wire is a specific data type that LabVIEW recognizes.

[Tom Bress]

That sounds like an interesting idea. One thing you would have to watch, though, is the error priority level. When you merge errors one of them "wins" and gets passed on and the rest are lost. With the Merge Errors vi you choose the priority by deciding which error gets wired to the lower numbered terminal. With an automatic error merge you would have to rewire every time you didn't agree with the automatic result, making the automatic error merge less useful.

[ragglefrock]

QUOTE (Tom Bress @ Jul 28 2008, 02:50 PM)

That sounds like an interesting idea. One thing you would have to watch, though, is the error priority level. When you merge errors one of them "wins" and gets passed on and the rest are lost. With the Merge Errors vi you choose the priority by deciding which error gets wired to the lower numbered terminal. With an automatic error merge you would have to rewire every time you didn't agree with the automatic result, making the automatic error merge less useful.

Good point. There could be a right click option similar to Reorder Controls in Cluster. Visually, it could always be oriented such that the top error gets priority.

[crelf]

QUOTE (ragglefrock @ Jul 28 2008, 05:31 PM)

Good point. There could be a right click option similar to Reorder Controls in Cluster. Visually, it could always be oriented such that the top error gets priority.

You could affect the order based on where you click on the accepting wire (eg: if you click on the top of it then your wire will first, if you click on the bottom of it your wire will be last). This is the same concept that currently exists in LabVIEW when you right-click on a wire and "insert" a primitive. If the primitive has 2 inputs, then the existing wire will be in a different input depending on when you originally right-clicked. That's not a great explination - let me know if that's not clear.

QUOTE (ragglefrock @ Jul 28 2008, 02:11 PM)

There's a really cool feature with Dynamic Data Type that allows you to merge signals really easily on the block diagram. Ignoring the fact that I never actually use DDT...

Is the reason that you don't use it because you don't like it or because it's not available where you would want to use it? Personally, I'm in the camp of the former - the LabVEW IDE doesn't know what sort of crazy thing I'm trying to acheive, so don't automatically insert anything. For example, if I have two controls, and one of them is wired to an indicator: let's say I want the other one to got to the indicator - I usually just wire it in and then delete the (now broken) wire from the previous control (this is particulatily important when you've spent time on laying out your wires). I would not want LabVIEW to put a bundle array or build cluster in there (partly because that would mean that I'd also need to change my indicator). You ight think that the error cluster is different, and you would always want to merge errors, but that isn't always the case. IMHO, DDT is a great method for making entry into LabVIEW easier for the lab guy who just wants to get his new M-series and SCB-68 up and running, but I don't want to see it pervade any more than that.

[ragglefrock]

QUOTE (crelf @ Jul 28 2008, 05:11 PM)

You could affect the order based on where you click on the accepting wire (eg: if you click on the top of it then your wire will first, if you click on the bottom of it your wire will be last). This is the same concept that currently exists in LabVIEW when you right-click on a wire and "insert" a primitive. If the primitive has 2 inputs, then the existing wire will be in a different input depending on when you originally right-clicked. That's not a great explination - let me know if that's not clear.

Is the reason that you don't use it because you don't like it or because it's not available where you would want to use it? Personally, I'm in the camp of the former - the LabVEW IDE doesn't know what sort of crazy thing I'm trying to acheive, so don't automatically insert anything. For example, if I have two controls, and one of them is wired to an indicator: let's say I want the other one to got to the indicator - I usually just wire it in and then delete the (now broken) wire from the previous control (this is particulatily important when you've spent time on laying out your wires). I would not want LabVIEW to put a bundle array or build cluster in there (partly because that would mean that I'd also need to change my indicator). You ight think that the error cluster is different, and you would always want to merge errors, but that isn't always the case. IMHO, DDT is a great method for making entry into LabVIEW easier for the lab guy who just wants to get his new M-series and SCB-68 up and running, but I don't want to see it pervade any more than that.

Merging error wires based on where you click is a great idea.

I'm not a fan of express VIs for a number of reasons. I don't want to imply that this Wish List idea is an extension of express VIs. It should just be an editor ease-of-use concept.

I personally dislike express-stuff because I don't think it really teaches people how to fully use LabVIEW. There's very much a limit of what you can do with express VIs, and once you reach it, you aren't really prepared to start programming with "normal" LabVIEW functions. You don't have a good concept of bundling, unbundling, arrays, etc. I'm sure I could explain that better, too.

What else would you expect to happen when you wire one error wire into another besides merging them? (Actually, I think I may have answered my own question. It's common to do this when inserting a function between two others already connected by an error wire.)

[Louis Manfredi]

Hi Folks:

My 2 Cents:

Certainly agree with Crelf-- I wouldn't like to see merge errors autoinserted. Occasionally, but rarely, I merge error streams from parallel paths. Much more frequently I'll add a sub-vi in the middle of a chain of stuff tied together by the error wires. Usually do this by ploppiing the new vi down near the error wire (and often a handle wire of some sort) wiring both the input and the outputs, then cutting the short circuit between input and output, then drag the new vi into line. Not sure this is the easiest way to do an insert, but its the way I normally use, and autoinserting a merge error vi would be a real annoyance for me.

Not sure that I agree that Express vi's are poor learning tools. As an experienced user I find them very handy for learning how to do something new, and same true I think for new users. I just caution new users to use them only as an example of how to do something, and not as examples of proper LabVIEW programming style, since, like many other NI examples, the style is often atrocious. And obviously you usually should throw away all the code in cases you're not selecting, but I don't see that as a problem since it is a chance to learn other ways that things could be done in other situations.

Best, Louis

[Tom Bress]

I started a a student LabVIEW users group here at Michigan (it's called M-SLUG). When I tell students about "normal" DAQ VIs and Express VIs I use the stick shift/automatic transmission analogy. An automatic transmission makes decisions and takes actions for you, a stick gives you more control and more performance. Students appreciate the Express VIs, they are usually trying to "learn LabVIEW" to build one specific, often quick and dirty, application for a research or team project and Express VIs make the DAQ part of their projects easier. Personally I avoid them because it is too difficult to change the configuration parameters programatically.

[crelf]

QUOTE (ragglefrock @ Jul 28 2008, 06:27 PM)

What else would you expect to happen when you wire one error wire into another besides merging them?

To break the wire - see my previous example here (I do this a lot).

QUOTE (Tom Bress @ Jul 29 2008, 09:33 AM)

I started a a student LabVIEW users group here at Michigan (it's called M-SLUG).

Completely off topic (sorry) - by "at Michigan", do you mean "at Michigan University"? Dan Shangraw runs SEMLUG (South-East Michigan LabVIEW User Group) in Livonia - there might be opportunities to network the synergies...

[eaolson]

QUOTE (crelf @ Jul 29 2008, 11:00 AM)

To break the wire - http://forums.lavag.org/Automatic-Error-Merging-t11502.html&view=findpost&p=49075' target="_blank">see my previous example here (I do this a lot).

Agreed, I do this a lot too, mostly when I need to insert something I forgot between two other elements.

I especially don't like the idea of having to worry about, not only what I click on, but from what direction the mouse approaches the thing I'm connecting it to. Maybe I'm just a bad mouser, but having to worry about whether I'm clicking two pixels above or two pixels below where I want to click would drive me nuts. (I'd hate those mouse touch-surfaces even more than I do now.) What happens if you connect the wire at a bend?

[Tom Bress]

QUOTE (crelf @ Jul 29 2008, 12:00 PM)

To break the wire - see my previous example here (I do this a lot).

Completely off topic (sorry) - by "at Michigan", do you mean "at Michigan University"? runs (South-East Michigan LabVIEW User Group) in Livonia - there might be opportunities to network the synergies...

Yes, the University of Michigan, Ann Arbor. I met Dan at the last Developer Education Day in Livonia. There might be some opportunities there, but I think our typical members have different backgrounds and needs. The membership of my group is transient and there is a broad range of experience. UM doesn't offer a LabVIEW course, so most of the students who have come to the meetings are looking for very basic instructions on how to get started. That's why I'm taking the Professional Instructor training at NI Week. I would like to offer the official LabVIEW courses on campus (with NI's permission) as a kind of "LabVIEW Bootcamp" for students who need assistance but don't want to spend an entire semester getting up to speed.

[crelf]

QUOTE (Tom Bress @ Jul 29 2008, 04:00 PM)

I would like to offer the official LabVIEW courses on campus (with NI's permission) as a kind of "LabVIEW Bootcamp" for students who need assistance but don't want to spend an entire semester getting up to speed.

Great idea - let me know if you need a hand. Another great preson to talk to is Ben at http://www.labviewmastery.com' rel='nofollow' target="_blank">www.labviewmastery.com.

[Yair]

QUOTE (Tom Bress @ Jul 29 2008, 04:33 PM)

I started a a student LabVIEW users group here at Michigan (it's called M-SLUG).

Good thing you didn't call it G-SLUM. :laugh: