[LV2013] Saving probes ?

[Kochise]

Hi,

used to have my 'watches' saved in my project files

under Visual Studio or Eclipse (or whatever modern

IDE) I'm wondering if I missed an option to check

in Labview to get my probes saved before Labview

exit/crash. The breakpoints are saved though, so I

expected the probes to be too.

Because each time I restart Labview (on the morning,

after a crash or when I change of project)  I have to

set back a couple dozens of probes before doing

some actual work.

It is annoying.

David Koch

[Hooovahh]

---

@Kochise wrote:

It is annoying.

---

I agree, but at the moment that is how it is.  Breakpoints are saved with the VI, but probes aren't saved anywhere.  If this isn't on the idea exchange yet, it should be.  I'd suggest it be saved with the VI, but I wonder if saving it with the project would be a better design.

[Kochise]

My old Visual C 6.0 from 1998 save them in

the project file, so that when I share it or save

it on git, I can get them back.

BTW on C/C++ IDEs, they are not numbered,

they just represent the variable name with the

right data type, minus some trouble like in

GDB :

https://sourceware.org/bugzilla/show_bug.cgi?id=12134

https://sourceware.org/bugzilla/show_bug.cgi?id=16441

https://sourceware.org/bugzilla/show_bug.cgi?id=18702

They also provides multiple tabs to sort your

watches/probes according to the context in

which you want them to be.

But since Labview is not tab-compliant, unlike

Testand, I bet that they will still be numbered

automatically like before, without the ability

to sort them one closer to another if they are

geographically close yet you added one long

after.

Well, I'm soon leaving the Labview/Testand

world so it doesn't bother me anymore to

have a 18 yo features present in other IDEs

implemented when NI would ever care. If

they do.

David Koch

[Hooovahh]

Goto has been around since the 70s and LabVIEW doesn't have that feature, would that be considered a weakness of the programming language?

Some times features from other languages don't translate from a texted based to graphical based.  One such feature is if you only had labels on the probe and not numbers, then you would likely have duplicate labels, since you are probing around in multiple subVIs.  How would you suggest sorting them, by label?  That seems like a terrible idea since I care less about the name associated with the data, and more about where the probe was placed, like in what subVI.  Which today LabVIEW does.

Probes could be better, custom organizing of probes, possibly breaking up into custom tabs, moving the probes around into specific way then being able to capture those settings to get later (probably in the project) seems like a good idea.  If you want to actually make LabVIEW better post this idea on the idea exchange, if you don't really care and just want to complain then you're welcome to do that too.

[Kochise]

Between Goto and an essential debug feature, the choice

is rather easy to do.

That Labview have none of them is kind of sad.

I'm a customer of Labview, a programming language, I'm

not here to debug it and/or implement essential features

that have been around for decades.

Keep in mind that Labview started in 1986 and that NI

charge premium prices to deliver a product that haven't

evolved much in between (gui the same, bugs the same,

etc)

As I said before, the Idea exchange is already full of

suggestions that yet have not been implemented for

years, so I will see what I can use for the next project.

Thanks for the advice though.

David Koch

[Hooovahh]

Is this what we're going to do today?  What you call "essential" I call an improvement.  Can debugging be done without whatever it is you are suggesting?  Yes and it has been done on very large scale applications, with the tools available, so I'd hardly consider it essential.

You are a customer, and unlike other products you buy you have an influence over the type of feature it can have.  Last time I checked I couldn't suggest GM add a VHS player to their new vehicles and have a public forum where others can have a dialog about my suggested feature.  It's an amazing privilege that will help make a better product for everyone.

---

@Kochise wrote:

Keep in mind that Labview started in 1986 and that NI

charge premium prices to deliver a product that haven't

evolved much in between (gui the same, bugs the same,

etc)

---

Right because the project explorer, object oriented code, scripting, VI server, multi platform development for FPGA, RT and other platforms using the same source, DVRs, classes, libraries, event structure, are all the same product that doesn't evolve.  Heck I could just read off the release notes from any LabVIEW version and have a list of constant improvements.  Some not as major as adding the event structure but you can't say it isn't ever evolving.

---

@Kochise wrote:

As I said before, the Idea exchange is already full of

suggestions that yet have not been implemented

---

And it's also full of ideas that have been implemented.  I'm so grateful to the developers who put a bug in NI's ear with a feature that I use daily.

[Kochise]

Right. I never said Labview is useless and debug

cannot be done without a more user friendly interface,

after all people used to code using notepad and

debug using printf or cout.

That Labview leverage coding on PC, RT, FPGA

is a good thing, but that the UI, the very interface

between the coder and the code, haven't quite

changed for a long time to improve a bit, is sad.

But you know me now, I always complain. Mostly

because the forum is here to voice ourself when

something doesn't work. Rarely to thanks all the

people involved in the development of LV.

BTW, here's my little contribution to LV, something

that saves my ass on a regular basis 🙂 If you want

to add them to LV, go for it...

David Koch

[James.M]

I don't see probe-saving as a very common need for most developers. You should be designing your application around what the users (maybe you?) need to see as you're going along, so your main interface should have the data you need instead of having to dive in to subVIs to probe. Probes are a great debugging tool as you're developing parts of your application, but you shouldn't need to probe in a whole bunch of different places every time you open your project. If you are, that probably means you need to compartmentalize your code development better.

My probing usually works like this:

1. Plan new feature
2. Create subVI(s) where needed
3. Test subVI functionality on the subVI level using probes
4. Run top-level if needed
5. Ins-outs are now confirmed, so probes can be closed
6. Go back with new probes if a bug is found later
7. ???
8. Profit

A cheap workaround for saved probes is the implementation of global variables where needed. Now your global variable FP is your probe window.

[Hooovahh]

The only reason I mentioned debugging itself not being broken, is because you called the feature that was missing essential, but whatever.

If we want to critique LabVIEW UI and interaction, then that is something I can get behind.  Not because it is broken, but because it is dated, and innovations haven't been seen as much.  If you want to talk about not evolving then lets:

Since LabVIEW 1.0 there is exactly one front panel and one block diagram for every VI.  Every control on the FP has exactly one terminal on the BD.  Every FP is its own floating window, and every BD is its own floating window.  The only way to provide inputs and outputs to a VI is through the connector pane, connecting to controls.  Icons on the BD for calling a subVI must be represented in a 32x32 icon (with few exceptions).  Window resizing is primarily done by splitting the UI into panes, and resizing control in each pane.

I'm not saying any of these statements are holding the language back, but some how I doubt that there haven't been improvements in UI and UX in the last almost 30 years, that LabVIEW couldn't benefit from.  Were the creators of LabVIEW so far ahead of their time that this is a perfect way to develop graphical code?  Probably not.  Focus has been on other things like APIs, compiler optimizations, tools, and hardware platform development.  Is 2015 the year of the UI? Doesn't look like it, lets hope for 2016.

Back to probes a bit, I agree that they usually are a temporary thing.  Test my module and I no longer need them.  But I could see them useful for debugging some APIs.  Lets say you download driver for some USB power supply control.  If I ran the example and probes were already made to where messages came in and out, I could see some benefit to that when the example breaks.  At the moment if I run and it generates and error I need to start probing, usually with wires retain values, to figure out where the error is coming from, and what inputs caused that error.

Also thanks for sharing your code but what does it do?  Something with SQL?

[tst]

I agree with the others that I don't feel the lack of the probe saving. I simply don't use probes that much and certainly not persistent ones.

If you really want this, you could write a plugin (let's say a Quick Drop plugin) which would iterate over all the wires in the current VI (or all open VIs) and set a tag on each wire to mark the presence of a probe (or remove the tag if the wire has the tag, but no probe). Then run another plugin to iterate over the wires and open a probe for each wire that has the tag and no open probe. I would estimate 5-15 minutes to write this.

This won't be as convenient as you like. It's not automatic (although there are ways of running things like this in the background). If you're going to do more than one VI, the traversal might take time. I'm sure you can find other faults as well, but it should work and since tags are saved with VIs, this should persist with the VI, so there's that.