From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Strange shift register initialization

Thanks James,

 

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

Sure, it's ordinary breakpoint, but it should fire only if comparator output goes FALSE --> TRUE, isn't it ?

 

I can't run your code because there are subVIs not included ...

I attached it (Bloch_Formula)

 

but the above statement should allow you to find the real problem, because the problem is not with your data values.

You mean "conditional probe". Ok I'll test it, but before I want to understand why my ordinary breakpoint deosn't work properly.

 

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.

Yes, probably I put it ocassionaly. I've removed it

 

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.

Frankly speaking I didn't understand this issue ... after all it is placed after Boolean Crossing block that (if my comprehension is correct must be executed on FALSE-TO-TRUE sdge on its input)

 

 

 

Download All
0 Kudos
Message 21 of 33
(1,419 Views)

Pavel,

 

The breakpoint executes no matter the value of the wire.  If a crossing is not detected, the value of the wire is false but the breakpoint will still execute because execution of the program has reached that point.  If you want it to pause execution on a TRUE value, set a conditional probe.  

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 22 of 33
(1,415 Views)

@Pavel_47 wrote:

Thanks James,

 

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

Sure, it's ordinary breakpoint, but it should fire only if comparator output goes FALSE --> TRUE, isn't it ?


No.  Just the output of the Boolean Crossing VI output changes.  Everything after that happens regardless unless you use a case structure.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 23 of 33
(1,412 Views)

@Pavel_47 wrote:

Thanks James,

 

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

Sure, it's ordinary breakpoint, but it should fire only if comparator output goes FALSE --> TRUE, isn't it ?

 

but the above statement should allow you to find the real problem, because the problem is not with your data values.

You mean "conditional probe". Ok I'll test it, but before I want to understand why my ordinary breakpoint deosn't work properly.

  

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.

Frankly speaking I didn't understand this issue ... after all it is placed after Boolean Crossing block that (if my comprehension is correct must be executed on FALSE-TO-TRUE sdge on its input)

 


You are misunderstanding how these things function at their fundamental levels. A breakpoint pauses the code when it is activated. It will always activate no matter True/False/String/Popsicle/Balloon. Your ordinary breakpoint is working properly, I guarantee it. Your code is not working how you expect.

 

A signal value property node doesn't work that way either. You can signal a False value and I do this on a regular basis. Say you want to signal an event, but don't want to change the actual value to True? The property node is for the control value, which is a boolean.

 

 

Here you can see I ran you code and the breakpoint paused it on a False value.

False.PNG

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 24 of 33
(1,408 Views)

@Pavel_47 wrote:

 

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.

Frankly speaking I didn't understand this issue ... after all it is placed after Boolean Crossing block that (if my comprehension is correct must be executed on FALSE-TO-TRUE sdge on its input)


 crossrulz told you this 5 hours ago.

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 25 of 33
(1,397 Views)
Dear Pavel_47
could i have your code in 2014 version ?
I had same problem before and as i remember I could solve it just want to try that method on your code
0 Kudos
Message 26 of 33
(1,345 Views)

Thanks for all hints.

I've managed my code - ideed there were unconnected wires inside "event cases" and some other errors.

Nevertheless initialization issue persists.

 

On the Fig. 1 - manual emulation of hardware setup (the parameters B0x, B0y, B0z, a, b are the same as in HW setup)

The X-axis correspond to Value Z in actual hardware VI, Y-axis - to Polarization variable.

As you can state the curve is concave - i.e. it goes over minimum, or in other words when Value Z starts from -5V, each actual value of Polarization is less than previous one (at least until minimum).

It's not the case in hardware setup - using breakpoint, I see that actual value is more than previous one already on 1st step of Value Z. (Fig. 2)

 

Certainly I do something wrong on initialization, but can't find where I've been mistaken

 

Thanks

 

Pavel.

 

P.S. In attachment - 2014 version of VI

 

Fig.1

 

BlochEq - actual value test.JPG

 

 

 

Fig.2

BlochEqHW - actual value test.JPG

Download All
0 Kudos
Message 27 of 33
(1,310 Views)

The only difference I can see if that you have a different variable going in to your Bz input. See red labels below:

 

Bz.PNG

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 28 of 33
(1,294 Views)

Yes it's the case: when VI starts running (after user clicks on "START") the value of Value Z is equal to Vmin (at least it should be like this).

As long as VI running, Value Z goes from Vmin to Vmax.

 

Actually I'm going to simplify the VI because all DAQ-related staff (create canal, start, write, etc.) are useless because there is no feedback: feedback is "emulated" by Bloch formula subVI (in reality the 3 voltages Z value, V2value and V3value modify magnetic field, that is captured by camera; the behavior of the camera is emulated by subVI).

 

By the way how did you succeed to run this VI if you have no (probably) the concerned device ?

In my setup if the device is OFF, VI doesn't run and outputs error.

 

Thanks

 

Pavel

0 Kudos
Message 29 of 33
(1,283 Views)

Why do you use a local variable in this case rather than a wire from the event data node?  There is a place for local variables but it is not here.

 

Capture.JPG

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 30 of 33
(1,275 Views)