todd

This is exactly the kind of problem I've been trying to solve. I really like using classes, since the instruments must sometimes be swapped out. But I can't quite figure out where to keep the class wires so that they're available to the tests AND to some other processes (simulation, for example). Some are kept in AEs, which makes it easier to access them from tests with a set of AE wrapper VIs. Now I'm trying to instantiate an AE class in order to create multiple AEs - but that brings back the original problem of where to keep that class wire.

I'm not yet able to keep up with this discussion. At the risk of being a distraction from the topic at hand - and at the greater risk of causing more confusion than clarification by posting incomplete code - here is a stripped down project. (Note that queue destruction and error handling are not completely implemented, here. Nor are all the accessor, and such. In the production code, many other helper VIs are in place.) The biggest pieces not included are the tests (which interact with instruments only via Data AEs and named queues), and the emulator - which also uses named queues to control what the simulated instruments are doing. A user (or a VI) can move sliders and push buttons in the emulator in order to test the tests. Sample Project.zip

My code has evolved into a similar (if less refined and sophisticated) pattern. Each physical instrument's slave loop responds to "show" and "hide" messages to display the front panel. Many of the instruments are streaming, so there are Start and Stop buttons, and appropriate displays of data that's being sent off to data queues (AEs). There are several different test VIs. Each test calls some of the instruments and some of the data queues (flexibility is key). Each test is called by reference so that "Main.vi" can do other stuff - such as run parallel tests with the other instruments, or allow the user to click Show and Hide buttons so they can watch the pretty data stream on by (or view the current collection rates or dropped packet count). The way I initially chose to use an instrument in a test is: 1. create a class in the top-level VI 2. send it to a dynamically dispatched* "handler" - the slave loop, which has a named queue 3. from a test, send messages to the named queue I'm trying to figure out how to get more flexibility in a test. If I add a duplicate instrument, I have to create a second named queue handler - along with its associated "add to queue" VIs. Perhaps I'll try bundling up all the instruments' classes and send them to the test. However, I also have "simulator" child classes of each instrument. A different top-level VI (separate app) has buttons for sending fake data on any instrument that was defined by the user as being simulated. Class methods are used for setting private data, and are accessed via the named queue. I want to start using a class that holds an instrument's class in private data (due to one version of an instrument having a custom GPIO interface that consists of several NI DAQ resource names, and another version having ethernet), but I haven't figured out how to access that class from another top-level VI without using something like a named queue. * This is dynamic because multiple versions of multiple protocols for multiple instances of multiple instruments must be continuously supported.

Apparently, it's okay for a Slave to miss a Master's command (slow Slave, quick Master) - but not for a Consumer to miss a Producer's.

You are writing to the graph twice - once with a local variable. Cluster To Array may be useful, here. Thermocouple Detection b.vi

Turns out I can do the enum-to-case-to-class constant in a subvi, then upcast it in order to put it in a cluster or array. The goal is to keep the various specific instrument classes all combined, somewhere. It may turn out to be more overhead than necessary, though.

Ah, yes, thanks! That's a good one. They create four instruments from four children of class DSSP. If I put those constants in an array, and downcast them in a loop, the array of child classes appears as expected. What I'm hoping for is a way to placing the child constants in a sub VI instead of having them on the BD. Perhaps the sub VI would need to be reentrant so as to "create" each class instance. Thanks, again!

I wish I'd seen Michael's vishots about classes and instruments a few months ago. I've made it to that level of functionality and am looking for the next baby step of having multiple instruments to iterate over - just for init, status and cleanup functions. (Most of the actual instruments stream data. I put that into a queue as it arrives, and process that queue into an LV2/AE - though it seems a look at classes +| IPE may be in order, as long as the performance is there.) I'm playing around with an instrument class that has child classes of dmm, gpio, power supply, serial binary streaming device, etc. Each of those classes has a child class for specific devices - for example, dmm might have child classes: agilent 34401, simulated and custom. I saw someone use a "create" or "new" method somewhere on the forums, here, but I can't find it now. Basically, I want a case statemtent to return a "simulated" or "34401" class, but in a subvi. See the attachment. I apologize for not taking the time to post code. The blue circles error out as expected, since real instruments are not installed. The red one does not. All that's in the "get new class.vi" is that case statement. (I added the "base" class instrument in an attempt to use dynamic dispatching and class-casting. Of course I've learned better than that by reading the forums. I remember seeing an example of this in someone's code on the forums, here, but I can't find it. Anyone remember the link - or have any other feedback? Thanks, --Todd

I notice your tribot detects a dark line early. Mine (er, my son's) didn't detect at all. A quick change to monitor mode showed the right value to use. I am impressed at the ease-of-use of the new programming app. The original was obutse enough to make me delve into the ngc route. The new one lets me get the program written _before_ my son completes the build. As far as cats (outside, at least) a friend of mine set spring-loaded paint stirrers (30cm long sticks) at cat level around his garden walls. He added vaseline to the end so the stick would smack the cat and deposit the petroleum jelly. The surprise and the work required to lick off the jelly deterred the neighbour's cats from any further visits.

Aitor, given Alex's next question, this may be jumping in a bit deep. It took a while for (even) me to get Matlab's build system understood. It wasn't well documented. Read the LabVIEW help for SysExec.vi (search for it) and the Matlab help for 'batch mode'. From the terminal (command line) you can type: matlab -r asdf.m to start Matlab and have it run asdf.m. If the last command is 'exit', Matlab closes. SysExec.vi lets you do this from LabVIEW. I sometimes use LabVIEW to generate data files that get used in the m-file - which then creates an output file.

I hope you don't mind that I'm posting your PM, Alex. When you open a vi that contains a Matlab script node, an instance of Matlab is automatically started that LabVIEW controls over ActiveX. You are only limited by the datatypes allowed into and out of the script node (plots work, too). Once the vi is closed (removed from memory/heirarchy) the Matlab instance closes. I have found it most useful to run Matlab in batch mode using SysExec.vi. That way I can programatically create data files and m files. --Todd

Here are some ideas: 1. Use MATLAB in batch mode. 2. Copy all your m-files into a single MATLAB Script Node. Add top level m-code to selectively run the subs. 3. Roll your own using ActiveX.

If you click 'search' in the Block Diagram's "Functions" palette, then start typing a word, the results window shows an incremental search. You can double click an item in the results list to see where it lives.

ASCII is ones and zeros, too. Perhaps the attached VI is helpful. Download File:post-107-1114756820.vi

If the driver VIs have the same filename: 0 close LabVIEW 1 delete or rename the driver VIs you don't want linked 2 open the driver VIs you do want linked 3 open the VIs that call the driver VIs 4 save all

Did you enable the ActiveX server in the Application Builder settings? Even if not, I haven't seen that crash a system (if by 'crash' you mean blue-screen). Also, does the .exe crash on the development machine or just the production machine?

When you build the exe, check "Create Installer" then under "Advanced..." button, check "LabVIEW Run-Time Engine".

How about search this forum for "Getting Started" Also, see the "Getting Started" subforum of "The LabVIEW FAQ" forum here.

So, thinking out loud, one person talking (P1) and two other people listening (P2 & P3). P1 asks P2 a question and extracts the answer. P1 then asks P3 a question and extracts the answer. Does your I2C driver allow you to do reads and writes separately? If so, P2 and P3 can each hold their answers until P1 extracts them. In other words, have one subvi that accepts an address and does the read, another subvi that accepts an address and does the write.

I'll send it tonight. The biggest file is a 30MB data.cab that may be splittable if my outgoing server won't work.

I've got the 34MB zip file. Can you receive this? I'm looking for a place to upload it.

A UART running at 115200 bits/second takes 8.68us per bit. A ten bit packet (start bit, data Byte, stop bit) therefore lasts 86.8us. Round to 100us - you have time to transmit four Bytes.

Is this called a moving FFT? Perhaps the waterfall in this toolkit is along those lines.

How about using one queue to get requests from all clients to the server. Then in each client obtain a queue whose name is the client's name. Send the client's name as part of the request cluster. Have the server parse the client's name, obtain that queue, and send the data. Edit: added image.

Allow me to increase my post count by suggesting that you start with an XY Graph with Time values on X-axis and Frequency values on Y-axis.