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.

Alarm sound has to play, and show a message box at the same time. If the user accepts the alarm by clicking on

No, it looks like everything closed out pretty fast. Just a comment, publishing data (Real or booleans) is a more efficient (faster) way to go than the simple method of right-clicking on a control & publishing it to the DS server.

Neville.

I sent this issue to NI and they reproduced the problem I was seeing. Here is their response:

Thanks for the clarification! I was able to reproduce exactly what you are talking about and I have to admit that it is quite strange. Front Panel DataSocket connections are not supposed to be waiting for updated values at all, so there is no way to set their timeout values and timeouts should not even be coming into play, although it appears they are. You are right in that the delay has nothing to do with the VI, but actually occurs in the Run-Time Engine, which runs in parallel with the development environment. I will submit this behavior for R&D to investigate, but in the mean time, I do have a workaround for you! You can hide this Run-Time Engine (duplicate

entry) that appears in the task bar by adding the line "HideRootWindow=True" to your LabVIEW.ini file (located in the same directory as LabVIEW.exe). This will hide the window that seems to be lagging and make the issue invisible to the user. Just keep in mind that if you are building executables (which have their own .ini files), you will need to add the same tag to their .ini files to get the same behavior.

Please let me know whether you are able to successfully implement the workaround and whether it is a viable solution for the time being.

As far as your comment, do you mean that using the datasocket primitives like in the picture attached? Maybe you guys know a better way to do what I want. Here is my situation:

I am writing a test executive and operator interface that is written in 7.1.1. This test executive loads and runs about fourteen different test applications based on the product being tested. The current applications and test executive is written in 5.1.1, and uses shared globals to communicate with the test executive (test applications use globals within the test executive application). The new test executive I am creating passes data to the test application through a generic data cluster (var name, type, and data as varient) using the call by reference for applications written in 7.1.1. Since I want to only have to update the one test executive, I wanted it to run the legacy code (which will probably never be updated because of time money contraints). I also wanted to be able to upgrade in the future without effecting the test application releases, and allow applications to upgrade to new versions at their own pace. So for these applications, I use an activeX application written in the version of LabVIEW I need to run. I pass the data using the set control and get control values.

The reason I needed to use datasocket (or something else?) was that I needed to transfer some data back while the test application is running. The only thing I use the datasocket information for is the current test display which will get updated around 400 times or so during product test, and the progress bar which only gets updated after every test block.

When I run test apps in the same version that the test exec is in, then I just pass the status data back using a queue and the progress data using the control reference (since it is not updated very much). The problem was communicating this information easily across LabVIEW versions. The datasocket setup in the control seemed the easiest way to accomplish this task.

Thanks for your inputs.

I tried your VI and everything works pretty fast. Close < 1s.

Do you have enough memory in your PC?

I have a laptop with 1Gig of RAM (just for comparison).

Neville.

So LabVIEW disappears from the task manager in less than a second or does the vi window just close?

It removes the vi's from memory fast on my machine and closes those, but it seems like LabVIEW is trying to cleanup loose ends with the operating system after that.

I am running WinXP Pro on a Dell workstation with a 3.2GHz processor and 2Gig of RAM so memory isn't an issue. I also tried running the same vi on a Win2000 virtual PC with the same issue. I am running trend office scan virus software on both images, but I don't think that would cause a 10 second delay.

It almost seems like a timeout value. I tried the timeouts when using the primitive datasocket vi's (which didn't work), but I don't know of any timeout values built into the control datasocket properties.

UPDATE: I also tried it on a coworker's computer that is a winXP computer as well. It took the same 10 seconds to close.

Have you tried running the close datasocket server VI?

I found that it didn't matter if the server is running or not. Attached is a vi that opens the server, the controls connect and then the server is closed and labview is exited. Note the time it takes for labview to close down on the task bar (or in task manager). On my system it takes about ten seconds. I can also remove the server open and close and it does the same thing.

Thanks

Download File:post-2966-1129240611.vi

Maybe some of you have ran into this and know of a fix, because I am :headbang:

I am trying to figure out how to use datasocket without having the EXE wait ten seconds before it closes. For an easy test vi I just put a control on the front panel and set it up for datasocket in the control properties (subscribe, local system). If I run the vi and exit from LabVIEW, it takes LabVIEW about ten seconds to close (same with an EXE). I have tried setting the default setting for the datasocket as disabled and then enabling it in the vi and then disabling it before I exit. Same ten seconds. I even tried just opening a datasocket up and then closing it (datasocket primitives) with the same issue.

I am using 7.1.1 right now so I can't use the Shared Variables, plus I am needing to communicate with applications in LV 5.1.1 so that wouldn't work anyway. I could add some TCP-IP drivers to accomphish the data transfer, but I wanted to see if there is an easy solution before I started down that path.

Thanks for any input.

Thanks for the reply. Things are a bit clearer.

The file solcelledata.MYD is located on the pc-logger

Is there a way I can fix or edit this file if it's corrupted ?

You might want to check if it is actually currupted by trying to edit the table with MyCC (go to mysql site). If it won't load you can always create a new database in MyCC with the parameters you need. I would also suggest to check the permissions of the user being used to login to the database in the LabVIEW application.

I doubt if you are having an ODBC issue because you are not getting an error in your connect routine, but you may want to check those settings as well. control panel\administrative tools\Data Sources. It is probably under System DSN.

You can add <B> </B> around text in the vi description or control description to make that text bold. I haven't found any other flags for italics or underline. If anyone knows...?

Most users probably already know this, but you can add custom tools to the LabVIEW tool menu by adding vi's or an LLB with top level vi(s) into the LabVIEW\Project directory (if you have more than one top level then those vi's show up under a sub menu). One use of the project directory I find extremely useful is for a vi documentation tool. Instead of having to find another vi with a correct description template, copying that description and pasting it into the new vi's description window, I just use the tool in the project directory to automatically apply a template (with <B> </B> to denote fields). Makes documentation fast and easy for new vi's.

And since, to the best of my knowledge, LabVIEW itself provides no means of providing what it actually places in the window title bar, you have to try all the various permutations.

Doesn't LabVIEW give you the actual window title with the FP Title property? The only issue I see with that is if you are managing windows that are not running. Are not all of the vi's you are managing running when you are switching focus?

See here and here for some ideas.

6105[/snapback]

I had tried the transparent control right after I sent out this question. The main issue I had with the transparent control approach is that I couldn't find a way to drop multiple files into the control. I belive the drag and drop event for the control looks to see if there are multiple files and doesn't allow a drop. This makes perfect sense because you can only hold one value in a path control. You can drop a folder which will allow you to get all of the files under that folder. So I guess that is some consolation.

Thanks for your help

I'm not really sure where this post goes.

Have you ever seen an ActiveX class integrated into LabVIEW?  I believe the reports VIs for interfacing with MS Office and things like that use them.  The methods and properties are available like a normal property node when using the class reference.  These are really slick.  I've seen LabVIEW hardware drivers implemented using these so you have the hardware functions available inside of LabVIEW... that kind of thing.

My question is, how do you make one?  How do you start from scratch and make something like that?  Are there any good references to guide one through the process of making an ActiveX class and/or integrating it with LabVIEW?  I'm sure I'll find some stuff on the web about ActiveX but I was wondering if anyone has experience on the LabVIEW integration end of things.

5875[/snapback]

It is very easy to integrate ActiveX classes into LabVIEW. It is pretty easy to make ActiveX classes as well. I've used ActiveX dlls written in VB6, and written and interfaced to ActiveX executables that I have created in LabVIEW. The LabVIEW executables have some upsides and some downsides. The upside is that it is written in LabVIEW and all interfaces to LabVIEW ActiveX executables are the same. This means you can keep the same class number (don't have to update your driver) even if you update your ActiveX app. The downside is that all interfaces to them are the same...you can't specify your own methods and properties. You can't build an ActiveX dll from LabVIEW either.

What I did was write a couple of generic ActiveX drivers for my LabVIEW exe's. One that runs a vi in the exe and waits for it to get done, and one that will keep the vi running and signal back to me when it is complete. All I have to do to communicate is to add the reference to the ActiveX executable and add the same named front panel controls to the vi that calls the driver. It basically works like calling a sub vi. You just pass in the inputs and it passes out the outputs.

If you want the property and methods to be separate then I would suggest using another language to build your ActiveX app. You can also use .NET as it interfaces similar (it has some restrictions) with methods and properties.

If you want to check out some existing classes, you can drop an automation refnum on your front panel (refnum palette in 7.1.1). Right click and select ActiveX class and browse. You then get the type library window where you can select from a multitude of different apps. You will want to choose the select creatable option because you want to create an instance of the application. Then just use the automation open fundamental in the ActiveX palette to open that reference and use the methods and properties to do what you want.

Attached are screen shots of the diagram for the interface vi and one of the general ActiveX drivers I wrote for LV ActiveX application.

Does anyone know of a way to perform a file drag and drop with multiple files from windows explorer to a LabVIEW treeview? It is so easy in .NET, but LabVIEW seems ignore this function. They have a file drag and drop for path controls. I heard that the next version of LabVIEW allows .NET controls which support file drag and drop, but I know there has to be some way in windows to enable the drop event for the control and get the file drop data into a LabVIEW treeview.

Thanks for any help.