RE: ActiveX server in Labview
Dalmady, Otto [EMAIL PROTECTED] wrote: Using Windows XP, 2000, NT, 98, or 95, Is it possible to have a compiled LabVIEW .exe act as a full Automation server with my own defined Methods and Properties that can be called/accessed as the VI runs (outside of the development environment)? I'm sorry to have to tell you that this won't be possible the way you describe it. I doubt that you could do that in MS Office or such either. The LabVIEW Active X Server Interface is a generic LabVIEW Interface to most of its VI server methods and properties and with a little work on the client side, does allow you to run, execute and query any VI inside the application as if it would be another method of the Active X server though. It's not as point and click in for instance VB as if the methods would be directly exported as part of the Active X Object model but it gets very close to that. Rolf Kalbermatter CIT Engineering Nederland BVtel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijkhttp://www.citengineering.com Netherlands mailto:[EMAIL PROTECTED]
Re: Quantify noise in freq. domain
I am not sure I understand your question. Is it possible you wire the output (complex) of FFT to the input of RMS.vi directly? If yes, the RMS.vi only compute the RMS of the real part. You may need to instert an absolute value operation. Good luck
Re: How do i use the peak detection vi in labview when designing...
What do you mean real time? Does the data come point by point. If yes, you may call Peak Detector PtByPt.vi from the palette FunctionsAnalyzePoint By PointTime Domain PtByPt.
How do I read text from specific rows and columns in a tree structure?
How do I read text from specific rows and columns in a tree structure? In a table you can specify the cell to read from but I have not been able to figure out how to do this with a tree structure.
Re: Why do some older instruments require waits between writes?
Indeed the older instruments may not have been fully compliant. The response time of the micros in these instruments running @ 4 Mhz is just not good enough to respond to (or even change bus states) back to back commands from a 3 GHz processor. They may also have depended upon one of the other forms of handshaking requiring you to test for device ready before communicating again. The developer tester of the time would not have encountered a problem depending on the test methodology. Even today, a rush to market will leave untested and non-compliant corners of device interaction. Nothing to do except hope that you are working with a company that is responsive to your needs. My opinion.
Re: Best way for recording instrument commands
The IVI model for labWindows/CVI instrument drivers typically keeps a state for the instrument under control to solve exactly this problem. When you execute a get state method for the driver, you get all parameters even though the instrument does not support query function. This is the best way of supporting what you are describing. The method you describe would require you to replay the entire transaction to reach the same state instead of just the state. Writing a driver with internal state is not trivial because you have to model the instrument completely (in order to support the complete state). You may choose to inplement only what your application requires or if the instrument is one of the IVI supported classes, you may want to look to IVI.
Re: Serial: VISA or not?
I prefer VISA for all the reasons that Rolf mentions. There is no difference in speed - 9600 baud is 9600 baud whether it's VISA or the obsolete serial functions. VISA suits me perfectly because I also do a lot of GPIB programming and I have greater control of serial port properties with VISA - termination characters, control lines, etc.
