Introducing... Darren's Weekly Nugget! 1/16/2006

[Ben]

JLV wrote

"Did you say 8 times????"

Yes Sir!

The example I posted should demonstrate this.

That performance would probably drop off if the string you are looking for is short (and fail if the string is a single characrter?).

But is seems that the longer the string you are trying to match is the better it should perform (relative to the brute force approach).

Ben

[Ray.R]

Interesting...

Wow... these Nuggets are very useful..   I am now looking forward to next week's.. 

😄

Thanks Ben & Darren for the info!

[K1200LT_rider]

---

@Darren wrote:

... if you hold down "Ctrl" when you double-click a subVI, both the front panel AND the block diagram of the subVI will open. ...

---

I like doing this, but it has bitten me a few times.  I look around at a lot of subVIs sometimes in our large application.  The first learning experience I had with this potential problem was when I suddenly and mysteriously had a broken run arrow when I wanted to run it.  The error list said that a particular subVI had an unwired input that was "required".  It was very obviously wired (visually, anyway!).  It drove me crazy until I decided to move the icon to see what happened to the wire.  I just about fell over when I saw I had moved a copy of the subVI that had somehow been placed perfectly on top of the original subVI.  After thinking about it, what must have happened was when I Ctrl-double-clicked the icon previously to look at the code, I had inadvertently made a copy of it and never noticed it (Ctrl-drag is what is supposed to create a copy).  Seems to me that the Ctrl-drag algorithm in LabVIEW needs to be adjusted a little so a copy can't be made so quickly and unnoticeably.  Then again last week the same problem happened again, only this time it was not easy to track down at all because this particular subVI had no "required" inputs to give me a broken run arrow!  When I ran the main application, I would get errors that were suddenly very confusing and didn't make sense.  I had placed several of my troubleshooting "Trace Logging.vi" calls in the area of concern and found by looking at the Trace Log file that certain code seemed to be executing twice.  After hours of frustrating troubleshooting I finally happened to move the duplicated icon and couldn't believe it happened to me again.  From now on I am making my subVIs with a required input if possible.

Has this ever happened to anyone else???  NI: Could somebody please tweak some code so this can't happen?  It would be GREATLY appreciated.

- Brad

[Darren]

Hi Brad,

You should file a request at the Product Suggestion Center that this issue be addressed in a future LabVIEW version.  For now, you could run the VI Analyzer on your VIs and the Wires Under Objects test would have detected that you had an object (in this case, your copied subVI) overlapping wires (in this case, the wires that are connected to the hidden subVI).  The Wires Under Objects test is one of the best in the entire suite of tests in the VI Analyzer when it comes to detecting problems in your code that are difficult to detect with visual inspection.

Good luck,
-D

[K1200LT_rider]

---

@Darren wrote:

Hi Brad,

You should file a request at the Product Suggestion Center that this issue be addressed in a future LabVIEW version.  For now, you could run the VI Analyzer on your VIs and the Wires Under Objects test would have detected that you had an object (in this case, your copied subVI) overlapping wires (in this case, the wires that are connected to the hidden subVI).  The Wires Under Objects test is one of the best in the entire suite of tests in the VI Analyzer when it comes to detecting problems in your code that are difficult to detect with visual inspection.

Good luck,
-D

---

Thanks for the info - I'll definitely file that request at the Product Suggestion Center.  About the VI Analyzer - I wish I had it.  If I'm brave enough to ask my boss for it, I'll stand behind something in case he throws something at me.  He's been very jaded at the high cost of NI software that is already on this one and only LabVIEW test station that I am maintaining the code for.  Unfortunately, I don't think any new test stations we buy or build will be run by LabVIEW.  Bad news for me since I don't really look forward to taking a step backward by having to deal with test stations running on C++ or Visual Basic.

- Brad

[Darren]

Hi Brad,

Sorry to hear that...perhaps you could explain that the $995 cost of the VI Analyzer could easily be made up in lost debugging time within a matter of mere months!  😛

-D

[Ben]

Darren wrote;

"perhaps you could explain that the $995 cost of the VI Analyzer could easily be made up in lost debugging time within a matter of mere months!   ".

Well in the case of in-house staff that are already salary, their time is often viewed as being "free" (because extra effort by them cost $0 ).

So

$995 / 0 = +Inf

Most of us will be retiring before then.

Ben

[Khalid]

I got bit by this last week. My sub VI did not have any required inputs. I spent hours trying to figure out what was wrong. It was actually funny, now that I think about it: In execution-highlight mode, I would go through the sub VI succesfully and come out of it. But on the main diagram I could see that the subVI still had the green running arrow on it! I thought I was losing it until it dawned upon me 🙂

Yes, just submitted a suggestion to not invoke the Ctrl+Drag action unless the mouse is moved by an obvious amount.

-Khalid

[elkag]

First off, GREAT thread and new feature.  I've already learned about 4 new tips and tricks and things to watch out for just in this one thread.

Re:  Brad's note:

"Thanks for the info - I'll definitely file that request at the Product Suggestion Center.  About the VI Analyzer - I wish I had it.  If I'm brave enough to ask my boss for it, I'll stand behind something in case he throws something at me.  He's been very jaded at the high cost of NI software that is already on this one and only LabVIEW test station that I am maintaining the code for.  Unfortunately, I don't think any new test stations we buy or build will be run by LabVIEW.  Bad news for me since I don't really look forward to taking a step backward by having to deal with test stations running on C++ or Visual Basic.

- Brad "

I hate reading about workplaces that have such attitudes because I've worked at such places, and the people running or owning such places are fighting a losing battle trying to keep those legacy languages going.  Point out to your boss that the future of PC's and test stations is going to be multi-core processors and that only LabVIEW is set up inherently to take advantage of those capabilities without ridiculous amounts of extra code to keep things in separate processing loops.  That individual may have no interest in hearing about it, but the better language will win in the long run.

All the best.

- Eliot

[Darren]

So nearly two and a half years later, I'm looking back on this nugget and doing a little investigation.  It turns out that Ben did his Search/Split String benchmarks in LabVIEW 7.1, which, indeed, are accurate...the Search/Split String trick definitely increases the speed of a simple string search.  However, the performance of the Match Pattern function was greatly improved in LabVIEW 8.0.  You will see the performance increase that Ben describes pretty much disappear in LabVIEW 8.0, and in later LabVIEW versions (try out his VI for yourself), Match Pattern can actually be slightly *faster* than Search/Split String in some cases (depending on where within the string the match is found).  So in the interest of full disclosure, I must clarify that this nugget is definitely helpful in LabVIEW 7.1 and earlier, but in LabVIEW 8.0 and later, you may not find it so useful.  If your string parsing algorithm must be as fast as possible, I recommend benchmarking to determine whether or not Search/Split String or Match Pattern is faster for your situation.

-D