Sparc

Compare the magnitude of the number and then choose between %f and %_f. At three digits any value between -0.001 and 0.001 would get %f (fixed precision), everything else gets %_f (significant digits). I may be off a zero, but the premise remains.

If no losses are acceptable and buffers are reused, any mechanism proposed will have this problem. That point is not valid criticism. If losses are acceptable a "no wait" path is provided by reusing a buffer from Q1.

The IMAQ wire is a reference to an image buffer. The data they contain isn't copied unless explicitly copied via IMAQ Copy function or IMAQ Get Bytes function or you wire up the "Dest" terminal on the IMAQ functions. Scenario 1: If the Consumer must process every item sent by the Producer the number of buffers must be a size to store the back log. Whether this size is 2 or 3 or 907 is only relevant when deciding or being constrained by the platform it's running on. Scenario 2: If the Consumer is only required to process as many as it can and losses are acceptable, pick a number of buffers that satisfies the acceptable loss criteria. Again the actual number of buffers is irrelevant. Two Queues. Q1 is Producer to Consumer. Q2 is Consumer to Producer. Queue element is same in both and is whatever you want as long as it has an IMAQ reference (buffer) in it. During initialization Q2 is loaded with as many unique buffers as deemed necessary by the Scenario. Scenario 1 Implementation: Producer Dequeues a buffer from Q2. Fills it. Enqueues it to Q1. Consumer Dequeues from Q1. Processes it. Enqueues it to Q2. Since Producer is pulling from Q2, there is no chance it will ever overwrite an unprocessed buffer. Q1 being empty is not a problem. Means consumer is faster than Producer. Q2 being empty is an error condition that must be addressed at the system level. Scenario 2 Implementation: Producer Dequeues a buffer from Q2. Fills it. Enqueues it to Q1. Consumer Dequeues from Q1. Processes it. Enqueues it to Q2. Since Producer is pulling from Q2, there is no chance it will ever overwrite an unprocessed buffer. Q1 being empty is not a problem. Means consumer is faster than Producer. If Q2 is empty, Consumer is backlogged and a loss must occur. Producer Dequeues from Q1. Since an element can only be Dequeued once, there is no chance the Consumer is processing that buffer and it is safe to overwrite.

There's an LED submerged in my cat's water fountain. I had to put the thing together (*some assembly required). That LED lead is literally two wires and some shrink tube. $25 + 35 + Audrino ($25) is ~$85 per drop. 180mm is 7 inches (max). DIY vs. OTS seems like a wash to me. With OTS winning for the reasons people buy OTS.

Taking a trick from racing events: RFID tags in their shoes and RFID tag scanners on the floor near the doorways of the rooms. Maybe not. After checking, the tags are cheap, the readers not so much. Tags: $1.00. Readers: $1000.00. Dropping to a door-acces like reader (which would require the guide to purposely activate) it's about $100 per door. Of course once you're at purposely activating a push button in each room is simpler. Accelerometers? Reset at a known position after after each 'lap' of the maze. A non-trivial amount of DIY involved (microcontroller with WIFI + accelerometer + battery + case + wifi access points) and cost is still about $100 per tracker. Not automatic, but webcams. Your CIC guys would have to check the webcam feeds to see who is where. Infrared. Each guide wears an IR beacon and an IR detector in each room can ID the guide. Smaller hardware requirements than the accelerometer idea. Depending on the Webcam, the IR beacon could assist there too.

These aren't the Big Box Specials where they advertise some awesome spec (9 GHz Octocore CPU!!!) and then cripple the entire box reduce cost with some unadvertised component (66 MHz, single channel memory bus)? I've haven't yet had a 32 bit app run worse on a 64 bit machine. I've had them run the same, better, or not at all -- but never worse (at least never so much worse that I noticed). My hunch is the new computers don't have better hardware in all the right places. For instance the existing PCs might be 4 GHz single core and the new PCs 2 GHz Quad core.

VI corruption. The fact a copy/paste of the code works is a strong clue. I've had many inexplicable problems simply disappear by just copy and pasting entire block diagrams in to new VIs. It's almost at the level that the technique is a legitimate debugging step. To paraphrase a friend: "What? You've never seen LabVIEW do something stupid before?"

Assuming you mean a traditional Windows driver, you can't. You'll nee to use the Windows Device Development Kit and it uses some version of Visual Studio and write it C or C++, I forget which. On the other hand, if you make it with a USB interface and HID compliant you won't need to make a device driver. Windows (and just about every other modern OS) will recognize it and use a built in driver for it. There are many microcontroller products/projects out there that ship with a USB interface and HID compliant stack.

Does this do what you want? timeline_lv2009.vi

The pi is imaginary!

Turned 'em on using a super-secret and private key in the LabVIEW INI file. That correlates well with some other "research" I've done. There are a handful of VIs down in <LabVIEW>\resource\PropertyPages\ that look liked they'd be used with these properties, but they also appear to be orphans as I can't catch LV ever trying to use them. Thank you for the insight.

The Help description is so tantalizing for these two methods it's almost unbearable: "Property Pages use this for generic get/set of properties." The interface to them is dead simple too: one I32 array, one variant. Sounds pretty ideal for a "Property Saver" type tool. Instead of nested case structures and class coercions you just wire an array and a variant to a Generic class method. Unfortunately, I can't get them to work. I've tried a wide variety of inputs to these guys and so far I've gotten nothing but 1058 errors: "LabVIEW: Specified property not found." About the only thing I have learned is if the array has more than 13 elements you'll crash LabVIEW. Searching the usual places has resulted in nothing. But then searching for terms like "get" and "property" turns up many non-relevant results. Has any one else had any luck or have additional knowledge about these two functions?

My guess is you have a DC offset in your data. DCOffset_8.5.vi

A few times now I've needed to dynamically display and resize some XY graphs. And it never seems to fail that after a few iterations I end up with a chart that resembles this: Or worse, I end up with a chart that has a negative size according to LabVIEW: Once this happens there is no way I have found to manually resize the graph. I have to delete the control and drop a new one, and in the process lose my formatting, local variables, property nodes, event cases, etc. "Replace" gives a new control, but at the exact same (negative) size. Today I was fed up and looked to why this happens. This is what I learned. First, you need to know there are two main movable parts to the graph. The first is the whole graph control. This works as you'd expect using the "Position" property. The second is the "plot area" and it is affected by "Plot Area Bounds" and "Plot Area:Size". From the development environment the of size the plot area is constrained by the Graph Control -- you can't make the plot area bigger than the control. When resizing programmatically, the plot area can be sized/moved anywhere in the pane that owns the graph control. Second, properties "Plot Area Bounds" and "Plot Area:Size" do similar things, but affect the Graph Control differently. "Plot Area:Size" will change the size of the plot area, and it will change the size of the Graph Control. If you use this property to increase the width of the plot area by 10 pixels, the width of the Graph Control will increase by 10 pixels. If you use this property to decrease the width of the plot area by 25 pixels, the width of the Graph Control will decrease by 25 pixels. This will be important later. "Plot Area Bounds" will change the size and position of the plot area without doing anything to the Graph Control. If you forget "Plot Area Bounds" is referenced to the owning pane and not the Graph Control, its easy to have your plot area moved to upper left corner of the window while the rest of your graph control sits in the bottom middle. The WTF. If you use "Plot Area Bounds" to make the size of the plot area bigger than the Graph Control, say 100 pixels wider, you can now use "Plot Area:Size" to shrink the plot area to 75 pixels wide and get a Graph Control that is -25 pixels wide. The steps to avoid headache: Simple Move\Resize: This is the typical use case, you need to resize the graph and you don't care how the plot area is aligned within it. Move the graph to the desired position using the "Position" property. Resize the plot area using "Plot Area:Size" and the graph control will resize by the same amount. Resize Graph and resize plot area: In my case I need to align the plot areas of multiple graphs. Because the Y Axis scales are formatted differently, the plot areas of each graph have slightly different positions. Write data to the graph Update the scales Move the graph to the desired position using the "Position" property. Resize the Graph Control indirectly by using "Plot Area:Size" knowing this won't be the final position of the plot area. Reposition the plot area using "Plot Area Bounds" recalling its parameters are referenced to the owning pane and not the graph control. Attached is a VI (LV 2009) that'll demonstrate "Plot Area Bounds" and "Plot Area:Size" DynamicGraphSizing.vi

The following will make me push and then push harder a few times before I figure out the problem.