ned

Thanks, I'll see if I can make that approach work. What about the case where my shared instrument needs to do many functions , each with several inputs, such that the functional global approach would result in a very messy connector pane? Or where I need to execute an uninterrupted sequence of commands on the shared instrument?

I'm building a system that can run up to 4 concurrent chemical reactions. My plan is to have 4 independent "reaction" objects that each execute in parallel, but they all need access to some shared components such as the liquid handling system that adds chemicals to each reaction, and the analysis equipment to check reaction progress. I'm looking for comments on the best way to make sure that only one reaction at a time can access the shared equipment. It seems like the traditional approach would be a semaphore, but there are all these other options available. For example, I can put all the functions for the liquid handling system into a single FGV, make it non-reentrant, and prevent overlapping access. Or I can put the automation refnum (it uses ActiveX) into a DVR or single-element queue to limit access. What is your preferred approach? What if I have 2 analysis instruments, and each reaction should use the first one that's free? Taking this a step further (and overlapping with the recent questions about singleton classes), say I create a class to wrap the liquid handling operations. Do I wire that class to all the reactions after opening the automation reference? Is there a clean way to store that reference inside the class so that I don't need to directly wire that class everywhere it might be used? Thanks for any comments; I already have some of this working but I can't effectively discuss my design with coworkers (I'm the only programmer on the project) so I'm looking here.

There are no variables in LabVIEW, just values on wires. Given the very limited amount of C++ code you posted there's no way to say what a good direct equivalent would be in LabVIEW; you need to provide more context. What are you actually trying to do? Post the LabVIEW code you already have and explain what it is you need it to accomplish.

I think you have it backwards here - binary compatibility is usually a subset of source compatibility. An API which is source compatible but not binary compatible means that you can't run your existing binaries with the new API, but you can recompile your code without modifying anything. Binary compatibility means you can install your new API and your application continues to run without any changes. If a change is significant enough to break source compatibility then it almost definitely breaks binary compatibility as well, but it's easy to have a minor change that requires recompiling but no changes to the source. A better LabVIEW example might be LV 8.5.0 versus 8.5.1, and versus 8.6. Code written in 8.5.1 is source compatible with 8.5, but code written in 8.6 is not. None are binary compatible - a recompile (even though automatic) is always required, and the matching runtime version is necessary to run an executable. I don't think you ever get binary compatibility between LabVIEW versions, but I've never tried the situation you described. NI works hard to ensure source compatibility between versions by providing translations for functions that change - like the "Convert 4.x data" option on typecast - but without those translations, source compatibility would break.

It looks like the code in that post on the NI forums is quite old, and you definitely don't want to use Winsock directly (or through ActiveX). There are shipping examples of creating a server, under Networking->TCP & UDP, which use the LabVIEW primitives. As far as determining the protocol that your client uses to exchange data, you'll either need to find some documentation, or spend some time with a packet sniffer (I'm sure someone else can recommend one for Windows, my experience is with tcpdump on unix) to try to reverse engineer the protocol. There is no such thing as "Winsock standard" handshaking.

Yup, the CAN Channel API is only for NI hardware. I recall doing something similar once: reading raw CAN frames from a KVASER card, writing them to one of the NI-CAN simulated interfaces configured for frames, and reading them back from the other simulated interface configured for channels. This was actually easy to set up, and I had good experiences with the KVASER hardware and software tools.

Sorry for stating the obvious here, but your client is aware that USB to Ethernet is not the same as USB to Cat5? If they're trying to use an existing ethernet network it's not going to work - they need a dedicated Cat5 cable just for this device.

Are you volunteering just for the competition, or to help mentor a team? If you're just helping at an event, it's a lot less work than jcarmody suggests. I mentored a team at my former high school last year and was there 2 nights/week from the kickoff in January through the regional competition in February; the team also had another LabVIEW mentor. I also attended one day of the regional competition with the team and found out too late that the overall event would have benefited from an on-site LabVIEW expert to help during the practice day when the teams are trying to make sure everything works. Last year was the first year LabVIEW was an option for programming the robots and I didn't see any teams using complex code, maybe they'll be more advanced this year. Teams don't need to write that much code because the framework that NI provides is nearly enough to run the robots. I think it's more helpful to have experience working with high school students (and I can't provide much advice there) than it is to have knowledge of advanced LabVIEW concepts. It will help to understand the provided framework, but unfortunately I don't know of any way to get access to it without the FIRST-provided CD, and you can't install the FIRST version of LabVIEW and the standard version side-by-side. Last year's framework used global variables and VI server to abort a running subVI in a way that simplified the code for the students but was puzzling to an experienced LabVIEW programmer. If you can't get access to an installation of the FIRST software, reading the documents or viewing Ben Zimmer's FIRST TipJar videos is a good start.

This might have to do with data copies. Depending on what you do with the previewed queue element, and the internal queue implementation, the preview may require creating a copy of the element so that the original element can remain in the queue. When you flush the queue no copy is necessary since that element is no longer in the queue.

They are part of the PID toolkit and should be in the PID palette.

You haven't understood how PID works at all. You MUST use the Process Variable input; in your case it's the measured height of liquid in the tank. The PID VI calculates the error internally by finding the difference between the Process Variable and the Setpoint.

I haven't taken the CLD so I don't know what the requirements are, but the logic in your Update_LEDs is quirky. For example, why use two index array nodes in sequence to extract a single element, instead of just wiring both indices to the index array function? Also, to find the first true boolean in an array, consider using Search 1D Array instead of a for loop. Finally it seems to me you could avoid rewriting the boolean array twice in the two for loops (one inside a case structure, the other outside).

If your devices are on your local subnet and respond to broadcast pings, you can ping the local broadcast address (x.x.x.255) which should cause your PC to cache the MAC addresses of all the devices that respond. I'm not sure it solves your problem at all but maybe it helps.

Have you ever actually had a problem with your queues in the past? I think you've misunderstood something here. There is no reason not to use queues in applications that run continuously. You're not creating a memory leak since LabVIEW hasn't lost track of that memory; you've just "reserved" that memory for the next time that data needs to be put into the queue. Unless you actually need that memory back immediately for some other purpose there's no problem.

Have you clicked the "Forgot my password" link? That should send an email to your registered address containing a link that will allow you to reset your password.

I've been using the ADAM-5000 series modules from Advantech. For communication they offer a dll (easy to use, the LabVIEW import wizard handles it cleanly), an ActiveX interface (not well designed), a .NET interface (haven't used it) and are also supposed to support Modbus/TCP.

Dynamic dispatch means that you don't know at compile time which VI will execute, and it would be impossible to preallocate a clone of an unknown VI.

Crosspost.

It's unlikely that you could improve throughput by writing your own external code, unless you think you can do better than your operating system. From an NI employee in this thread: "The networking primitives are a thin wrapper around the OS's networking stack." Try transferring your data in larger chunks, so that each packet of data has a greater ratio of data to overhead. EDIT: just to follow up on Gary's suggestion, take a look at this VI from NI for disabling the Nagle algorithm on a single connection.

Most likely the problem is that your native mail client supports authentication, while the NI example does not. When using authenticated SMTP the mail server is willing to accept mail to any destination because it knows who the sender is and that you have permission to use it. Without that authentication the mail server will only accept mail for a limited set of addresses (most likely only mailboxes in that domain) because otherwise spammers will use it to relay mail.

The easiest way to communicate between projects is using VI Server, for which there is plenty of documentation in the LabVIEW help. Each project is its own "Application Instance" and there's some information about how to get a reference to an application instance in this thread.

QUOTE (jdunham @ May 7 2009, 02:04 PM) Yes - and on a related note, I wish that when going the other direction, replacing a two-input compound arithmetic block with a simple boolean operation, the replace menu would come up with the Boolean palette instead of the Numeric palette when the function has boolean inputs.

QUOTE (jonmcbee @ May 12 2009, 06:55 PM) You can get a strict type reference to a specific connector pane pattern by creating a constant from the "type specifier VI refnum (for type only)" input of Open VI reference; then right-click on it the constant, browse, and select a VI with your plugin's connector pane. Now you don't need a static reference to your plugin, you just pass the appropriate path to Open VI Reference to open that specific plugin and you'll have a strict reference to it. If the connector pane doesn't match you'll get an error. However, without knowing too much about your application, be careful of trying to make your code too generic. You'll never get your framework generic enough to cover every case without exceptions and yet still be specific enough to be useful, and is it really that much more difficult to distribute a new application than it is to distribute a new plugin? I think you're running the risk of having exactly the same problem again, just twice as complicated - you'll end up distributing lots of slightly customized plugins to your customers instead of distributing slightly modified applications. See if you can change your development process instead; for example, you might be able to use conditional disable structures for adding custom code for a particular customer. The one exception I can see here is if you absolutely cannot shut down your code in order to update it, but I'd be really hesitant about using this sort of system to do anything that critical.

QUOTE (pete_dunham @ May 5 2009, 12:32 PM) Generally I right-click on the block-diagram terminal of a control or indicator, choose create->reference, then right-click the reference and choose create->constant in order to create a strict type specifier constant.

I'm not sure about faster, but in general in this sort of situation you're better off doing the conversion inside the loop so that you only allocate a single variant rather than an array of them.