todd

Yes, the IDE is stable until a user does something less than ideal, So instead of a user having to learn what will work, perhaps the IDE can teach us what won't work. Perhaps show the user what's taking so long.

Live links are down due to spam. If you place the cursor within the link text and click the "Unlink" button (just below the smiley face, for me), the link text shows up:

I've only done two medium-size projects in 2013 (<2,000 VIs). Classes, Actors (now that I've got the lvlibs partitioned properly), ACBR. So far, so good.

http://forums.ni.com/t5/LabVIEW/Darren-s-Occasional-Nugget-05-09-2012/m-p/1984687#M655336

Several projects, here, show dirty dots when opened. After saving, though, tortoise says the file has not changed.

OpenG Pipes: http://opengtoolkit.cvs.sourceforge.net/viewvc/opengtoolkit/pipe/ ogp file (still installs with VIPM): http://forums.ni.com/t5/LabVIEW/Controlling-the-STDIN-STDOUT-of-a-legacy-application-in-LabVIEW/m-p/1103853#M487810 NI cross-post: http://forums.ni.com/t5/LabVIEW/Streaming-commands-to-a-python-console/m-p/2613903/highlight/true#M783840

Could you filter the timeout error when it occurs, and report the unit ID - perhaps in a warning?

Cross-post: http://forums.ni.com/t5/LabVIEW/Radio-button-refnum-control/m-p/2613039#U2613039

So VISA read works when you read from an instrument that exists, and VISA read times out when you read from an instrument that doesn't exist? That sounds like expected behavior.

I'm wondering about the Samples per Channel input on the acquire VI. You have it tied to the buffer size. procons_t.llb

The numbers kind of line up with these:

Arg. Sorry, I mis-read the requirement. I haven't seen anyone post a tool for that.

Sorry, crossed my wires. Check out "Rename LVOOP Labels" in the NI LabVIEW Tools Network. I think it shows up in default VIPM repos. http://lavag.org/topic/15258-team-lava-rename-lvoop-labels-now-cwlv-silver/?hl=%2Brename+%2Blvoop+%2Blabels

Have you tried the LVOOP assistant? http://lavag.org/files/file/132-lvoop-assistant/

http://lavag.org/topic/17063-openg-libraries-on-computer-that-cannot-be-connected-to-the-internet/

Does there need to be a "Swap Values" prim in there?

2011 and 2013, too. Whether it's a downcast or a default value, I would still need the reference types, correct?

Like this: I don't like the idea of picking refs off the FP from within any subVI because then I might as well be using a single-loop for everything on the BD. A single loop with access to everything seems to make it easier to cause unintended consequences. If smaller pieces of functionality exist in separate loops, the only difficult part may be "hmm, which loop was THAT part in?". And that seems easier to manage.

I hear you. I'm sensing some kind of poly VI that outputs the correct reference based on a string. I don't want to do that in this project - I'd rather have one VI for each cluster that does the casting so the refs can be passed to the loops. It feels like a smaller maintenance choke point (one VI per cluster). I like variant attributes. I wonder, though: when it's time to use the reference, it still needs to be casted, right? At the moment, I'm thinking I'll use one subVI to "manually" step through the cluster Controls[] and feed them to the typedef'd cluster of refs.

I had to sniff an RS-232 link for a project. An additional RS-232 to USB adapter with only the Rx line connected to an existing com channel worked pretty well. Had to read one Byte at a time instead of term chars to not lose sync. The only problem was I needed better than 1ms accuracy on packet start times with relation to some other signals. I did an analog acquisition of the Tx line at 3x the bit rate. It was pretty straightforward to down-sample to one '1' or '0' per transmitted bit. Then a simple state machine to turn the bits into Bytes.

I'm bundling FP control refs and sending them to subVIs (kind of like how I do AF actors: bundle the refs into the actor's private data). In order to make the BD smaller and easier to read, I'm playing with putting the groups of controls in clusters, then sending a cluster ref to a subVI that produces the named bundle of control refs. I'm looking at vdata and to-more-specific for the cluster-ref-to-bundle-of-control-refs conversion. Is there an easier way? (By the way, very little VI server work is done in the subVIs. It's mostly dynamically registering for change value events.) The image isn't much help, but here it is:

!

Please read about the Nyquist Theorem. http://en.wikipedia.org/wiki/Nyquist_frequency https://www.google.com/search?q=nyquist+theorem&rlz=1C1LENP_enUS552US552&espv=210&es_sm=93&tbm=isch&tbo=u&source=univ&sa=X&ei=Th1cUo6NCOOJjAL934C4BA&ved=0CFAQsAQ&biw=1920&bih=995 If the MyDAQ can only update at 200kHz, it can not create a 150kHz signal.

Then you need a reconstruction filter in hardware. http://en.wikipedia.org/wiki/Reconstruction_filter

Find out what the device is.