Conditional Error Probe not working as expected

[JonathanLindsey]

I'm having an issue in LabVIEW 2018 where I configure the conditional error probe to pause on an error and it pauses but allows code to execute that shouldn't execute first. Please see the attached screen recording and attached VIs. This other thread sounds like it's related but there was never enough information there to figure it out. https://forums.ni.com/t5/LabVIEW/Conditional-Error-probe/m-p/3242303

[MarinaBen]

Hello JonathanLindsey,

It looks like the top error wire in your Reciever.vi is always finding an error while the error wire you are probing is rarely receiving an error. I would put your custom probe on the top error wire instead when I did this it would pause before continuing. 

[JonathanLindsey]

I know what that VI is doing. I believe I have described a bug in LabVIEW 2018. I suppose I could work around the bug by unbundling the cluseter and using a simple conditional boolean probe to pause the VI at the right time (like the other thread concluded with) or possibly I could make a custom probe to pause the VI at the right time but would it be possible for NI to fix this bug in a future release of LabVIEW?

[billko]

Can you show this bug in a distilled form?  i.e., A while loop with nothing more than an error ring attached to the probe and an indicator attached to the iteration to prove it's still running?

[BertMcMahan]

I believe the bug is that the boolean indicator shows True when the bottom error value shouldn't have propagated. Theoretically, the breakpoint should have stopped the error from hitting the And block, which should have stopped the error indicator wire from being lit up. It took me a couple watches in the video to see what you meant, but this does look like a bug.

Shouldn't the conditional breakpoint halt the dataflow of the error wire, resulting in the And not being evaluated? Notice in OP's video at about 37 seconds  that the "result" indicator lights up just before the conditional probe trips.

By the way, I ran your code on my end and I'm seeing the same behavior (LV2018 as well)

[JonathanLindsey · Accepted solution]

I contacted NI aplication engineering. They confirmed this is a LV bug and created CAR number 728937.