It looks like for the cRIO 9035 a monitor has to be connected to the displayport for the embedded UI as the unit is powered on. Unplugging and replugging the cable causes the display to not turn back on again. Is this by design? Is there some kind of way to re-enable the display through the command line? I would really like to know because I can see scenarios where the display can get disconnected- I restarting the machine to re-enable it is not good.
Solved! Go to Solution.
Normally, enabling Embedded UI is done when the cRIO boots up. You can set this option in NI MAX. However, I do not see why it would disable after you unplug the cRIO. Does this happen with any other monitor you plug in or just one particular monitor?
Have you seen this forum post? The post describes how a customer fixed a similar situation. Also, are you using any third party adapters? There are occasionally problems communicating between the cRIO and monitors when using adaptors, as discussed in this link.
This final link also explains why you may be losing calibration when disconnecting your device.
no not using third party adapters. I am connecting it directly to the cRIO displayport, using the official NI cable that came with the touchscreen. I'll try setting the display mode to DP through the menu and see if that's what it needs
Have you seen this tutorial, "How to Calibrate your Touch Screen Monitor in NI Linux Real-Time"?
This may allow you to change the configurations that you are looking for with your TSM 1017.
We are aware of the issue but it is lower-priority than some of the other things on our plate. What we have found in initial investigation is that there's some issue with either the HW, the kernel, or both that prevents the graphic chipset from reporting when a cable is plugged back in on a booted system.
Hi BradM good to know you guys know about it. Any workarounds? like possibly a command line thing or a script? Then I could have it trigger by pressing spacebar or whatever and have the diplay turn back on
I think we have a solution to fullfil your need. Use the "System Exec.vi" in a loop on your RealTime target and enter in the command line "xrandr --auto --display :0".
If you set the timing of the loop to 2000ms, every 2 seconds the RealTime target will generate an event to turn on the screen, if the screen is in standby or power safe mode.
Thanks for the update. One thing to keep in mind is that running a SystemExec command will induce jitter on other threads within LabVIEW RT, so if this is a concern to you, you should investigate using a startup script to launch a looping script that will run the commands noted (as the lvuser user) to periodically.
Here are the raw notes from our early investigation:
When checking the output of "udevadm monitor", there are udev events that happen on monitor disconnect but *not on reconnection*.
I was testing with both a third-party and the NI miniDP-to-VGA adapter, and both behaved in this manner.
Further testing with the third-party adapter showed some interesting behavior:
>If you unplug the VGA cable but leave the adapter plugged in, you get an event.
>If you plug the VGA cable back into the adapter, no event and "xrandr" reports no monitors connected
>If you unplug the adapter, you get an event
>If you replug the adapter, you get no event
>If you then use xrandr to query the state of things, you now get a udev plug event
It's been a while since I wrote those notes up, but as I recall, you won't get events if you've only unplugged the cable from the adapter (and calls to xrandr won't see any displays, which means that the noted command won't work in those cases), and my testing was only with a miniDP to VGA adapter.
If you get events reported by udevadm monitor, you can write udev scripts to automatically run that command on your behalf. The issue, as I discovered when looking into this, is that for our Intel Baytrail-based controllers (including the 9035), no events will be reported to udev until you actually call xrandr, and sometimes not even then.