PA-Paul Posted February 26, 2009 Report Share Posted February 26, 2009 I was just doing some coding and getting information out of a property node, and it struck me that, from a style point of view at least, property nodes are upside down... Having recently read Peter Blume's Labview style book, one of the big conventions seems to be that error clusters should wire in an out of the bottom of subvis... So why do we have to wire errors in and out of the top of property nodes? I like my code to have a nice continuous error line somewhere near the bottom, but as soon as you start dealing with a few properties from one node, you can't do that neatly anymore. Wouldn't it make sense for the base part of the propery node (i.e. the class label) to be at the bottom with the error, and then you could open the properties terminals upwards... Anyways, I probably just have too much time on my hands! Paul Quote Link to comment
crelf Posted February 26, 2009 Report Share Posted February 26, 2009 QUOTE (Ic3Knight @ Feb 25 2009, 09:32 AM) ...one of the big conventions seems to be that error clusters should wire in an out of the bottom of subvis... Another big convention is to have references wire in and out of the top of subVIs. QUOTE (Ic3Knight @ Feb 25 2009, 09:32 AM) I like my code to have a nice continuous error line somewhere near the bottom, but as soon as you start dealing with a few properties from one node, you can't do that neatly anymore. Are you talking about statically linked or dynamically linked property nodes? Quote Link to comment
PA-Paul Posted February 26, 2009 Author Report Share Posted February 26, 2009 Statically (I think?!), I've attached a picture of the code I was just working on as an example... Its part of a bigger application to control a system which contains a DAQ device. Since there is a possibility that my system will be connected to a PC which already has a DAQ device attached, I use the serial number of mine to find the device name and then populate a cluster of channel names which I'll use later on in my code.... Anyways, you end up having to do several operations below the "error line" which I don't like (although functionally it doesn't matter obviously!) Anyway, as I was say its just something that struck me, I have to admit, I didn't think it through a huge amount!! Cheers! Paul Quote Link to comment
shoneill Posted February 26, 2009 Report Share Posted February 26, 2009 QUOTE (Ic3Knight @ Feb 25 2009, 04:18 PM) Statically (I think?!), I've attached a picture of the code I was just working on as an example... Its part of a bigger application to control a system which contains a DAQ device. Since there is a possibility that my system will be connected to a PC which already has a DAQ device attached, I use the serial number of mine to find the device name and then populate a cluster of channel names which I'll use later on in my code.... http://lavag.org/old_files/monthly_02_2009/post-14639-1235574922.png' target="_blank"> Anyways, you end up having to do several operations below the "error line" which I don't like (although functionally it doesn't matter obviously!) Anyway, as I was say its just something that struck me, I have to admit, I didn't think it through a huge amount!! Cheers! Paul Since Property nodes are expandable imagine the mess which would be created if the error wire was dragged up and down with the lower edge of the property node..... If anything, the upper part (Refnum & Error connector) could be made larger to support the standard Connector wiring scheme spacing. Less error wire bends... Shane. Quote Link to comment
PA-Paul Posted February 26, 2009 Author Report Share Posted February 26, 2009 QUOTE (shoneill @ Feb 25 2009, 03:29 PM) Since Property nodes are expandable imagine the mess which would be created if the error wire was dragged up and down with the lower edge of the property node..... If anything, the upper part (Refnum & Error connector) could be made larger to support the standard Connector wiring scheme spacing. Less error wire bends...Shane. You can already get into that mess by dragging the top of the property node upwards... Perhaps something it should be selectable (reversible) and the size of a typical SubVI? So that you don't get error bends on the default size and you can choose whether to have the properties above or below?! Just a thought Quote Link to comment
Aristos Queue Posted February 26, 2009 Report Share Posted February 26, 2009 I recently placed an idea in front of the LV R&D team to think about: Shouldn't error terminals be moved -- on all nodes -- to be the top terminal of all nodes? That is the one consistent location that you could then string an error wire across between functions, regardless of type. Then if you have a second type that is railroading along side the error code, have it running in the second-from-the-top terminal. This means that you have one side of your node that you can get values to the other terminals without crossing your two railroad track wires, and your nodes can stay top aligned to minimize bends in the error wire. Yeah, it'd be a big change to the diagram to do it today. But if we didn't have 20 years of diagrams, wouldn't that be a better strategy? Quote Link to comment
crelf Posted February 26, 2009 Report Share Posted February 26, 2009 QUOTE (Ic3Knight @ Feb 25 2009, 10:18 AM) Statically (I think?!), I've attached a picture of the code I was just working on as an example... Yep - that one's static (there's no reference terminal). QUOTE (Ic3Knight @ Feb 25 2009, 10:53 AM) You can already get into that mess by dragging the top of the property node upwards... Yep - I think both approaches are equally valid, but NI just choose one way over another. I still prefer the reference/error clusters where they are, as they define the object, whereas the expandable nodes are methods/properties of that object. IMHO, I think it should stay the way it is, but it's always good to try to think outside the box every now and then Quote Link to comment
shoneill Posted February 26, 2009 Report Share Posted February 26, 2009 QUOTE (Aristos Queue @ Feb 25 2009, 05:15 PM) I recently placed an idea in front of the LV R&D team to think about: Shouldn't error terminals be moved -- on all nodes -- to be the top terminal of all nodes? That is the one consistent location that you could then string an error wire across between functions, regardless of type. Then if you have a second type that is railroading along side the error code, have it running in the second-from-the-top terminal. This means that you have one side of your node that you can get values to the other terminals without crossing your two railroad track wires, and your nodes can stay top aligned to minimize bends in the error wire.Yeah, it'd be a big change to the diagram to do it today. But if we didn't have 20 years of diagrams, wouldn't that be a better strategy? Ding! That's the right Idea I think, even though upwards expansion of property nodes still messes up wires but it'd be an improvement. It'd cause a stir and it'd take some getting used to though..... Shane Quote Link to comment
Antoine Chalons Posted February 26, 2009 Report Share Posted February 26, 2009 QUOTE (Aristos Queue @ Feb 25 2009, 05:15 PM) I recently placed an idea in front of the LV R&D team to think about: Shouldn't error terminals be moved -- on all nodes -- to be the top terminal of all nodes? That is the one consistent location that you could then string an error wire across between functions, regardless of type. Then if you have a second type that is railroading along side the error code, have it running in the second-from-the-top terminal. I agree with that ! QUOTE (Aristos Queue @ Feb 25 2009, 05:15 PM) Yeah, it'd be a big change to the diagram to do it today. But if we didn't have 20 years of diagrams, wouldn't that be a better strategy? That is certainly a strong reason not to make the change... how did LV R&D people reacted to this idea ? Quote Link to comment
Justin Goeres Posted February 26, 2009 Report Share Posted February 26, 2009 QUOTE (Aristos Queue @ Feb 25 2009, 08:15 AM) I recently placed an idea in front of the LV R&D team to think about: Shouldn't error terminals be moved -- on all nodes -- to be the top terminal of all nodes? That is the one consistent location that you could then string an error wire across between functions, regardless of type. Then if you have a second type that is railroading along side the error code, have it running in the second-from-the-top terminal. This means that you have one side of your node that you can get values to the other terminals without crossing your two railroad track wires, and your nodes can stay top aligned to minimize bends in the error wire. The worst part of this idea, in my opinion, is that it would've made a really great April Fool's joke. And now you've used it all up . Quote Link to comment
Rio C. Posted February 26, 2009 Report Share Posted February 26, 2009 QUOTE (Aristos Queue @ Feb 25 2009, 09:15 AM) I recently placed an idea in front of the LV R&D team to think about: Shouldn't error terminals be moved -- on all nodes -- to be the top terminal of all nodes? That is the one consistent location that you could then string an error wire across between functions, regardless of type. Then if you have a second type that is railroading along side the error code, have it running in the second-from-the-top terminal. This means that you have one side of your node that you can get values to the other terminals without crossing your two railroad track wires, and your nodes can stay top aligned to minimize bends in the error wire.Yeah, it'd be a big change to the diagram to do it today. But if we didn't have 20 years of diagrams, wouldn't that be a better strategy? While you're at it if you're going to change the error terminals it may also a good recommendation to change the error cluster... into a class. Quote Link to comment
crelf Posted February 26, 2009 Report Share Posted February 26, 2009 QUOTE (Rio C. @ Feb 25 2009, 01:09 PM) While you're at it if you're going to change the error terminals it may also a good recommendation to change the error cluster... into a class. That's a definate thread hijack right there - please start a new thread to continue that discussion. Quote Link to comment
bsvingen Posted February 26, 2009 Report Share Posted February 26, 2009 Or better, make the error wires invisible. Seriously, they mess up the diagram wile serving only an implicit function that distracts away from the flow of data. I mean, LV is dataflow - not errorflow. There could be a switch that makes them visible/invisible, and the connectors could be "filled" when a wire is connected and unfilled when not. Quote Link to comment
crelf Posted February 26, 2009 Report Share Posted February 26, 2009 QUOTE (bsvingen @ Feb 25 2009, 02:11 PM) LV is dataflow - not errorflow. Errors are data too. Quote Link to comment
bsvingen Posted February 26, 2009 Report Share Posted February 26, 2009 QUOTE (crelf @ Feb 25 2009, 08:20 PM) Errors are data too. He he, funny Yes, but everyone knows what that data is... It is only when debugging that the data in those wires are of any interest, if at all. The main purpose of those wires are to transport errors away to an error handler of some kind. Quote Link to comment
crelf Posted February 26, 2009 Report Share Posted February 26, 2009 QUOTE (bsvingen @ Feb 25 2009, 03:10 PM) It is only when debugging that the data in those wires are of any interest, if at all. The main purpose of those wires are to transport errors away to an error handler of some kind. I don't agree - I make a lot of decisions in my code based on what's in the error cluster, even before it gets to an error handler. Quote Link to comment
MikaelH Posted February 26, 2009 Report Share Posted February 26, 2009 Same here, I e.g. use a special Error code for User Abort, so I can terminate a test sequence as fast as possible. //Mikael Quote Link to comment
gleichman Posted February 26, 2009 Report Share Posted February 26, 2009 QUOTE (Aristos Queue @ Feb 25 2009, 11:15 AM) Shouldn't error terminals be moved -- on all nodes -- to be the top terminal of all nodes? , wouldn't that be a better strategy? I like this idea! I would like to see the default label "(no error)" part of the error in go away. Quote Link to comment
crelf Posted February 26, 2009 Report Share Posted February 26, 2009 QUOTE (gleichman @ Feb 25 2009, 04:56 PM) I would like to see the default label "(no error)" part of the error in go away. I would only support that if it were replaced by some other method of easily seeing the default of controls. Quote Link to comment
ragglefrock Posted February 26, 2009 Report Share Posted February 26, 2009 QUOTE (bsvingen @ Feb 25 2009, 01:11 PM) Or better, make the error wires invisible. Seriously, they mess up the diagram wile serving only an implicit function that distracts away from the flow of data. I mean, LV is dataflow - not errorflow. There could be a switch that makes them visible/invisible, and the connectors could be "filled" when a wire is connected and unfilled when not. I would argue instead of this (but similar) to have error wires default to the bottom z-order of a diagram, beneath all other wires. I don't want to hide them, but I always do Ctrl-Shift-J to put them beneath all other wires. It would be awesome if this was somehow the default behavior. Quote Link to comment
crelf Posted February 26, 2009 Report Share Posted February 26, 2009 QUOTE (ragglefrock @ Feb 25 2009, 06:30 PM) I would argue instead of this (but similar) to have error wires default to the bottom z-order of a diagram, beneath all other wires. :thumbup: I like. Quote Link to comment
jdunham Posted February 26, 2009 Report Share Posted February 26, 2009 QUOTE (gleichman @ Feb 25 2009, 01:56 PM) I would like to see the default label "(no error)" part of the error in go away. It takes about a minute to go into C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\errclust.llb and remove the annoying "(no error)" part of the label (don't forget to fix both the classic and the 3D version). That's just about the second thing I do to a fresh copy of LabVIEW after turning off 'Lock Automatic Tool Selection', 'Automatic Wire Routing', and AutoGrow. Quote Link to comment
bsvingen Posted February 26, 2009 Report Share Posted February 26, 2009 QUOTE (crelf @ Feb 25 2009, 09:25 PM) I don't agree - I make a lot of decisions in my code based on what's in the error cluster, even before it gets to an error handler. Yes, but I don't see how the ability to make the wires invisible (transparent) will prevent you from doing that. I mean, this would basically be an implementation of layers, that have existed in CAD/graphical programs for decades. Quote Link to comment
crelf Posted February 26, 2009 Report Share Posted February 26, 2009 QUOTE (bsvingen @ Feb 25 2009, 07:17 PM) Yes, but I don't see how the ability to make the wires invisible (transparent) will prevent you from doing that. I mean, this would basically be an implementation of layers, that have existed in CAD/graphical programs for decades. If the wires were transparent then I wouldn't be able to look at the code and see where the data flows. That would be a big step backwards IMHO. Layers in the diagram - well, that's different, and certainly deserves further discussion... Quote Link to comment
Val Brown Posted February 27, 2009 Report Share Posted February 27, 2009 QUOTE (crelf @ Feb 25 2009, 05:45 PM) If the wires were transparent then I wouldn't be able to look at the code and see where the data flows. That would be a big step backwards IMHO. Layers in the diagram - well, that's different, and certainly deserves further discussion... Layers would be good esp if the error wire could come to the top of the z-order IF an error or warning is being propagated. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.