Flashing red border! (She can't hold it much longer, Captain!)

[NeilR]

I've often wondered whether NI would introduce some sort of speed control on the highlight execution.
It's very handy, but sometimes you wish there was a "throttle control" to zip through parts of the code and then slow it right down at critical areas so that you can see exactly what is happening.

Maybe even a reverse trace !!! Now there's an interesting thought ... or maybe it's just time for my medication. 🙂

[Ray.R]

---

@NeilR wrote:
Maybe even a reverse trace !!! Now there's an interesting thought ... br>

---

Reverse trace???
😄 😄 😄 LOL 😄 😄 😄

Would that be like going back in time?

LOL!! I can picture the GPIB commands coming back from the instrument to the PC..

That would be fun...

All kidding aside >>> yes, it would be a nice feature <<<

The way I'd see it is that you place a marker where you want to "replay" the execution.. sorta like a loop, but not a loop in the LOOP sense (do you have spare medication?? 😉 )
You could set a breakpoint, set markers "START" & "END", execute, and when the code reaches the breakpoint, turn ON the highiligh execution and keep going back & forth within the "re-play" feature.

Wonder if Dennis or Ben could whip up something ?? 😉 Or maybe we should take this to the wishlist thread..

😄

[NeilR]

JLV

Glad you liked the reverse trace idea. I suppose it was the trekkie talk that made me want to push at the boundaries of what is possible. But of course "ya cannay change the laws of physics". 😉

I've had a lie down in a darkened room and I'm feeling much better. 😄

[spaceman_spif]

I'm going to tinker with the Breakpoint feature. It seems like it could help me during debug quite well. I have some fairly large sized case structures (try not to be envious) and following the highlighted execution is a pain because sometimes you can't pan the screen fast enough to catch things happening. So I'll give the breakpoint a try.


Right after I go get some more dilythium crystals.



Hey!! Someone put anti-matter in my cheese sandwich!!

[altenbach]

---

@JoeLabView wrote:
You could set a breakpoint, set markers "START" & "END", execute, and when the code reaches the breakpoint, turn ON the highiligh execution and...

---

That's not a bad idea. I would be happy if we could do selective execution highlighting for only part of the diagram code or make execution highlighting data flow dependent: If data reaches a "Highlight ON point" highlighting would start until data reaches a "Highlight OFF point". These would be set similar to breakpoints.

[Ben]

These ideas should be posted to the wishlist so they do not get forgotten.

I will drop a break point inside a new case structure that fires only under the conditions I want to monitor.

I seem to remeber the new "conditional break-points" will do similar, but I am beihnid in my reading.

Under

Tools >>> Options >>> Debugging >>> Show data bubbles durring execution highlighting

will speed up execution highlighting a bit.

Brace yourself BJD!

In the old days... When James Tiberius Kirk was the captain, there used to be a main-frame called "KI-10" that had a knob on the front that you could use to control the CPU clock speed. BTW: That machine had actual light bulbs (thousands).

One more thing;
Did we forget to acknowledge "The Rocky Horror Picture Show" aka "Time Warp"?

Ben

[tst]

---

@Ben wrote:
In the old days... When James Tiberius Kirk was the captain, there used to be a main-frame called "KI-10" that had a knob on the front that you could use to control the CPU clock speed. BTW: That machine had actual light bulbs (thousands).

---

In the less old days, when Jean-Luc Picard was captain, every PC had the magical "Turbo" switch, which usually did nothing (except to turn on a light bulb), but would allow kids to imagine that their game didn't take 4 minutes to load but in fact only 3.
I must also say that I prefer the station called "K-7" to the mainframe called "KI-10", and that while I like Richard O'brien alot, when it comes to Trek vs. Rocky, Rocky "should be hauled away AS garbage".
But here is the question for the real trekkies: which version of LabVIEW was the Enterprise's (that's the original Enterprise ["N...C...C...,1...7...0...1. No bloody A, B, C or D"]) computer programmed with and what happens if in the middle of a battle with the klingons the computer stops because of a misplaced breakpoint?

[Ray.R]

---

@tst wrote:

---

It was LabView-27.3.1(a)

They did away with the "breakpoint" feature on subsequent releases.

I guess we'll have to wait until 2248 to find out.

😄

[tst]

According to the Enterprise's library-computer, by the year 2248, Dennis will have written 69,426 posts with an averge rating of 4.96 (it seems by then we've advanced to 2 digits of prescision) and has achieved a rank of Revered Grand Master. While I don't like Enterprise that much, I will admit that's it's much better than Voyager and I would like to join JPD's call-to-arms and ask everybody to help uncancel it at Trek United. It may not have helped John Crichton, but we can still hope to save John Archer. I think the almighty NI corporation should back the claim of its loyal customers and threaten UPN with removing support for LabVIEW 21.6 (that's the one installed on the NX-01).

[DFGray]

While you are playing with breakpoints, check out custom probes. As mentioned earlier in this thread, they allow you to break on any condition you can code. They also let you massage their input any way you want. For example, you can create a VI reference probe which shows the title, path, and documentation and halts if the reference is invalid.