Wait on Front Panel Activity crashes labview?

[msoflaherty]

---

@billko wrote:

...

Maybe it's what you do when it's been inactive is what's crashing the computer.

---

It's in the snippet - I switch a couple of switch-on-release booleans. That's all. Most of the time even the value doesn't change, it's only there as a precaution after all.

I'm not sure what additional information i'd get from turning off BSOD reboot. Also, I would have difficulty seeing it - this is a remote machine, so I need VNC up and running to view it. If I have the time I'll look into inspecting the memory dumps.

[msoflaherty]

---

@Ben wrote:

If you suspect the offending code is the user "Wait on ..." then toss it temporarily and wait 2-3 the crash interval. If it stops crashing we know what the "problem is". If it still crashes then we have to look elsewhere.

I've disabled it again after altenbach's tip didn't work out, and i'll report back again if it crashes, but I'm not expecting it to. The clock's ticking, at least.

The next step would run just that "special" code on another machine and wait for it to crash. If it does not crash, then the problem may be an interaction issue ... which takes us in yet another direction. 

Sadly I don't have the privilege of another machine on which to try this.

That prompts the question "what else was changed" since when it worked. Did the LV version or OS version change?
Still smells like a hardware (related ) issue and not a LV issue.

No other changes, no new hardware. As i mentioned before this was an isolated change. It's just a little thing I've been meaning to do for a while that I had "the spare 5 minutes" this would take to implement. 😑 ha ha

[msoflaherty]

This interrupt stuff is getting rather over my head, but wouldn't that also count for Wait On FP Activity? Wouldn't that be handled by an interrupt (reacting to mouse clicks, for example)? Why do we need to invoke new hardware to be responsible? Perhaps some collision between the event structure (which also handles mouse clicks) and Wait on FP Activity is triggering some sort of race condition where each tries to handle the same interrupt, but some resource has been freed, leading to an "attempted to access pageable memory while the process IRQL that was too high"?

The old VT100 hardware has been chuntering along reliably for about 3 years now, I'm very skeptical this is where the issue lies. To satisfy your curiosity, this is the device, (note those last couple of bullet points... fun stuff), it spits out strings that look like this:

¬7¬8¬7¬¬¬8¬¬¬¬C.A.E.N. SY527 V3.18¬¬ACTIVE¬Ch_En is: ¬On ¬¬¬V0-SEL¬ ¬I0-SEL¬ Crate 01

¬ Channel HVmax Vmon Imon V0set I0set Pw Status Ch#¬¬¬*¬¬ WB_024 3103 1792.20 0190.00 uA 1792.00 0250.00 uA On 9.02¬ WB_018 3103 1533.60 0164.00 uA 1534.00 0250.00 uA On 9.03¬ WB_027 3103 1662.80 0177.00 uA 1663.00 0250.00 uA On 9.04¬ WB_008 3103 1657.00 0140.00 uA 1657.00 0250.00 uA On 9.05¬ WB_030 3103 1754.00 0147.00 uA 1754.00 0250.00 uA On 9.06¬ WB_011 3103 1846.00 0155.00 uA 1846.00 0250.00 uA On 9.07¬ WB_033 3103 1829.00 0153.00 uA 1829.00 0250.00 uA On 9.08¬ WB_005 3103 1506.40 0160.00 uA 1507.00 0250.00 uA On 9.09¬ WB_032 3103 1517.00 0162.00 uA 1517.00 0250.00 uA On 9.10¬ WB_001 3103 1693.00 0180.00 uA 1693.00 0250.00 uA On 9.11¬ WB_044 3103 1575.60 0168.00 uA 1576.00 0250.00 uA On 9.12¬ WB_047 3103 1637.80 0174.00 uA 1638.00 0250.00 uA On 9.13¬ WB_012 3103 1479.80 0157.00 uA 1480.00 0250.00 uA On 9.14¬ WB_016 3103 1586.60 0171.00 uA 1587.00 0250.00 uA On 9.15¬¬¬¬¬¬A734 ¬¬Page 7 ¬¬ WB_024 ¬¬¬ ¬Q¬uit ¬E¬dit ¬C¬hange ¬A¬dd ¬I¬nsert ¬R¬eplace ¬D¬elete ¬U¬pdate ¬N¬ext ¬P¬rev ¬M¬ore ¬S¬witch ¬V¬/Isel¬¬7¬¬¬8¬¬7¬1828.80¬8¬7¬1506.80¬0160.00¬8¬7¬1517.00¬8¬7¬1637.80¬8¬7¬1479.80¬8¬7¬1586.60¬8

where those escape sequences are interpreted by hyperterminal (or me, in labview) via a mapping such as from here to make up something that looks like this.

(aside: did i really need to do this just to copy that text to be able to post it??!)

[johntrich1971]

---

@msoflaherty wrote:

---

@billko wrote:

...

Maybe it's what you do when it's been inactive is what's crashing the computer.

---

It's in the snippet - I switch a couple of switch-on-release booleans. That's all. Most of the time even the value doesn't change, it's only there as a precaution after all.

---

What do those booleans do? Perhaps you have created (or exposed) a race condition. In any event I don't recall ever using that Wait on Front Panel Activity function. I've found an event structure to be more than adequate. Also, the Elapsed Time express vi is nice when you need to perform a function after a given time.

[msoflaherty]

The booleans disable background reads. On the main event structure timeout, they control a case structure; if enabled, a background read is performed, if false, one isn't. They're mechanically switched, not latched. Shouldn't be any race conditions.

[johntrich1971]

---

@msoflaherty wrote:

The booleans disable background reads. On the main event structure timeout, they control a case structure; if enabled, a background read is performed, if false, one isn't. They're mechanically switched, not latched. Shouldn't be any race conditions.

---

Where else in your code are you switching the controls? What happens if one is switched and the other is not (a race condition in which one gets updated from your code and then they both get read before the other is updated)? If this piece of code is really the problem then the problem likely exists in how it interacts with the rest of the program.

[msoflaherty]

---

@johntrich1971 wrote:

Where else in your code are you switching the controls?

---

Nowhere, other than by the user clicking the button. They're read in one place, where they control a case structure, either case of which is acceptable and independent. They're changed only via the FP. They're literally as simple as a variable can be.

---

---

What happens if one is switched and the other is not?

---

One controls whether to do a background read, the other whether to advance which set of channels is being read. They're independent, and can be in any configuration, with no interference. If 'do read' is true, a read is done. If 'advance page' is true, it increments the page number (a basic int) before reading, otherwise it doesn't.

[billko]

Any particular reason you are inverting the output of the tick count?

[altenbach]

---

@billko wrote:

Any particular reason you are inverting the output of the tick count?

---

It's just a subtraction and the comparison acts as a poor man's detector if the wait has timed out or not.

Would be nicer if the function had a "timed out?" output, though. 😉

[billko]

As you can plainly see, I suck at bit-wise operations.