viSci

Hello all, I would like to have my application generate some sort of windows event that will stop the screensaver from starting up. I have tried generating mouse movements but this does not seems to work. Any ideas?

I have been using LuaVIEW for over a year and it has worked very well for me. I can control all the resources in a PXI chassis (single point and HW timed analog input, AO, DIO, counter PWM) also VISA based instruments such as balance scales, humidity sensors, fluid baths. I have a prototype dialysis machine completely running under LuaVIEW control. All you really need to understand is how to define a LuaVIEW callable LV vi. There is very good documentation on the subject. I am attaching a couple of examples for you to look at. Good Luck! Mike Sachs Intelligent Systems Download File:post-162-1158323291.vi Download File:post-162-1158323357.vi

It seems like a writable simulated resource should be pretty easy to program. You could generalize things by having the resource read from an array of data that is stored in max, similar to scale tables. MAX already provides an interface for creating new scales so it is not outside the scope of what is already there. You would simple select the data source for the simulated resource to be either the default sine wave or an external table.

I do not think this is currently possible but I have a good use case for it. VI Logger lite is a free program from NI that is a fairly good general purpose data logger, except that it can only log analog input channels. It has a API that can be programmatically controlled from labview to start, stop, enable logging, read data, etc. Although all channels must be analog, they can also be simulated channels. If you could setup a writable simulated channel then it would be easy to merge other asynchronous data such as RS232 based instruments, state info, etc. into the HW timed data stream. Any thoughts on the subject?

Greetings All, I am hoping to generate some discussion on the relative merits of these 2 scripting interfaces. I am currently using LuaVIEW and have had some good success with it to model pumping mechanisms for a medical device. I am somewhat concerned about the use of a proprietary CIN and some undocumented vi server methods (set/get tag) that LuaVIEW depends on, since we would like to settle on a tool that we will be able to standardize on for the long term use within our R&D. I am also concerned about the scalability from the simple uses I am doing now to much larger prototyping of complete medical devices that would involve the deployment of a large hierarchy of script modules. Mike Sachs Intelligent Systems

What is wrong with using Datasocket for OPC? I use it all the time and it works great.

I would like to collect some examples of Labview front ends for either scripting language. I would like to develop an interactive scriping vi that would allow me to load new scripts into a table or tree display and see a highlighted execution. (Hey maybe even breakpoints too.) I tried this a few months ago with LabPython and came close but could never get it to work correctly.

I am interested to find out how others are using scripting languages such as Python (LabPython), Lua (LuaView) etc. for applications involving multi-head testing and instrument control. I am particularly interested in hybrid approaches where a script can be invoked by a labview application and that script can also invoke test functions or instrument control vi's. Also where a main vi might have a state machine that is being sequenced by script commands via tcpip messaging. I am very interested in learning from others who have been using LabPython. One area of interest is how to expand the existing LabPython model so that it will work with multiple script threads. I imagine it would be possible for each Labview client to implant an identifier in the server script thread so that the tcpip port or messages could be unique. That way there would not be a fixed port for LabPython.

I think this one will finally work. Download File:post-10-1073107005.zip

Attached is an example that demonstrates how to get native UNDO functionality in a built application. I am doing a few extra things to the RT menus in order to preserve the use of user defined menus in the application. It seems that the UNDO functionality that has been hidden in the Runtime can only be elicited if the default RT menus are instated and hidden Download File:post-10-1073106893.zip