ned

That's a critical piece of information - it means you're running on a cRIO with the IO controlled by the functions NI provides. No wonder you're confused; all the previous comments were based on the assumption that you're using DAQmx on a Windows machine. In your case, no, there's no way to trigger a VI to run the instant you push a switch. You'll need to poll the state of the input and when it switches (from false to true, or whatever your condition is), run your VI. You may want to have a separate loop in your code, running at a faster rate, dedicated to doing this if you absolutely need it. If you describe your goal more fully you might get more helpful hints or suggestions on an alternate approach.

And now we have DAQmx Events, which let you trigger an event (in an Event Structure) when a digital line changes. I haven't actually used them, but it looks easy enough.

If you use the Close File function, the output is the path to the file.

If you want to be really efficient about this, and you don't need to reuse the arrays after computing the intersection, you can reuse the non-auto-indexed array to store the intersection, and trim that when the loop exits. This gets you the benefit of both 1 and 2.

There's no need to concatenate in a loop at all here. You know in advance that the intersection array cannot be larger than the smaller of the two input arrays, so you can preallocate an array of that size. Track the current array index in a shift register. Each time there's a match, use replace array subset instead of build array, and increment the array index. When the loop finishes, resize the array to the final value of the index shift register. This is much faster than concatenating in a loop.

The top approach looks pretty good to me. You could improve it slightly by pre-allocating the final array, then resizing it after the loop finishes. Also, this is purely aesthetic, but there's a Swap primitive available in the memory management palette that could replace the case structure at the top left.

You're going to need to modify that code even if you put in a custom error handler - currently it calls abort() regardless of whether it calls the custom error handler or not. How often does your library generate an error? Do you expect your code to be able to recover from the error? You could write your own custom error handler that posts a user event to LabVIEW, or sets an occurrence; I've never done it, but I've seen sample code. You would need a function to register the occurrence or event refnum before running any functions from the DLL that crashes. One thing I did in a similar situation (an ActiveX component that crashed routinely) was put that component into a separate LabVIEW application and call it using VI server. I could detect when the component crashed (VI server returned an error) and restart that component application using System Exec, then reconnect with VI server. The users saw an extra item in the task bar (wasn't important to hide it), and an error message and a slight delay when it crashed, but it allowed the main application to run reliably.

I don't understand what you're saying here... you can send a notification when no one is waiting on it, and it will be seen by the next Wait on Notification unless the "Ignore Previous" input is TRUE.

I realize the original poster's question has already been solved, but I still wanted to add a few comments. No, it's not functionally identical. Your version will shut off the output as soon as the process variable is in the range of the setpoint +/- the deadband. Mine keeps the output on until the process variable is greater than the setpoint + deadband, then turns the output off until the output is below the setpoint - deadband (a form of hysteresis). Any control algorithm for this situation will necessarily vary the amount of time that the output is on. What I was trying to say is that PWM doesn't make much sense when the PWM and PID run at the same rate. Let's take your example with 1 minute periods and the PID calculates the number of seconds the output should be on. Say the loop runs once per second and it calculates that the output should be on for 30s. Now what? Do you turn on the output for 30s, turn it off for 30s, then run the PID again? That's going to slow your control response substantially. Or, you run the PID again one second later and it calculates the output should only be on for 10s. How long should the output be on? If the PID output is 0s on the iteration after that, do you turn off the output immediately? If not, then your control probably isn't going to be great. If so, then you should be using a simpler control algorithm that provides a boolean output instead of the analog signal provided by PID, as I was trying to explain.

Right, but if they're hooked up to a PID loop, they're using a PWM driver to convert the PID's continuous signal (duty cycle) into the device's discrete output (on or off). PID is meaningless in a digital system; if you can't change the magnitude of your output based on the magnitude of the error, then there's no reason to use PID, and that's the situation the original poster is in. Did you look at the poster's code? He's trying to connect the PID output directly to a digital out, which isn't going to work. No amount of tuning will make much difference in the performance. If he were to add a PWM driver and connect it to an analog output instead, then PID will become a reasonable control scheme.

Perhaps a better phrasing would have been "PID is designed to drive a continuous signal, not a discrete one." If you can only turn your output on and off, and you can't use a PWM driver to do that more rapidly than your control loop runs, then the PID isn't helping. Are you sending a speed command over Modbus, or a command to turn the motor on or off? If it's a speed command - and I'm guessing it is, since you have a VFD - then you have a continuous output and PID is a reasonable choice.

Given your hardware, PID is the wrong control algorithm for you. PID is designed to drive an analog signal, not a digital one. PWM lets you use a digital output as though it were an analog signal by switching the output rapidly with varying duty cycle. Your USB 6008 cannot do digital pulse generation so you would have to do PWM in software, at which point it makes more sense to write a control algorithm that switches the output directly. A simple approach is an On-Off controller with deadband. An example of such a controller is attached. On-Off Controller.vi

This is correct. There is no multiple inheritance in Java. Interfaces are a separate concept from inheritance. A class can implement multiple interfaces, but it can only inherit from one class. An interface is a set of function prototypes that the class must implement.

There's an NI LabVIEW user group meeting near me next week. I've never attended one before, but I just moved and have been trying to meet people in my new location. Has anyone attended one of these and found them helpful, fun, informative, worthwhile?

I'm not an expert on Windows messages, but I have successfully used this library to receive messages from another program. In my case, I had to provide the third-party application with the Window Handle of my VI (through an ActiveX call) so that it would know where to send the messages. It sounds like you need to do something similar - find a way to tell your third-party application where to send events. You should not need to modify the windows message library. If you're trying to intercept events that would normally go to the third-party application, I have no idea how you could do that.

You could include the batch file in your project (a LabVIEW project can include any type of file, even if LabVIEW didn't create it) and then include it in your build. Alternatively, you could have your VI write the batch file and then run it, since a batch file is just a text file with a .bat extension.

Make a batch file and call it from your LabVIEW code. There's no way this will work; have you tried doing the same thing by opening a command line and pasting in the exact same line that you're calling from LabVIEW? With a batch file, the interpreter gets a chance to parse the entire file and find the destination of the jump. When you enter it all on one line like that, the interpreter handles each line one at a time. It sees the goto command but it hasn't yet seen the target of the goto so it fails.

I don't see any good reason to separate this into two loops. Make it one loop, use an array of IRQ numbers (containing two elements, 0 and 1), and pass the IRQ(s) Asserted output as an input into a case structure (inside a for loop) that determines what logging action to take. It's a bad idea to open multiple reference to the same FPGA VI. If you must use multiple loops, fork the reference wire rather than opening a second reference. The way you're doing it will work but is not recommended; see the LabVIEW help for "Using Multiple FPGA VI References for the same Target."

You wrote your code to wait for interrupt 0, then for interrupt 1, and then loop and repeat, so it's doing exactly what you would expect. You have the output from Wait on IRQ 0 as an input to Wait on IRQ 1 (with some other functions in the middle), so your code doesn't start waiting for IRQ 1 until it has already acknowledged IRQ 0. What you're getting is sequential, not parallel, execution because you wired it that way, and there's no polling. The Wait on IRQ function allows you to supply an array of values so that it can wait for any of several IRQs, and that's what you want. Wait for either IRQ 0 or 1, do the appropriate processing/logging based on which interrupt was asserted, then loop and go back to waiting again.

You can put all three VIs into a single DLL and call them as different functions in that library. Your problem is the length parameter in the TCP Read. You only read 64 bytes, which would be sufficient for one double-precision value, but is not enough for an array. You need to prepend either the length of the string, or the number of elements in the array, to the string before you send it. On the receiving end, read that length and use that to determine how many bytes of data you need to read. Also, check the representation of your array constants; you do not need the conversion to DBL after the typecast.

It's really closed, like with a queue or notifier.

I see something like this regularly, and as far as I've been able to tell in my case it seems to be a combination of using classes, and storing everything on a network drive. Whenever I see LabVIEW lock up temporarily my network usage also goes up (according to the Windows task manager), as though LabVIEW is reloading a lot of files from disk at once, which it might do more frequently when using OOP classes for some reason.

I think this is the same bug I found in 8.2. It already has a CAR assigned but I have no idea if it was fixed. EDIT: Oops, should have checked before posting... it was reportedly fixed in 8.5. Might be a related problem, though.