EricLarsen

You make a good point here. But I don't think I'd want to make a blanket statement that you never want to implement something like this in a UI. Therefore I whipped up this little VI that does what I was thinking about. It borrows heavily from François' example. Just another tool for the tool box. Yep, I get to experience that particular joy next week when I start training operators on my new UI. It's always a bit humbling when you get to find how easily your foolproof software can be fooled. User Input.llb

In general, each time the user changes the value of a control, a command gets sent to an instrument. For example, if the user changes a furnace setpoint from 200 to 201, a serial command gets sent a furnace controller, which takes a finite amount of time. There isn't any reason to tell the furnace controller to goto 201, then 202, then 203..... Generating serial commands too fast to some of these instruments can cause communication problems. Sure, there are ways to prevent this from happening by ensuring the code you use to communicate with the controller doesn't overwhelm it. But it just seems to me like this is a common enough UI issue that there should be a universal way to deal with it.

Ideally I'd like an event generated after each control is updated. I'm afraid that probably wouldn't work. A user could change a control, then walk away with the mouse still hovering over the control. Then it wouldn't generate the mouse leave event. In this case, it would only be a matter of time before a user changes the control, then forgets to push the go button. Then I'm getting a late night phone call wondering why the furnace was set to 210C is only running at 200C.

Let's say the value is 10, and the user clicks the increment button 30 times. I'd like the user to see the control change to 11,12, 13.... so there is visual feedback that the clicks are working. However, only when the user stops clicking at 40, and doesn't click the control again for 1 second or so, then an event is generated that sends the value of 40 to an instrument.

This question has probably been discussed ad-infinitum elsewhere, but I can't find a good answer. I'd like to ignore multiple value change events on a numeric control and only generate an action based on the latest value of the control. This article discusses how to ignore events that involves a single "mouse up", such as continuously holding down the Increment or decrement button. However, I (and most of my users) typically change a control with multiple clicks on the increment/decrement buttons. It would be nice to come up with a simple drop in solution that would only generate an event after the user has stopped clicking. And since I may have dozens of controls on the User Interface, the simpler, the better. I've hit a brick wall for a solution. Any ideas?

You've really hit on the $64 million question in neural net programming. Pre-rocessing the data into a discrete form that can be trained into a neural net is the most important factor in determining a net's success. There really isn't a one size fits all approach that will work for all time variant signals. In your specific case, the most likely difference between male and female voices is frequency. You might try doing an FFT on portions of the song and dividing that up into discrete frequency bins. The relative values of the bins are then fed to the input nodes of the net. Doing a search on neural networks and voice recognition will result in thousands of hits, one of them might be useful. Here's a few things I've learned the hard way. Always normalize your input data set, variation is signal strength will really throw off your results. Make sure you randomly select values out of your training set for your test set. And collect as many training sets as you can.

Interesting, never thought of that. What mechanical action do you use for Boolean controls in this situation?

Yep, the way to increase resolution is to take more data. Here's an article explaining that: http://zone.ni.com/devzone/cda/tut/p/id/4278 The tough part for you is the frequency of interest. If you're really in the terahertz range, which is actually 10^12, to satisfy Nyquist you'll need to be sampling at least twice your frequency. For a df of 0.5 Hz, that 2 seconds of sampling is going to be terabytes worth of data. That's a lot of numbers. You'll have to make some good decisions about exactly what df you need and if you have the hardware to handle that much.

How about using USB/RS-232 converters? Such as this one: http://sine.ni.com/n...ng/en/nid/14583 I've used these on a number of projects (although, I've never tried to use 12 ports on one computer). They work great, VISA sees them as conventional COM ports. You'll want to check power requirements, you might need a powered hub to drive 3 of these units.

I've written a plugin for the RCF that toggles the autogrow on all structrues or selected structures on a diagram. It also acts on structures within structures. If anyone interested I can post it to the code repository.

I've been doing some brainstorming about my next project, and I would like to get ideas from this group for a good software architecture to use. The application will be providing an operator interface to a bench-scale experimental process. The process is a fairly typical one; there will be a mix of valves, flow and pressure controllers, heating and cooling loops, thermocouples, etc. The process will be controlled by a Compact Field Point system. In thinking about the software architecture, I envision a two layer approach. The top layer would be for the day-to-day operations. It would consist of modes like "startup", "operate", "shut-down". Each of these modes would have a series of operations that would occur at the start, such as "open Valve A, Set Flow B to X.XX, etc." The operator would select when the next phase would start, but certain criteria would have to be met before the next mode could happen, such as "temp T1>100, pressure P1>50". The idea here is that an operator does not have direct control over the components of the system, but only makes high level decisions about when to go from one mode to another. The second layer would be where a trusted operator could directly manipulate the system, with commands such as "Open Valve A" or "Set flow B to X.XX". These kinds of commands would only be done during off-normal conditions. But there still need to be limits on when certain actions can be taken, such as "Valve A can only be opened when Pressure P1<50". There would also be alarm conditions that would trigger actions, such as "close valve B if temp T1>150". This strikes me as a fairly typical software architecture. I'm no PLC expert, but isn't this is basically implementing ladder logic in software? I could hardcode a series of rules in the software, but I could see that quickly becoming unwieldy and hard to debug. Some kind of a rules based editor where I could go in and define the rules in advance and then quickly implement that in software would be ideal. Any suggestions? Are there any resources out there that describe how to implement something like this in Labivew?

You probably already know this, but you actually do have a potential for an infinite loop. The maximum value of an I32 is 2^31-1 (2,147,483,647). As you increment from 2^30 to 2^31 you'll jump from 1073741824 to -2147483648, than to 0 for anything past that. If Size control is any number over 2^30, you'll be stuck in an infinite loop. You could limit the maximum of Size or use a for loop with an exit conditon instead.

Thanks for the reply, Ben Property nodes may be part of it, but I found some other examples that also don't work. This one uses a strict type def which may be causing the problem: http://decibel.ni.com/content/groups/northeast-oh-labview-users/blog/2009/09/08/state-machines This one, even the 2-D array constants (which worked in the link in the orginal post) don't work: http://decibel.ni.com/content/docs/DOC-6108

I suspect there is a simple answer to this, but I'll be darned if I can figure it out. Why don't code snippets always work? For example, I can drag and drop every snippet on this page just fine: http://zone.ni.com/d...a/tut/p/id/9330 But when I try and drag and drop this snippet: http://decibel.ni.co...t/docs/DOC-9812 I get the "circle with a line through it" cursor. No error, no explaination, just no drop. It happens all the time on snippets. Is it a version issue? I'm using LV9f2.

Here is a way to display a Google Map in a front panel. Is this what you are looking for? http://decibel.ni.com/content/docs/DOC-7983

There are numerous low power PC/104 cards that could probably do this. The 6W requirement is going to really limit the options. Here is on from VersaLogic that might work. I've never used this one before, but we've used numerous VersaLogic boards and they are a good company. http://www.versalogic.com/products/DS.asp?ProductID=200

After calling Write File, have you tried calling Flush File? If it's some kind of file buffering issue, that might help.

Reminds me of the bad old "pre-undo" days of LV. If you ctrl-click drag on a diagram object, it copies it. If you crtl-click drag on a blank part of the diagram, it moves everything around to create extra space. Before undo, if you tried to ctrl-click drag an object but missed, it would blow your diagram up to 100 times it's normal size with no good way to undo the mistake. The biggest cheer I ever heard at NI-Week was when the word "UNDO" appeared on the screen during a presentation!

I've never had any problem with Labview releasing a serial port. I spend a lot of time switching between LV and Hyperterminal while developing serial instrument drivers and as long as I close the connections it works great. Get a copy of Portmon from Microsoft and use it to capture serial port events. It will tell you WAY more about serial port communicaton that you want to know. But it will tell you if the port is being used by another program and if it's getting closed correctly. http://technet.micro...s/bb896644.aspx

You are partially correct on this. Decreasing speed and acceleration can increase a robot's payload a bit. However, motor torque is only part of the equation. There are also bearing loads, belt tensions, mounting bolt strengths, motor brake strengths, and so on. All these can have an impact on payloads. Robots are actually designed for bigger loads than they are rated for. For example, our custom robot we use was rated for 30kg, but the was actually tested at around 40kg. By the way, our 30kg 'bot weighs in at about 450kg. So the curve isn't quite exponential, but you get the idea. However, the manufacturer is very unlikely to give you the green light to run with a higher than rated payload, and I think you would be taking a gamble. What if a programming error on your part caused the robot to run with too high of an acceleration? Could be pretty hard on some very expensive equipment and would most likely void a warranty.

Check with Kawasaki Robots. They make numerous robots that might fit your configuration and are a rock solid robotics company. A 15 kg payload robot is going to be a pretty big one. As payloads and reach go up, the size of the robot goes up almost exponentially. You could easily be looking at a 200kg robot.

Calling Dlls from Labview is a bit of a black art. The most likely cause of the crash is sending the dll a parameter that's different than what it expects. For example, if the dll is expecting a 16 bit integer and you send it a 32 bit integer, Labview probably going to crash. Sounds like that's what's happening to you. Did you write the dll or do you have access to the source code and/or *.h file? If so, double check that you are calling the dlls with the correct parameters. Sometimes in dlls you'll run across complex data stuctures that don't match very well with Labview data types. It that case you usually need to write a wrapper dll that translates the data types into what the dlls expect. Check out this article, it's a starting point for how to call dlls from Labview. It also discusses the difference between calling a regular dll and a .NET assembly. http://digital.ni.com/public.nsf/allkb/DCB90714981A1F148625731E00797C33?OpenDocument

How about a combination of Mouse Up event and Value Change? In the Mouse up event, grab the value of the control. This accounts for the user either rotating the needle or clicking increment on the digitial control. In the Value Change event, check the status of the mouse button using mouseAcquire.vi. If the mouse button is down and the mouse positon is inside the bounds of the gauge, assume the user is twriling the dial and do nothing. It might take some tweaking to account for all the actions a user could take. Eaiser than two controls? Maybe not, but it might be worth playing around with. Edit : I already see one problem with this. I tend to enter value in controls by typing in the control and then clicking the mouse outside the control. For a square shaped control this idea would work. But because a guage is round and it's bounds are square, I think there is an area outside the round gauge that's still inside the bounds of the control. If the user clicked in that area to enter the value the bounds checking might fail. Hmm...

An easy way to enforce ordering of parallel loops is to use timed loops instead. Wiring a different value to the offset input of each loop will cause them to start at different times.

Does a faster PXI-RT processor reduce deployment times? I'm using an older PXI-8187 controller, and while it's fast enough for the application, the deployment times during development are a bit annoying. Or would a faster host computer help as well?