Make the default probes smarter

[Mads]

Custom probes are great, however unlike the default probes you do not always have them with you...so why not just make the default probes just a tad smarter? 

- The array probe e.g. should not just show a single cell - it should by default show at least some of them (1*10 for 1D, 10*10 if 2D etc. e.g.), have it's scrollbars visible and be resizable?

 You could add some core information about the array, like it's size e.g. in an indicator on the top as well....and perhaps have a pull-down menu for the display format. Keep it general and simple of course, but a bit more convenient than today's probe.

- The string probe should also be resizable and have a control that let's you switch the display format.

- etc.

[MikeS81]

Hi Mads,

why do we need this from NI? If we need it, we can make a custom probe and provide it in the LabVIEW community.

Just my thought

Mike

[MikeS81]

Addon:

You can transport your custom probes on an usb stick (if you don't want to copy them to the other pc). Create a link to your "USB-Stick probe folder" inside the "LabVIEW x.x\Probes" folder.

Mike

[Mads]

Of course you can copy custom probes from machine to machine - but does that mean that the probes that come with LabVIEW should never be improved? No. 

Message Edited by Mads on 07-02-2009 08:23 AM

[Mads]

(I would think the "You do not *always* have them with you..." - part would indicate that the suggestion was made with knowledge about the portability of custom probes.... )

Message Edited by Mads on 07-02-2009 08:37 AM

[PJM_Labview]

Good idea.

[JackDunaway]

The two that especially bite me are probing a msec timer where the last few digits (the important ones!) are cut off, and probing an array where you only see 1 element.

Here's a workaround in the meantime: you can set up a probe, right click on the probe and select "Copy Data", then paste it on an empty VI. There, you can expand the indicator, add scrollbars...

The disadvantage is you get a snapshot of the probe, not spooling data. It's brute and primitive, but works very well without needing a toolbox of custom probes. (Think on-the-spot as-needed customization mentality)

Regardless, Kudos on this idea. And the most important line from Mads: "Keep it general and simple of course, but a bit more convenient than today's probe."

[altenbach]

I agree. For 1D arrays I always use the conditional array probes, they're great. 🙂

There are some other omissions with the stock probes that should be addresses the next time somebody is working on probes.

There are many datatypes where an indicator works, but a custom probe picking the same indicator doesn't.

Some examples:

We cannot probe a 2D array with a waveform graph.

We cannot probe a complex 1D array (CDB) with an xy-graph.

Other omissions: 

There is no conditional array probe for 1D CDB, 1D I16, 1D U8, etc.

...

[AristosQueue (NI)]

We have reached a point of "minimum return on investment" for custom probes. Although there are still plenty of tweaks that could be made to the probes for individual data types, the request for improved probe functionality is but one request among a sea of requests from our users, and it is generally better for R&D to focus on the items that cannot be done by our users rather than by popularizing customizations that can be done by users. This is a constant problem for a wide range of LabVIEW features, custom probes being only one of many. As LV's existing feature list gets longer, R&D faces a constant struggle between introduction of new features (which is what drives short-term sales and upgrades), incremental improvements of existing features (which drives the perception of stability and usability and thus long-term sales and upgrades), and tuning LV for various niche customers (which drives both long and short-term).

On the custom probes front, I would suggest that instead of posting a request for R&D to improve the custom probes that instead you post individual VIs that you would like to see us ship as default custom probes. These VIs should be free from any intellectual property restrictions (read the Terms of Use [linked at bottom of page] for details about VIs that you post). Then the community can kudos individual custom probes. Collecting popular VIs and shipping them with LV is a more productive use of our time than trying to guess what the most useful customizations are and trying to ship them, hoping that the beta feedback is enough to let us know whether we got it right or not.

If you do start posting these, in order that we can identify all the ideas that are specifically new custom probes for us to evaluate, consider using the convention of naming your idea "New Custom Probe: XYZ.vi"  or "New Custom Probe: XYZ.llb" (the second for times when you have a whole batch of custom probes in a single idea... they should generally be on related data types or else be posted as separate ideas). If you take this route, I think you'll have a lot more success both at getting R&D to pick up the idea AND at getting custom probes added that you actualy find useful. 

Just to be clear: I'm not saying R&D has no responsibility for improving the probes. We do. But our attention over time becomes more and more divided, and having the community post the VIs themselves rather than us developing those VIs is more likely to be a successful strategy in the short run than waiting for enough issues to pile up such that it becomes a top priority worthy of allocating an R&D developer to the project.

[Mads]

You sound like you are tired of all the nagging from the customers;-)

The posted idea and the responses so far has not requested any new features or major changes, and it's not about custom probes...It's about very small adjustments to the *default* probes. No rocket science...no great disputes on how they should be.

I'm sure you've gotten lots of requests for things that people could make and make public themselves, this is no such request. I think making this a competition would cloud the issue (people are already free to post their code anyway) - which is the fact that some very minor adjustments would improve the usefulness greatly. The rest is fully covered by the custom probe option which is available already.

[altenbach]

I agree, making custom probes is no rocket science and I am typcally happy to make my own. Especially if they are based on an existing probes, things are quite easy. 🙂 Looking at my probes folder, I have a few integer probes that display in zero padded binary and some other useful stuff.

I am not fully familiar how versioning is handled in terms of probes. For example, I still have some 8.0 probes in the probes folder, and they work just fine within LabVIEW 8.6, but once they are saved in the new version, older LabVIEW versions can no longer use them. I would assume that very old probes also no longer work, once the upgrade step is too far.

Having an online depository of useful custom probes is a great idea. It could even be integrated into the LabVIEW UI. For example, the right-click custom probe menu could have a fifth entry that points to the "cloud" at NI with some nice preview interface (or also to some shared local resource within a company as configured). Dowloaded probes would be cached locally and updated as needed if new versions are posted.

There are general improvements possible that would make creating custom probes easier: For example, the wizard to create a custom probe from an existing probe is very cramped. The list of existing probes is a "stamp sized" list that gives me tunnel vision. The entries seem to be in no recognizeable order (What is the order???).

The interface should be resizeable so it can be used more comfortably. There should also be a sorting and a search function, similar to the palette help or quick drop to more easily browse the list of existing probes.