Embedded UI on Dual Monitors

[jwright30]

Hi,

I am currently developing an embedded UI on a touchscreen monitor. Is it possible to extend this to a second monitor? I know a mirrored monitor works, but I would like to not mirror the first monitor and extend it for extra information on a second display. The second display would not have touch capabilities. 

Thanks,

-Jonathan

[mcduff]

Never done this but there appears to be a property that you can set.

EDIT: This implies you need two UIs (VIs), one for touch screen one for other screen.

[jwright30]

I've tried this through the VI properties with two VI's but it did not work. But I also only saw the main monitor on the display setup screen of the OS on the touch monitor. So I wonder, can the crio/sbrio OS handle multiple monitors?

[mcduff]

From the help inthe previous post says it is not supported in RT.

[rolfk]

---

@jwright30 wrote:

I've tried this through the VI properties with two VI's but it did not work. But I also only saw the main monitor on the display setup screen of the OS on the touch monitor. So I wonder, can the crio/sbrio OS handle multiple monitors?

---

I’m pretty sure that it can’t, out of the box. Being Linux in principle it could probably be made to support it but :

- cRIO/sbRIO aren’t meant as desktop replacements. Traditionally they didn’t even have a display connector and getting something like VNC working on them was a challenge as they were pretty much designed to have no UI at all.

- even if the OS would support it, the LabVIEW realtime runtime engine doesn’t since it is compiled without that support. The X11 server implementation on the RIO platform is a lightweight variant on purpose as they want to have as much processing power as possible for the realtime process, not waste half of it with a fancy super duper alpha shading and 3D capable display server deamon!

Accordingly the X11 interface only supports the required functionality and not extra extensions for multi display support and such. Keeping code in the runtime engine that tries to access non-existing extensions only makes testing and maintenance more expensive and bloats the binary size uselessly.