Strange shift register initialization

[Alexander_Sobolev]

There is one more debugging tool: save wires values, next to highlight, I like it even more: run the program, then check if there is problem with values.

A couple more problems except local variables:

1) Tunnels of the event structure are in mode "use default if unwired". If you have not wired them through all states that have executed (timeout for example), there are zeros and no point in initialization.

2) Infinite while loop. Place stop button and event for it. Or correctly process Panel close? event. Do not use abort execution.

[Pavel_47]

Concerning last point - upon starting they must be the same by concept: except constants (B0x, B0y, B0z, a, b, V2value, V3value - values come from controls/indicators) the only difference is Value Z, which comes from loop.

But initial value when loop starting is the same that comes to shift register initialization.

[aputman]

---

@Pavel_47 wrote:

Hello GerdW,

The breakpoint will fire whenever code execution comes to this point - unless it is a conditional breakpoint.

Is it a conditional breakpoint?

But it should come to this point ONLY if the TOP comparator value is grater than BOTTOM one. Isn't it ?

It's ordinary breakpoint.

Wrong. In highlight mode your VI behaves the same except it runs much slower…

Sure, but I was waiting for about 3 min, clicking time-to-time in "START", but execution didn't reach the location of interest.

Are you sure they are the same? To the very last bit of the float?

On the above post I visualized probed values ... they are the same until 5 digit after point

Thanks

Pavel

---

That would be a conditional breakpoint because you just gave it a condition in your explanation (top value is greater than bottom).  Did you place the probes after the breakpoint had already occured? I don't think the wires retain their values unless you enable that option.  (correct me if that is not the case).  

[James.M]

---

@Pavel_47 wrote:

Hello GerdW,

The breakpoint will fire whenever code execution comes to this point - unless it is a conditional breakpoint.

Is it a conditional breakpoint?

But it should come to this point ONLY if the TOP comparator value is grater than BOTTOM one. Isn't it ?

It's ordinary breakpoint.

Wrong. In highlight mode your VI behaves the same except it runs much slower…

Sure, but I was waiting for about 3 min, clicking time-to-time in "START", but execution didn't reach the location of interest.

Are you sure they are the same? To the very last bit of the float?

On the above post I visualized probed values ... they are the same until 5 digit after point

Thanks

Pavel

---

An ordinary breakpoint will always stop the code when operated. It doesn't matter if the wire is a boolean, DBL, waveform, whatever. If you right-click and go to Custom Probe > Conditional Probe, then you're going to get a conditional probe.

A smart way I like to use Highlight Execution is to create a breakpoint right after my Start button, or right before the code I care about, run the code regular and then turn on Highlight once it hits that breakpoint.

[aputman]

---

@Alexander_Sobolev wrote:

There is one more debugging tool: save wires values, next to highlight, I like it even more: run the program, then check if there is problem with values.

A couple more problems except local variables:

1) Tunnels of the event structure are in mode "use default if unwired". If you have not wired them through all states that have executed (timeout for example), there are zeros and no point in initialization.

2) Infinite while loop. Place stop button and event for it. Or correctly process Panel close? event. Do not use abort execution.

---

Ah yes.  I knew I had seen that Retain Wire Values somewhere.  Shows how much I don't use it.

[Alexander_Sobolev]

>> But it should come to this point ONLY if the TOP comparator value is grater than BOTTOM one. Isn't it ? It's ordinary breakpoint.

Tutorials!!

It is ordinary breakpoint, it fires if execution has reached that wire. If it executes this frame, it will always fire.

>> On the above post I visualized probed values ... they are the same until 5 digit after point

Double has 15 digits resolution.

>> Sure, but I was waiting for about 3 min, clicking time-to-time in "START", but execution didn't reach the location of interest.

This case fires if there was a, b, 80, etc value change. No "Start" value change.

[James.M]

This thread got a little hectic. Pavel, are you still having an issue? Is the issue with values not matching, or with your breakpoint?

Sharing your code might help. Please include a Snippet of your code, or attach your VIs, so that we can better assist you. We are here to help, but won't spend all day recreating your code from scratch.

[Pavel_47]

Hello Aputman,

That would be a conditional breakpoint because you just gave it a condition in your explanation (top value is greater than bottom).

Ok, now I placed breakpoint after "Boolean Crossing" block - it is configured to execute only on rising edge of input signal

kI don't think the wires retain their values unless you enable that option.  (correct me if that is not the case).

Yes, I think the option wasn't enabled. As you can state from the screenshot below - breakpoint is fired despite equal values on comparator inputs (at least until 6th digit after point)

Also comparator displays "FALSE".

Regards

Pavel

[Pavel_47]

Thanks James,

Here it is

[James.M]

This is not a conditional breakpoint. The closest thing to a "conditional breakpoint" is a conditional probe, which you don't have. 

 If the code is not paused when run, then the code does not execute that frame of the code.

I can't run your code because there are subVIs not included, but the above statement should allow you to find the real problem, because the problem is not with your data values. It also looks like you've assigned a breakpoint to the entire event strcture case. Notice the red border around the inside of the case.

By the way, your "Min Found" value signal will signal that value every single time even if the value is False. You need to place a case structure around the property node if you don't want it to signal.