LabVIEW Idea Exchange

Please let me know if something like this exists, but I can't seem to find anything.

What I want is a tool to automate some of my subVI building and implementation. There are a few repetitive things I do during development that would be optimized if I was able to build a custom macro to complete these things with some simple customizing inputs.

Here is my scenario:

I have API for each module in my application. Each API VI passes an "Action" enum along with varient data. The "Action" enum is a type-def and the API uses the module's queue reference to pass the action and data to the main module VI.

Every time I want to create a new API VI for a module I have to complete the following steps:

Open a previous made API VI (or template API VI if I want to make one)

Save As my new API (i.e. ReadData.vi)

Open "Action" type-def enum

Edit Items of enum

Add "ReadData" option to enum

Close "Action" type-def

Change Action in API to ReadData

Change Icon in API to match

Save and Close

The only changing variables in my situation are:

Which module for which to create the API

Action name for th enum

This seems like the ideal application for a macro similar to an excel macro or other languages.

Thanks for reading!

Grouping objects on the front panel is helpful to avoid inadvertently destroying a UI's layout.

Unfortunately it comes at a cost: if you want to access block diagram counterparts of any of the objects in that group, you have to first ungroup them, select the object of interest, right-click and select what you are looking for, go there... and hope you won't forget to regroup the objects when you are done.

Surprisingly, you can actually access an individal's object properties and in fact access pretty much any of the right-click contextual menu items BUT the "Find" one. So no "Terminal", "References", "Property Nodes", "Invoke Nodes", Local Variables" access...

Why?

If there is no fundamental reason for this, please consider this as a request.

What I'm suggesting is a combination of an textring and a string control (BD-terminal is a string). The idea behind is, that I like to offer the user a list of pre-defined values (e.g. the values from the five latest program runs) but also the ability to enter a new string.

Of course I can get this functionality by adding two separate controls or by combining those in an XControl but I feel the combination would look better, is much easier to handle in the code and needs less space on the UI.

Please see the picture for better understanding.

Hello all,

The best summary of this idea I can come up with is:

When isolating errors in inheriting classes, the "Error list" window needs improvement so that it is easier to find the root cause of "cascading," hierarchical errors.

I debated whether to post this one, as it's somewhat difficult to explain, and please bear with me as I'm describing the issue from memory and might get a couple of details wrong.

Here it goes:

In many cases I find it difficult to isolate errors in LVOOP classes, especially when I have a hierarchy of several inheriting classes, and even more so when employing dynamic dispatch VIs.

Here's how things might proceed:

• I have a broken run arrow for one of my class method VIs, but the VI reports that class is broken.
• I bring up the error window by right clicking on the broken class and selecting "Show Error Window"
• The "Error list" window contains myriad errors, some of which pertain to the class I'm working on
• All or most methods in the class have errors listed because the class has a broken dynamic dispatch VI
• Inheriting classes with the same dynamic dispatch VIs also report copious errors, citing one or more dynamic dispatch instances of that VI being broken.
• I go up and down the class hierarchy trying to figure out which method is actually causing the error fest
• And on and on it goes...
• In the end, I have so many "false alarm" errors that point in all directions, effectively making the error window almost useless.

At this point, I trace my steps backward to figure out what I did that caused massive cascading error mayhem.  Yet, it would be fantastic if the error list window somehow detected the offending method that is behind all of the cascading errors.  I don't know what this would look like, but I would love any improvement in this area.

Maybe someone's posted something similar, but I couldn't find it.

Alright, I know everyone is now asking, "What the heck is he trying to say?!"    That is my best attempt.  Feel free to summarize it more succinctly.

Thank you for reading this giant missive.

Jim

As a debug tool, it would be incredibly helpful for me if I could pause at a certain point in the code when a value meets a certain criterion, without having to edit the code.

This functionality already exists as the "condition" tab for an error cluster in the Probe Watch Window, but does not exist for any other type of data.  (In the image below, I'm showing that the "condition" tab will enable me to pause execution when the data on the error wire I've probed is updated, and the "error" boolean of that cluster is TRUE.)

In other words, I'd like to see this behavior become more robust/flexible for other data types.  The alternatives are:

1. In run mode, put in an unconditional break point somewhere in the code, and manually step through the code as I watch the probed wire of interest update to the value of interest, so that I can continue debugging - or

2. Stop the VI an all the VIs which are running on top of it, and in edit mode, create a case structure which evaluates as TRUE whenever the wire of interest is updated with a value I care about (as in this image):

The problem with #1 is obvious - lots of lost efficiency.

There are several problems with #2, being that you must enter into edit mode for this work-around to debug your code:

• I may be inheriting a lot of complex code for which the architecture is already pre-determined, so I cannot effectively influence the VI hierarchy to make this kind of breaking work-around for debugging convenient
• I may have some other design constraint that requires me to makes breaking in this work-around inconvenient.
• There may be a lot of data which is loaded/unloaded dynamically by the VI, so this is lost efficiency.  Perhaps I'll need to wait hours or days for the same data to occur, such that the code is back into the same state where I can take the next step.
  (There's never a guarantee that putting in just the one brekapoint will be sufficient to capture everything I need to know to debug, so this just gets me one step closer to finding out what kind of edits I need to make next, to further debug.  That iterative process would be much easier if I didn't need to enter "edit" mode.)
• I must often make changes to my data flow in order to ensure this debugging pauses at the correct instant in time, since the value I am waiting for probably influences something later on in the code that I want to watch with Highlight Execution or whatnot.
  (e.g. above image, I cannot simply branch off of the I32 data wire to create this case structure/breakpoint work-around.  I must re-route the wire through each case of the case structure, or something equivalent, to enforce that I break at the appropriate time.)
• VI recompiles due to edits
• Lots of clicking to set this up
• I must go back and undoall the edits to the code again to put it into its original state once debugging is finished.

So here's what I'd like to see:

Other considerations:

1. Obviously, we can be all sorts of creative and crazy on the implementation, asking what-ifs for if you want to pause for multiple values, or an array of values, or whatever.  That's not the 90% use case.  I really only care about pausing with one, simple comparison on one primitive value (like boolean, string, integer, and floating point.) The kind of comparison would depend on the data type under investigation (e.g. you probably wouldn't need greater than, less than, etc. for boolean, and may not need them for string.)
2. Let's say hypothetically someone implements this, and lots of people begin using it.  THEN maybe you could consider adding support for non-primitives, such as a clusters and arrays of primitives - but I make no suggestion of how to handle those in the probe watch window.  Doing comparisons on arrays would require more processing, and at that point I think the coder is on his/her own put the right hooks into the code to pause and debug when something doesn't look right.
3. Something I could see a more immediate use for - pause in another area of the code based on an update to a wire value.  So in other words, lay down a breakpoint in one VI, and set it to conditionally pause based on a value in another VI.  This brings up a synchronization/communication problem that could possibly be resolved by setting a flag from one VI when the value updates, and when the breakpoint of the other VI recognizes that flag, it activates upon execution.  I'm sure that's more complex than my above suggestion, though.
4. Perhaps you could do something like this with an X control (I'll admit I don't know much about them), but that requires a preconceived notion of whether or not I'll ever need to debug by pausing for a certain value on that data type.  Also, I don't really feel like creating a custom control for an I32, just so I can try to future-proof all of my debugging.

I'd like the ability to add a title to the one-button, two-button, and three-button dialog boxes that pop up. I thought of an easy way to implement them: add another entry to the "right-click->Visible Items" menu on the BD for the dialog VIs called "Visible Label in Title Bar". It would quite simply do just that; whatever you put in the label field would show up in the title bar as the title. Easy!

Of course, a  "caption" property could be added with "Visible Caption in Title Bar" instead, to preserve label functionality...

Or a "title" property could be added... with the ability to make it visible...