Real Time Solution?

[klessm1]

Hello all-

I am looking at LV real time for the first time so I am fairly clueless when it comes this environment. I don't even know if LV real time is the correct direction to go on this project.

Basically what we want to do is to be able run a test system like it is an instrument. It doesn't need a user interface, it only needs to communicate to the automation PC which tells it what kind of part it is going to test so it can pick the correct test application to run and then go run the tests.

My boss does not want to use Windows as it is increasingly difficult to update Windows PCs every two or three weeks with new versions of virus protection definitions and Windows patches. The reason why the window's updates and virus updates and patches are such a big deal is because I work for an FDA audited company - everything must be documented. It is like doing a small software release each time we have to do this.

The two solutions that were brought up was LV Real Time and Linux. We do not need the determinism in LV real time, only the reliablilty since the tester is in a fully automated manufacturing line. Am I tying my hands with LV real time? I read Jack Hamilton's post and it seems like LV real time may be more trouble then it's worth for this solution (basically getting rid of Window's updates).

Couple of questions about real time.

1. Is real time like Linux where you have to compile the vi's in the environment? Or can you just use regular LabVIEW code (minus any windows fuction calls...activeX) and put it on the real time system and run it?

2. How do you setup the FTP settings? The PXI system that we have doesn't have any username or password for the FTP server login. We need to be able to control these PC's to a certain extent.

3. Do we need the LV real time module for every developer's PC (there are many)? Or would this just be useful on a host PC? This is one reason why I am hesitant in going to Linux because we would have to buy LV for Linux for every developer that would be working with the test system.

Is there any good ideas out there on any drawbacks to the real time approach. Many of Jack Hamilton's comments were directed toward the effect of certain coding practices on determinism. Since we are not worried about determinism for this test system, is there any reason not to use real time for this solution?

Is there any ideas out there for a better solution?

Thanks for your inputs.

[David Boyd]

I would've preferred that someone else on LAVA with more experience with RT would have replied by now, but since no one else took a stab at it...

I'm relatively inexperienced with RT, having only a short handful of FieldPoint RT systems in use since last year, so all my answers are suspect.

The two solutions that were brought up was LV Real Time and Linux. We do not need the determinism in LV real time, only the reliablilty since the tester is in a fully automated manufacturing line. Am I tying my hands with LV real time? I read Jack Hamilton's post and it seems like LV real time may be more trouble then it's worth for this solution (basically getting rid of Window's updates).

My reasons for using RT devices were pretty similar to yours - less about determinism and more about the promise of runs-like-a-tank long-term operation. In this regard, they've delivered as promised. As has been pointed out, you do trade off some capabilities. In one of my applications, periodic logging of measurements was an essential. Since the NI Report Generation and Database Connectivity toolkits are ActiveX-based, they're out. My needs were simple enough that I could just maintain a delimited-text file in the FP device's flash memory. I setup the built-in web server to show the application's top-level VI (current status), and in the HTML I added a link on the page to open the text file. Then I setup the webserver's MIME types so the remote user's browser would load the file into Excel on their machine (which handles delimited-text files even if you give them .xls extensions, I found). Of course, they still need the LV runtime support installed so their browser can see the VI panel embedded in the page.

Couple of questions about real time.

1. Is real time like Linux where you have to compile the vi's in the environment? Or can you just use regular LabVIEW code (minus any windows fuction calls...activeX) and put it on the real time system and run it?

The RealTime module is installed on the development PC as an extension to the LabVIEW development environment. This adds the capability in LabVIEW to change the execution target (from the default host environment) to the RT device over Ethernet. The VI files live in the development PC's filesystem, but when you run the VI, the generated object code and FP resources are pushed to the RT target's memory. The development PC then manages the FP interaction. At this point you can cut the RT target loose (by closing the LV editor, or targeting another RT device, or retargeting the host environment). The RT target continues to run. Note, however, that the RT target will not resume running this code if it's rebooted. To do THAT, you need to have built a startup application and FTP'ed it down to the RT target. The LabVIEW application builder (I assume you have this already) gets extended functionality when you add the RealTime module, so that it knows how to build executables which run on the target hardware, push them to the target via FTP, and set the RT target's INI to launch the exe. Maybe it's just me, but it took me awhile to get the concepts sorted out after years of just running LabVIEW code on a PC.

2. How do you setup the FTP settings? The PXI system that we have doesn't have any username or password for the FTP server login. We need to be able to control these PC's to a certain extent.

I believe all the FTP particulars on the target are manageable through MAX. I admit I haven't made a big study of security. There's security related to what IPs can access FieldPoint hardware (if your RT device happens to be FieldPoint), and a feature to lock the RT target against settings mods and reboots. Having just now looked at the NI knowledgebase, I see that the 'lock target' feature applies the same password to the FTP server, which ignores the username.

3. Do we need the LV real time module for every developer's PC (there are many)? Or would this just be useful on a host PC? This is one reason why I am hesitant in going to Linux because we would have to buy LV for Linux for every developer that would be working with the test system.

Anybody with a copy of LV can develop VIs which will eventually run on the RT target hardware, but the development PC must have the RT module installed to interact with RT target hardware.

Even after all the develpment is done and the RT solution is fielded, you still need a PC somewhere if humans are going to interact with the process. So as far as FDA compliance is concerned, you've only offloaded part of the controlled software. But this may still be more palatable than administering Windows-based PCs which directly connect to the controlled process.

Hope this long reply is of some use to you in your decision-making.

Best regards,

Dave

[klessm1]

Thank you for taking the time to reply. I didn't think anyone was going to answer! Your inputs are very helpful. :thumbup:

Michael

[Mike Ashe]

You originally mentioned Linux as an alternative to RT, but then did not ask any questions. Have you definitely decided to go RT. Or is Linux an option? I helped us Linux with RT extensions on a telescope project and it worked very well.

[klessm1]

You originally mentioned Linux as an alternative to RT, but then did not ask any questions. Have you definitely decided to go RT. Or is Linux an option? I helped us Linux with RT extensions on a telescope project and it worked very well.

We haven't decided to go to RT yet, and will probably still look at Linux. I have heard that it is easier to go from windows LV to RT than to Linux. Haven't checked it out for myself yet though.

The only main issue I see with going to Linux is that every developer will have to have a Linux station instead of being able to develop on a windows PC (which they currently have) and on LabVIEW for Windows (which they already own).

[Mike Ashe]

We haven't decided to go to RT yet, and will probably still look at Linux. I have heard that it is easier to go from windows LV to RT than to Linux. Haven't checked it out for myself yet though.

The only main issue I see with going to Linux is that every developer will have to have a Linux station instead of being able to develop on a windows PC (which they currently have) and on LabVIEW for Windows (which they already own).

Giving everyone a linux station will cost, at most, about $200.00 per developer. Either you install Linux in a dual-boot configuration, or you simply buy a removable HD kit plus one spare caddy each. About $25.00

http://www.newegg.com/ProductSort/SubCateg...?SubCategory=43

Look at the Kingwin KF-20-IPF HD rack and the KF-20-IT extra caddy. Actually $15.00, but add shipping.

Then you buy an extra HD for each, about $175.00 (I like bigger HDs, you can go smaller). Set you boot drives to be in the caddy. Yes, you can dual boot linux and Windows, but I find the caddy solution is a good/better option for many apps. YMMV.

Don't get me wrong, LVRT is a great product, but Linux is an option.

[klessm1]

Giving everyone a linux station will cost, at most, about $200.00 per developer. Either you install Linux in a dual-boot configuration, or you simply buy a removable HD kit plus one spare caddy each. About $25.00

http://www.newegg.com/ProductSort/SubCateg...?SubCategory=43

Look at the Kingwin KF-20-IPF HD rack and the KF-20-IT extra caddy. Actually $15.00, but add shipping.

Then you buy an extra HD for each, about $175.00 (I like bigger HDs, you can go smaller). Set you boot drives to be in the caddy. Yes, you can dual boot linux and Windows, but I find the caddy solution is a good/better option for many apps. YMMV.

Don't get me wrong, LVRT is a great product, but Linux is an option.

The main cost I am looking at is that the developers will have to have a license for LabVIEW for Windows (legacy systems) and LabVIEW for Linux. This is not a small cost. :thumbdown: The hardware like you said is no big deal.

Also, I am also thinking about reusability. Can you recompile code between LV for Linux and LV for Windows? Even if you can, it still is not true reusability because you will have to have two different sets of code. It would be a pain to try to have to sync up both sets of code all of the time. What I like about RT is that all the code doesn't have to be duplicated in our SCC system.

Also, what about LV FPGA? I didn't see any FPGA modules in the supported hardware list (maybe I missed them). We are currently using LV FPGA on a current project and may go to it on this project to replace USB, RS232, and the parallel port that is used in our custom test head. If it does support FPGA then that would be great.

Thanks for the information.

[Phillip Brooks]

Your problem seems to be more of configuration management one. If your LabVIEW stations are "instruments" then you want to treat them as such. I've used many traditional instruments where firmware and even OS updates (Agilent scopes) were regularly released, but I didn't because of dependancies and configuration management.

Don't treat the instrument station as simply another PC on the network. Don't take crap from the IS department. They will likely say "It's a PC, it's on the network, and the company policy is yada, yada, yada... We own it, and it MUST have Netscape, TimeKeeper+ 2000 and the AutoChron Super Backup service running..."

Don't install MS-Office, Norton AV, Firefox, or AOL IM. Don't use the instrument station for non-instrument functions like timeclocking or a print server. Disable Windows sharing, Windows Update, telnet, ftp and all the other unneeded services. Store your data directly on a server and access the results from there. If your IS department can't help you do this, point it out to the IT manager!

To reduce the possibility of viruses, your instrument stations could be placed on a private LAN. The account(s) used by operators would not have admin priviledges. They could be further physically secured by removing floppy drives, disabling USB (disables removable media) and disconnecting the optical drive from the computer's bus.

You might say "Hey, now it's hard for me to update or work on the instrument station. How do I load, debug, etc..." You will have problems with Linux, LVRT etc. The difference is that you won't have to support new OSs, manage LV licenses for different platforms or learn how to relink a kernel!

[Mike Ashe]

The main cost I am looking at is that the developers will have to have a license for LabVIEW for Windows (legacy systems) and LabVIEW for Linux. This is not a small cost. :thumbdown: The hardware like you said is no big deal.

Sadly, this is still true. Now that NI allows us all to install 3 machines with one LabVIEW 8 license it would be great if theywould allow any mix of platforms as long as you meet the 3+home limit

Also, I am also thinking about reusability. Can you recompile code between LV for Linux and LV for Windows? Even if you can, it still is not true reusability because you will have to have two different sets of code. It would be a pain to try to have to sync up both sets of code all of the time. <snip>

Yes, you can easily recompile. We did it for an astronomy project that used both Windows and Linux. The main problems we ran into were a few font size issues and a couple of cases where we had DLL calls in Windows and SharedLib calls in Linux. It was a minor hassle, but I wouldn't call it real painful. The flexibility we got with Linux-RT was worth it, for that application. YMMV.

[klessm1]

Your problem seems to be more of configuration management one. If your LabVIEW stations are "instruments" then you want to treat them as such. I've used many traditional instruments where firmware and even OS updates (Agilent scopes) were regularly released, but I didn't because of dependancies and configuration management.

Don't treat the instrument station as simply another PC on the network. Don't take crap from the IS department. They will likely say "It's a PC, it's on the network, and the company policy is yada, yada, yada... We own it, and it MUST have Netscape, TimeKeeper+ 2000 and the AutoChron Super Backup service running..."

Don't install MS-Office, Norton AV, Firefox, or AOL IM. Don't use the instrument station for non-instrument functions like timeclocking or a print server. Disable Windows sharing, Windows Update, telnet, ftp and all the other unneeded services. Store your data directly on a server and access the results from there. If your IS department can't help you do this, point it out to the IT manager!

To reduce the possibility of viruses, your instrument stations could be placed on a private LAN. The account(s) used by operators would not have admin priviledges. They could be further physically secured by removing floppy drives, disabling USB (disables removable media) and disconnecting the optical drive from the computer's bus.

You might say "Hey, now it's hard for me to update or work on the instrument station. How do I load, debug, etc..." You will have problems with Linux, LVRT etc. The difference is that you won't have to support new OSs, manage LV licenses for different platforms or learn how to relink a kernel!

It is true that part of the issue we are trying to solve is a configuration management issue. If all we had to do is setup a production test system the task would not be as bad. We look at providing solutions for production manufacturing first, maintenance group second, and development group third.

When test systems are down due to hardware issues, the maintenance group needs the flexibility to easily fix the machines. These systems are all over the world, so to fix these systems we proxy into them and help the engineers there debug the issues. Without a network link, this would be impossible. It is not possible at this time to break this link. The facilities do not have the expertise.

What you have been talking about is XP embedded, which is one of the OS options we are looking at in addition to RTOS and Linux. Basically a cut down version of XP with all of the stuff we don

[Mike Ashe]

I like your idea of a private network. We eventually have to get out to an outside network to send our test results to our database though. Every tester from IC to final device uses this database. This database must be accessible on the intranet because it is used for all sorts of data analysis and trend information for our products. And of course, we still have to maintain it, load new software, and test engineering product for evaluations. There needs to be lots of flexibility for some of our customers and minimum flexibility so they don

[klessm1]

With the appropriate setup the private network can be virtual. For some hospital mangement software development and debug we used a couple of flavors of VPNs, some through SSL, that went into secure hospital networks a long ways away and did remote installs, updates, live debugs and mods. That took some cooperation from the IT depts at the hospitals, but all-in-all I'd say it went pretty smooth. The VPN tunnels were okay, the only hassle came from a couple of hospitals that routed all external access to their intranet though a 24x7 dialup and PcAnywhere. I don't recommend that.

I'll have to ask our IT guys about that one.

Thanks.