LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Strange behaviour of LabVIEW in multidisplay monitoring

I have LabVIEW 2011 application running in WindowXP (RAM 2 GB). We also have 2 display, both have same resolution and screen size.

 

Application consist of 25-30 screen. Application is designed is such way that screen can be moved to any display.

 

Problem is that when I move screen from one display to other , It writes data to hardware(e.g changes state of digital I/O) automatically. I also verified my program and there is no such event.

I am very surprised that only moving LabVIEW application screen to one display to other display cause automatically writing of data. 

 

Awaiting for your reply...

0 Kudos
Message 1 of 21
(2,572 Views)

Can you show the code?


GCentral
0 Kudos
Message 2 of 21
(2,563 Views)

Hi,

As per company policy I could not show code, but inside code nothing is written regarding this.

0 Kudos
Message 3 of 21
(2,551 Views)

Without the code I can't suggest anything. I suspect others won't either.

 

Perhaps you can try opening a service request with National Instruments - they might be able to look at your code in private or via an NDA.

Otherwise, you could try creating a smaller example (that you could share) that reproduces the problem.


GCentral
0 Kudos
Message 4 of 21
(2,520 Views)

I've never tried moving a "LabVIEW Screen" from one monitor to another while the code is running.  I know there is a setting in the VI Properties to set which monitor is used, and I seem to recall a Property node that lets you do the same thing programmatically.  It make sense (to me) that LabVIEW would need to know where to send the pixels it is generating, so the fact that it (internally) generates a "change of state" doesn't bother me.  Why is this an issue for you?

 

Bob Schor

0 Kudos
Message 5 of 21
(2,478 Views)

@piZviZ wrote:

I have LabVIEW 2011 application running in WindowXP (RAM 2 GB). We also have 2 display, both have same resolution and screen size.

 

Application consist of 25-30 screen. Application is designed is such way that screen can be moved to any display.

 

Problem is that when I move screen from one display to other , It writes data to hardware(e.g changes state of digital I/O) automatically. I also verified my program and there is no such event.

I am very surprised that only moving LabVIEW application screen to one display to other display cause automatically writing of data. 

 

Awaiting for your reply...


So which Events cause a hardware write? Which of these events fire when you move the windows (that shouldn't be too hard to find out). Maybe these should be changed to Dynamic events and be unregistered while the window is moving?

I can imagine the windows redraw when changing screen can cause a faulty value change on a button, or a false read if polling, just as you switch screens.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 6 of 21
(2,464 Views)

@Bob_Schor wrote:

I've never tried moving a "LabVIEW Screen" from one monitor to another while the code is running.  I know there is a setting in the VI Properties to set which monitor is used, and I seem to recall a Property node that lets you do the same thing programmatically.  It make sense (to me) that LabVIEW would need to know where to send the pixels it is generating, so the fact that it (internally) generates a "change of state" doesn't bother me.  Why is this an issue for you?

 

Bob Schor


Bob, from what I read in the original message, the problem is that digital outputs are being written to because the window was moved and not because something in the program caused the digital outputs to be written to.  I can see why that is an issue..

 

Questions for the OP:

1.  How do you know the digital outputs were written to?  If they were written to but with the same values they originally had, then I don't know how you would notice.  If they were written to and the digital output went from high to low or vice versa, and you didn't intend for that to happen, then I can see how you would notice and that it would be a problem.

2.  Are you sure there is nothing in the code that is causing an extra event being generated?  Have you looked at probes placed around all of your DAQmx Write functions.

 

The behavior you are describing is very strange and I would never suspect a bug like that would exist in LabVIEW  It is just not logical.  So any code that you can post, a simplified,non-proprietary VI that demonstrates this behavior, would be helpful.

Message 7 of 21
(2,462 Views)

@piZviZ wrote:

I have LabVIEW 2011 application running in WindowXP (RAM 2 GB). We also have 2 display, both have same resolution and screen size.

 

Application consist of 25-30 screen. Application is designed is such way that screen can be moved to any display.

 

Problem is that when I move screen from one display to other , It writes data to hardware(e.g changes state of digital I/O) automatically. I also verified my program and there is no such event.

I am very surprised that only moving LabVIEW application screen to one display to other display cause automatically writing of data. 

 

Awaiting for your reply...


Find any/all of the code that acts on the digital I/O and set a break-point.

 

Run your code and move the screen

 

When the break point fires look at the drop-down that is used in development mode to control the font and you will see the call chain  that triggered the break-point.

 

If I had to guess I would suspect that an event case has a "use default if un-wired" tunnel.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 8 of 21
(2,453 Views)

LabVIEW definitely is NOT programming your DIO out of itself while you do UI operations of any sort. If something like this happens, it must be your code that does it despite your claims that it isn't. Now you have to start debugging! Smiley Very Happy

 

As others mentioned "use default when unwired" or an event case structure that has a default case in which it does something under the assumption that the default case only is caused by very specific events, are the most likely culprits. Or a wire that appears to run through something but the real wire goes underneath that something.

Rolf Kalbermatter
My Blog
Message 9 of 21
(2,423 Views)

Computers are very good at doing what you TELL it to do, but not necessarily what you WANT it to do.  Hopefully, the more developing experience you get, the closer TELL and WANT become.  😉

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 10 of 21
(2,383 Views)