HELP!!! Does LabView support a thin client or dumb terminal (diskless workstation) type of deployment

[pglover]

The thin client workstation/dumb terminal in the lab needs to be diskless. We are running on a Windows platform here. So what that means is that I need a dumb terminal workstation that has XP embedded and also have the ability to install the necessary LV files to run the LabView application. Any suggestion on a cheap dumb terminal capable of running a LabView application with DSC, and an OPC server software. The terminals needs to be connected to the network so it can read data from the PLCs (once again the PLCS are connected to the network).

[tst]

I don't know whether XPe can run an LV application. Try searching the site.

In any event, I don't think you will need a modbus server, just a client implementation, which can be done with pure ASCII, and for which you can find examples.

I will say this again, one last time - the easiest solution would probably be not writing any software for the device, but connecting to the server.

[shoneill]

Providing you don't do any hardware access (RS-232, DAQ, IMAQ) then wouldn't it be possible using a web panel?  You mention network connections, meaning the connections can be maintained by the server, can't they?

Sounds to me like you only need the interface on the client, not the entire program.

I mean this way the application isn't technically "running" on the client, but my question would be "Does it really need to RUN on the client, or do you have to be able to interact over the client?".

I know it's silly suggesting something I've no personal experience in, but there you go.

Shane.

PS This means I agree with Tst.  Kind of predictable, but there you go again. 😉

Message Edited by shoneill on 07-18-2006 04:41 PM

[tst]

---

@shoneill wrote:

Providing you don't do any hardware access (RS-232, DAQ, IMAQ) then wouldn't it be possible using a web panel? 

---

To interact with a VI in an RFP you have to install the RTE and the actual support for this works through ActiveX.
This won't work with CE, but it might work with XPe.

Of course, to only view the VI, you don't need anything installed, as that's just an image.

[tbob]

I used to work with dumb terminals in a UNIX environment, but that was a long time ago.  To clear up any confusion, a dumb terminal IS just a screen and a keyboard.  No CPU, no disks, nothing else.  It is meant to connect to a network in a manner that the main program runs on a server and the dumb terminal is just a display to the program running on the server, and the keyboard is an input device to the server.  That way, many terminals can be connected to the server, and the server can contain many applications that can serve the dumb terminals.

What is needed is a server application that can run the Labview program.  Of course you also have to have a terminal application that interfaces with all terminals (there is a name for it but I forgot what it is).  Perhaps some UNIX guru would be able to provide a better answer.  Its been too many years ago since I worked in that environment.  I do remember however that the terminals all communicated to the servers over an RS232 link, and the local area network was simply a serial switch, an AT&T Datakit switch.  You would get a DIAL prompt on the terminal and you would enter in the server you wanted to connect to.  The Datakit switch would then connect your terminal to that server, just like it was plugged directly into a com port on the server.  Then you would type in the application you wanted to run.  The terminal server program would call up the application and you could run it on your dumb terminal, using the server's processor as your CPU, along with the server's memory space, hard drives, etc.

[bww]

Just bumped into this thread while looking for something else so I'm not sure if it's still active....Anyway, Labview Run-Time does run quite well on Embedded XP even though it isn't supported by NI. I have developed/deployed several units and have been pleased with the results. If there's still interest in the subject, please let me know and I'd be happy to post more.

Regards,

Bryan

[tst]

What are the actual differences between XP and XPe?
Could the device (at least theoretically) run both versions?
Did you get it to support hardware (VISA, MAX, etc.)?

In any case, if the platform isn't supported by NI you could always find out that the next version doesn't support this any more and that you're stuck with a certain version for development for XPe.

[bww]

XPe is just a componetized version of XP, which means that you can strip out the pieces of XP that you don't need. This allows you to shrink the install footprint small enough that it can boot and run off a compact flash card. You can also go the other way and build a full version of XP, with all it's extra features. So in theory, XPe can be the same as XP and if the device can run a full version of XP it can run XPe. In fact, the dual boot is one of the debug, development setups.

I have succesfully developed installs that support hardware devices. Specifically, an IOtech daqboard 2000 but I have no doubt that any device designed to operate on an XP box would also operate on an XPe box.

As for NI not supporting XPe, they just say that it is not a supported environment but since one is built from the other, there really isn't much worry until NI drops support for XP.

The real beauty of the XPe system is that you can build a small image of XPe (~250 Mb ) that you'd believe to be a full version of XP and then run the device from a Compact Flash card. Which has the following advantages:
- no moving parts, ie hard drive
- quick boot times
- EWF (RAM overlay)
-and of course the most important...it supports the labview run time engine.

The reason I went down the XPe path was that I needed a touch screen interface and I was very disappointed with the PDA products/solutions.

[Lavezza]

I've looked into using a thin-client setup. I haven't tried it yet, but I'll add my thoughts.

Windows Option:

Run LV (or LV created apps) on a Windows Server and have Windows Thin-Clients. For those who aren't familiar, Windows Thin-Clients are diskless machines running XPembedded. XPe comes preinstalled and normally isn't customizable. These boxes are like plugging in a cable box, you don't have access to change the OS, add hardware, etc. The boxes connect to a Windows Server when they boot up. The desktop, apps, file storage, etc. all happen on the server, nothing happens on the thin-client expect displaying the video and collecting the keyboard and mouse inputs. If you need more RAM, fast CPUs, more hard disk space, etc, you upgrade the server.  (OK, not entirely true. There are thin-clients that have local storage, some that don't run XPe, etc. But the above is generally true and represents the normal setup)

The main issue is that NI doesn't support LabVIEW on any server versions of Windows. This doesn't mean it won't work, just that NI hasn't tested these setups. Also, Windows didn't start as a multi-user OS, so some apps just don't behave correctly when multiple users are all trying to run copies at the same time. For example, it wouldn't be unusual for a Windows app to create a temp file in a global directory (e.g. c:\temp). What happens when 20 people are all running copies of that program at the same time on the same computer? Probably nothing good.

Linux Option:

Run LV or LV apps on Linux and have X-based Thin-Clients. This is similar to the setup above. The advantage here is that Linux was designed for this sort of thing from that start. The linux versions that NI supports can be setup as Thin-Client servers. X (the graphics display code in Linux) has always been designed for running apps on different computers from where they are displayed. Since user acces to global directories is usually locked down in Linux, multiple copies of an app can run just fine. Some X thin clients have a small embedded version of Linux burned into memory, some just download the OS from the server during bootup.

The drawback here, of course, is that LV on Linux doesn't have all the features of LV on Windows. Also, if your users and IT people aren't familiar with Unix-like OSes, there will be a learning curve for everyone.

[Paul M.]

Just to provide some NI-side input here:

The main reason we don't support XPe and the Server OSs is that currently only a very small percentage of customers have requested this feature, and these OSs introduce MANY variations that would significantly increase time between releases. 

With that said, LabVIEW and most of its features will most likely work well in both XPe and the Server OSs.  The problem is, we can't guarantee it. If you DO run into a bug in these scenarios, supporting it and fixing it would be very difficult if not impossible. 

I have heard of several users being successful with XPe.  As long as XPe remains fully compatible with XP apps, we should be OK.  To reiterate, if you need the reassurance of tech support, I would probably avoid this option.

From personal experience, I have noticed a lot of hardware drivers run into difficulty in Windows Server because of a much tighter hardware access policy which trades off performance for security. 

If you find yourself drawn to these platforms, we need to hear from you! If enough users ask for support in these OS's, we will seriously consider them.  Submit a suggestion here:
http://digital.ni.com/applications/psc.nsf/default?openform
These are seen by R&D managers and considered for features in future releases.

Cheers,