Gan Uesli Starling

I have a LabVIEW program, which when operating with simulated input data is blazing fast during mock-up. As soon as I hooked into a real cDAQ on Windows, however, the update speed fell off to 4 seconds. That's awful slow. I don't really have a whole lot of channels. I have read tasks for Volts of maybe 5 channels, write tasks for both On./Off for maybe 10 channels (simultaneous) and write tasks for 4-20mA of only 5 channels. How may I improve on that? Is it maybe a priority issue in Windows or to do with USB? What? How to improve? Thanks in advance.

So I'm calibrating a NI-9205 as voltage on a range of 2-10 VDC (the differential of 4-20mA through 500R). And one channel is behaving oddly. It clips at 42% of its 50 PSI scale, but only while measuring via scale, not while measuring volts. I'm setting pressure via a dead weight standard, pressing air into a Specter sensor which outputs 4-20mA. I'm measuring it as V across 500R because I need to filter it with a Sallen-Key active filter (a retro-fit to eliminate pump ripple from out of the signal). So, anyhow, Ch 0 on the NI-9205 is fine in all ranges from 2 to 10 VDC while measuring volts. Let me turn on the scale, however, and then it's nice and linear right up until 21 PSI where it clips. The proper voltage is there. I am double checking it with a Fluke DMM. I can add weights on the dead weight standard right up to 50 PSI, and while set to show Volts and not scale, then NI Max shows the right volts. At each PSI level, I can switch back and forth between Volts and scale on NI Max and both are good right up to 20 PSI. Above that, however, and even though Volts keeps on climbing, scale clips and holds a t21.345388 PSI. I have tried remaking the scale. I have tried that same channel with other scales. Those other scales too (all for ranges of 2-10 VDC but different PSI ranges) all clip at 40% of their full scale on this channel only. I have swapped out the NI-9205 and the new one does just the same. Any ideas?

Hmm... The Waveform Charts can display as "stacked plots". There is a checkbox for that in the front panel as an option. It is very like a digital oscilloscope, yes? And in my Yokogawa DL850 scope (and others) you can divide the screen into sections (or plots, stacks, whatever may be the most correct term). And in each of those sections (on the DL750 and others) you can have more than one trace. So, for instance, I could be viewing Temperature in one section, with all my temp data there, Pressure in another with my transducer data there, and Flow in another with all my coriolis meter outputs there. Similar types of data, in similar ranges, all nice and tidy. All on one device (for a scope). I was hoping for the Waveform chart to emulate this behavior. But if need be, I can call separate Waveform charts, one for each type of data. It just seemed less tidy, plus a bit more bother for having to deal with plural references (versus one) to thread the controls down through sub-sub-sub-routines via cluster. Sorry this is taking up so much of your time. It seemed a simple concept to start. Perhaps I was wrong.

Thank you for that. However, it seems I explained poorly. So I beg pardon. I should have said, upper and lower "stack", each with 3 lines, both stacks on the same chart. This as opposed to needing two separate charts, thus to keep the two simultaneous. Two, because with auto-scale in Y on the same non-stacked chart, if PSI is in the hundreds while PPH is in the teens, the PPH will be sorely squished down. Your otherwise very fine example is showing six lines in a non-stacked chart. Playing around I somehow managed, quite accidentally, a 2-stack plot with one line above and two lines below. But I've no idea how that occurred and have not been able to reproduce it.

So, to paint a picture... In the TOP plot, three lines corresponding to Pressure in PSI: The ACTUAL pressure as a solid white line, read from a transducer. Above that (hopefully) a dashed red line corresponding to Do-Not-Exceed value for the present circumstance (a constant). Below that (hopefully) a dashed red line corresponding to Fall-Not-Below value (another constant). In the BOTTOM plot, three lines corresponding to Mass Flow in PPH, and that with it's own set of three lines, like for above. Now, the two plots are simultaneous, and of significantly different magnitudes, so that one would end up squished small if on the same Y axis. Hence two plots. Now also, the waveform chart would be zeroed out between changes of circumstance. That is to say, each circumstance would be one step in a staircase of values across the range, some very small, others quite large. Thus the tolerance for max & min, plus the value itself, would be squished down from auto-scaling once higher values passed through the view. So I break up the display into circumstances of one stair step each, with each lasting a minute or so.

Granted that I could do this very thing with two single-stack charts of 3 traces each. I could do that... However... What I'd very much prefer is to have 1 chart with 2 stacks and 3 traces on each. So my question is...Can I do that? And if so, how can I do that? I'll tell you what this is for... I have a test stand measuring pressure and flow. I want to show the current value for each in a separate, vertically stacked plot, with also the current max and min limits as dotted red lines. The settings are progressive steps, each with a different max and min for both those values. I want the operator to not have to think, only just look at the cart, and to know in an instant if it is performing amiss. Also an aid to troubleshooting. Save me a lot of headaches and interruptions down the road.

Very informative and to the point. Thank you. I switched from \\Foo\ to \\ plus dotted quad, and it works fine now.

Attached is my VI for writing a tiny HTML file to a intranet network directory. This is on Windows for writing to a file path like \\foo\bar\wtf.html (fictional!). But when the network is slow (quite often) the file write will fail. I've got a patch in there so survive the error and just wait till next time. But what really I need is a way to tell the write to hang in there longer and not give up just because there's no reply yet. My temporary work-around is to open a Windows file browser to that path, the twiddle my thumbs until the file list populates. Then, the path being established, I may safely start the parent VI of which this VI is a sub. Any ideas? Write_HTML.vi

Thank you both! I shall try them out on the weekend.

Can someone example a VI for obtaining the current X & Y screen position in pixels for the mouse? This is for a little widget I'd like to make to assist me in judging sizes of objects from a photograph. I'm going with LabVIEW instead of Perl, etc, just to save myself from having to mess with writing a GUI. So the idea would be this, In a photograph I know the size of one item and want to derive the approximate size of others by comparing their relative lengths (ignoring parallax) and just doing the trig. I have that working already but only in combination with GIMP while eyeball reading and manually punching in each separate X & Y, which is a pain. By contrast I could do it in Perl, but then I'd have to write a GUI, which in Perl I've not done for years.

Needing to capture a peak value. Not willing to rely on sofware timing for fear of missing the actual peak in between LabVIEW read cycles. So...might anyone know of an NI hardware (module or standalone) which can capture peaks on its own, holding that value until the next LabVIEW read query? That is to say, an amplifier with this built-in (possibly as analog) inside the module? Sure, I can build one from scratch, but it seems a feature many others would want. I rather think that NI might have it as an option in one or another module for CompacDAQ, etc. But I fail to locoate it and NI's website is not much help, directing me off in different directions. And yes, I know I asked a similar question one time before, but got only a software answer. I'm specifically interested only in a hardware recommendation. The software iteration loop is intrinsically too slow.

I half expected as much. I'll just re-write it. Thanks for saving me the futility of trying in vain.

I have a built *.exe which I wrote myself two years ago but for which I have since lost the source VI. Said original VI was small so that I could write it anew, but am hoping for a lazier way. I'd like (if that's possible) to just un-build that foo.exe so as to get the original foo.vi if that is possible. I was thinking to put it in the public domain once I do. How I losts the VI is that between then and now I'd got a PC upgrade at work and must have neglected to copy that over (it not being an official work project). What the little program does is only some math. I have attached it as a ZIP. It's a conveninece util for doing trig on bit map pictures. Say you know the size of one item in the picture, You enter that. You also enter the X,Y pairs, end-to-end for that item. Then to know the size of any other item in the same pic (only approximate because of ignoring the camera's parallax) you enter another set of X,Y pairs and violla, it does the trig. Very handy for guestimating proportions so as to create 3D models from photographs of real-world objects. I didn't have LabVIEW on my home PC so I built this up at work, but in a directory not where I keep my work-related LabVIEW projects. And hence I forgot to copy it over when I got the new PC. Virtual Calipers.zip

Good to know! Made immediate use of that. Thanks. Our test lab here mostly uses a generic, all-purpose LabVIEW program which I've been adding to and modifying the past three years. There are umpteen channels of each kind of cDAQ module we have in house. All are addressed via reference. Over the years it had grown...and grown...and grown yet more into quite a LOT of references. So things were starting to bog down from the overhead to such a degree that some of our slower PCs didn't like to run it at all (still a few Dell GX620's in service). So I was just recently getting around to writing a VI for to strip away, on the fly, unused channels from the arrays-of-clusters-of-references just before those outermost array's wires enter into the main execution loop. Armed with the handy info posted here, it was easy enough to also close the references inside said strip-away loop. Very timely indeed. Thank's for posting it.

I have attempted to address the issue with the Icron Ranger 2204 unit pairs by updating them to latest firmware supplied by Icron Support (91-00083-R05.exe). This update of firmware had no beneficial effect on this particular problem with communicating to the NI 9237. I have informed Icron of this and await their further suggestions. Meanwhile know that the Icron Ranger 2104 unit pairs continue to serve my LabVIEW purposes well. It is only the 2204 units which have this issue.

Update: I've spent two hours mixing and matching my USB2-Cat5-USB2 extenders and have more complete results. While none of the Ranger 2204 pairs I have tried perform reliably with the National Instruments cDAQ-1978 having a NI-9237 installed, all of them cause the LabVIEW program to hang at some point, I do have another model, an Ranger 2104 pair having SN’s ICL2101903-009845 and ICR2014903-005975 which appears to be working fine, at least so far. Models & SN’s of Ranger 2104 pairs which work okay: Model P/N 10-00117 SN ICL2101903-009845 Model P/N 10-00119 SN ICR2104903-005975 Model P/N 10-00117 SN ICL2101905-020378 Model P/N 10-00119 SN ICR2104905-006207 Model P/N 10-00117 SN ICL2101912028137 Model P/N 10-00119 SN ICR2104912009732 Models & SN’s of Ranger 2204 pairs which cause LabVIEW hangups: Model P/N 10-00153 SN IC2204L003612 Model P/N 10-00154 SN IC2204R003612 Model P/N 10-00153 SN IC2204L002365 Model P/N 10-00154 SN IC2204R002365 Model P/N 10-00153 SN IC2204L006293 Model P/N 10-00154 SN IC2204R006293 Model P/N ? SN IC2204L-04-007412 Model P/N ? SN IC2204R-04-007412 So, oddly enough the oldest USB to Cat5 extenders, the ones I bought first, the 2104’s seem to perform okay but all of the newer 2204’s, which I thought were nicer because they’d sit on top of the PC where I could see the readout LEDs are sources of trouble. I am in communication via Email with Icron to see what might be the issue.

Alas and alack, I get this... Your request to URL "http://imgur.com/" has been blocked by the McAfee Web Gateway URL Filter Database. The URL is listed under categories (Media Sharing), which are not allowed by your administrator at this time. Likely it will be the same with any of those. When I'm desperate, I got to B&N and use their WiFi, but it's a fair drive from work.

To Jordan & Mellroth: No worries, I'm not so thin skinned. Among an infitity of things in which I am not an expert, LabVEIW is just another. That said... If I take the Icron Ranger 2204 USB2-Cat5-USB2 extender out of the connection link, replacing it instead with a pair of daisy-chained, USB2 repeater cables, then my LabVIEW program works as expected, sometimes for up to two hours. If I do get any error on the those, daisy-chained cables, it's temporary failure to recognize the cDAQ at all, whereupon I get a "device found" pop-up from windows. The program also works fine as is if I bring a laptop into the combustion lab test cell and plug in the USB cable from my cDAQ directly.So my suspicion would be that it has to do with the Icron extenders themselves. Timeout: I have set my timeout up to a full minute to the same effect. Sample rates: I have tried increments everywhere from 1613 to 50,000 all to the same effect. Read later in the program: This would be hard to do. But it's a loop and often does take a reading on the first loop, sometimes several, before it hangs. Longer delays in the loop: Tried this just because. Does not seem to help. Timing: I use the internal clock. Updates: I pretty much always have the latest. We're on NI's annual renewal plan for two Full Development licenses. I have twenty some other channels being read all in the same loop and none of those give any problem. These are thermocouples, current AO's and AI's, a digitial output. My single bridge channel is configured for Finite Readings, 2 Samples only of just one channel, on the internal clock at any of the speeds told above. I really only want one single reading per loop. I could get that using a voltage channel but I was really looking forward to the simplicity of not having to hook up an external power supply every time just to get pressure readings from my Sensotec units. So I bought four of these cDAQ bridge units on my annual capital budget. They're starting to become an embarrassment to me. I'd like to include a screenshot but I can't seem to upload it directly and am having trouble finding someplace to put it where I can just use an URL.

This is the specific error I keep repeatedly getting, but only when trying to read a channel of the NI 9237. Sometimes it stopps immediately, other times it chugs along nicely for a few readings first. Error -200284 occurred at Inputs_Read_All.vi Possible reason(s): Some or all of the samples requested have not yet been acquired. To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate. If your task uses a start trigger, make sure that your start trigger is configured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If this is the case, supply an external clock. Property: RelativeTo Corresponding Value: Current Read Position Property: Offset Corresponding Value: 0 Task Name: _unnamedTask<A89> I can get it to run quite a bit longer by daisy chaining two 5-meter USB 2.0 extender cables end-to-end (routed under the door) but then, after enough time, the cDAQ itself momentarily fails to be detected and I get a "device not there" error. So that's no fix either. Alas and alack.

To "Jordan Kuehn" and "Hooovahh": Our IT Dept pushes us to use these small form factor Dells which have only one Ethernet connection and our Ethernet has a lot of restrictions. Very specifically, I'm forbidden to put in a switch (which might add latency there, as well).

To JamesMc86: These are all the cDAQ units I presently use. Green have given me no difficulty whatsoever. Only the red ones have been a problem. I mix and match them variously for different tests. Obviously I don't have the bucks to just replace 9 USB cDAQs. Qty Model Description 9 NI-9178 Compact DAC, USB Chassis, 8-slot 7 NI-9203 Analog In, Current, 8 Ch SE 10 NI-9205 Analog In, Voltage, 32 SE/16 DI 11 NI-9213 Analog In, Thermocouple, 16 Ch DI 1 NI-9263 Analog Out, ±10 V, 4 Ch 11 NI-9265 Analog Out, 0 to 20 mA, 4Ch 1 NI-9274 Digital Out, 24 VDC Max , 8 Ch 6 NI-9435 Digital In, ±5 to 250 VDC/10 to 250 VAC, 4 Ch 7 NI-9485 Digital Out, 60 VDC SSR, 8 Ch Only the four that I have of this model give me problems: 4 NI-9237 Analog In, Wheatstone Bridge, 4 Ch DI I think latency is indeed an issue. I have only one cDAQ chassis on this Dell Optiplex 790 MT. But I can get a few readings on the 2-port USB before it hangs, never more than one or two. If I'm plugged into the either of the 4-port USBs it hangs on the first scan. May I add that I'm only trying to read one single channel of that Wheatstone bridge module.

To "asbo": The problem manifests with plural, identical NI 9237 modules. To "hooovahh": I would like to have considered that before having acquired almost ten of these cDAQs slowly over the last five years. At the time the idea was to have them compatible with any PC. We only have a two, 3-instance, Full Development licenses and propagate some VI's as built applications. Also, our IT department has fairly draconian views with anything we do on Ethernet.

For years I have successfully used the Icron USB Ranger 2204 Cat 5 Extender with both cDAQ and SCXI. But now I have one very annoying issue. I only recently purchased some NI 9237 units for my pressure transucers. Those, and only those, modules don't seem to like being polled over the USB-to-Cat5 extenders which I have in both of my test cells. I have timing issues. Not with all of them all of the time. But with all of them some of the time and with some of them all of the time. I get that pop-up message that says not all of my channels have been read. Increasing the timeout even to ridiculous lengths helps not at all. The rest of the porgram works just fine so long as I do not assign a bridge channel. So, what gives? I can't go bringing my PC closer to the test setup because of safety reasons. We're a combustion lab. I don't want to have to be stringing out long wires all of the time because we're a test lab and those get set up, taken down, changed all around every week. It's a big issue. Can anybody recommend a USB extender other than the Icon which they have used with good success on the 9237 units? All that I am trying to read are finite samples, just two of those, and the speed doesn't matter much. I've already tried different speeds to no avail.

Iteration loop speed is much, much too slow to capture a spurius event happening at, say 1250 Hz. The probability of the spurious event happening right at the time of an iterated reading is very remote. It just wouldn't work. Reaching back into my electronics days, the way to do this in hardware would be to charge a zero-loss capaciter through a shockty diode. Two pair of such circuitry, one for peaks the other for valleys. Said charge(s) would be tapped without loss by an amplifier of near infinite input impedance. The max pean and min valleys would be stored between iteration loops for reading. Once read, the charges on the caps would be shorted to ground. Like so, over and over. Always the max peak and min valley gets stored on those caps for reading, even though they happen BETWEEN iteration loops. So I guess what I'm asking is whether any of the NI modules (preferably one for cDAQ) is useful in this kind of mode.

Am wanting to know if it is possible to acquire peak & valley readings for voltage (amplified signal from accelerometer) over long durations but with non-huge data files. So not a time history file representing waveforms. Rather a collection of max peaks and min valleys (or even just envelope span as an absolute magnitude) at regular intervals. That is to say the greatest one which occured during said interval. Say my vibration table is running a 10-hour dwell at 1250 Hz, what I'm wanting to do is splice into the acclerometer feedback signal (post amplification) and keep a running log of the max peak and min valley (or said span's greatest magnitude) sampled only at much longer intervals (say once a minute). I am needing the readings sampled to be only that, the max peak & min valley (or greatest magnitude) that transpired during that 1-minute interval (even if it happened only once but without couthing how many). What I don't want is the instantaneous value at the time of sampling which would be useless. Hope that's clear. I've had that feature on other instruments (peak/valley sample & hold, reset at intervals) but am unsure how to accomplish it in LabVIEW. Not even sure if it's a feature of the hardware. Can I do it in voltage using a cDAQ and 9205, for instance? If so how? If not, any suggestions?