Phillip Brooks

I am. I'll check it as soon as I have some free time...

A great candidate for a <vi.lib> patch distribution from the LabVIEW Minutiae thread on the dark side: http://forums.ni.com/t5/BreakPoint/LabVIEW-Minutiae-that-may-bite-you-someday/m-p/1973519#M19044

http://en.wikipedia....elated_software The Ch interpreter is a C/C++ Interpreter that can be embedded into LabVIEW for Scripting.[8]

It seems that NI is in the process of developing drivers for IEC-61850. http://forums.ni.com/t5/LabVIEW/IEC-61850-and-IEC-60870-5-103/td-p/1868231#M633636 Maybe you could contact your NI rep and get more info or help them test their driver..

Decided to Google IEC61850 and UDP. I found this interesting PowerPoint presentation in PDF form. http://www.pes-psrc....%2002282012.pdf I liked the next to the last slide best: The author indicates that dropped messages are statistically insignificant. They were never able to eliminate them completely. If you're just starting out with LabVIEW, this is going to take you some time, and I would wager that you will never achieve zero data loss using UDP.

Between the posts on the NI forum and here, I think everything the OP needs is available. Either the assignment is to learn that something is not feasible, or the instructor doesn't have a clue. http://forums.ni.com/t5/LabVIEW/file-transfer-using-UDP-protocol/td-p/1958549

You can increase the udp buffer size under windows by accessing the socket. See my post from the NI forums... http://forums.ni.com/t5/LabVIEW/Change-UDP-Socket-ReceiveBufferSize-under-Windows/td-p/483098

I hope the recent VLA patch notice via email was not an attempt at a prank

http://zxing.org/w/decode?u=https://lavag.org/uploads/monthly_04_2012/post-26690-0-71182500-1334258067.png

As Rick Santorum can attest, a #1 Google search can certainly affect your image. I would point out that there have been some lively discussions on NI's own forums. This one is a classic. http://forums.ni.com...ons/m-p/1908003 There are a few NI employee posts in there, but much of the discussion is between users. In the end there was still disagreement, but kudos to NI for not purging it as Apple and AT&T sometimes does because the discussion "besmirches the brand". The response to David's post in the Wordpress link you provided pretty much ends the conversation. Richard's response was: He states that he cannot think clearly, that passion takes the place of logic and that his personal situation somehow makes NI's products bad. We just have to accept that sometimes "haters gonna hate"

Maybe there's still time Emilie... New Year in Southeast Asia is celebrated on the 14th of April (or there abouts depending on country). I'm attending Thai New Year at the Wat in Boston this Sunday. Maybe the joke could be Unicode Support Added to LV

I just thought of what could be the perfect April 1 presser. It combines LabVIEW, augmented reality glasses and VI Analyzer. Any programmer wearing the glasses would see real-time suggestions for improving the code while it is executing with highlighting turned on. Users could write their own analyzer tests to implement features like 'bleach dead code' but the only way to see the results is using the glasses. An optional Source Control add-on would allow for displaying check-in comments and allow the user to highlight code changed by a specific user (identify code that is suspect) Not only would the well equipped LV programmer look friggen' awesome, but it would help NI sell more hardware. Isn't that what LabVIEW is for anyway?

Are you volunteering? Aristos Queue's LV Patch has a nice ring to it. Or maybe The Captain's LV Patch would be better

I would limit the definition of a patch to be changes to NI provided code. Examples would be a fix of Riffle, updating NI VIs that contain oldvers and compat type sub-vis that NI tells us we should stop using (but they don't ) and fixing the fact that Telnet Buffered Read is not reentrant and causes numerous problems when used with TestStand. Maybe a template copy of a LabVIEW.ini file with cool features from the wiki disabled and with comments( super-secret baby!) (We might be able to help more if a few less VIs were password protected )

Why do you want to use a stacked sequence structure? I suspect that the majority suggestion on LAVA would be to convert the flat seqs to sub-vis. If they are old and work, don't mess with them; especially if you aren't touching the code inside them. People usually use flat seq structures to enforce order of operation and a seemingly simple change can break things badly. They did this because they don't understand dataflow which means they don't know LabVIEW and that means there may be other monsters waiting to bite you. If the flat seqs are large (complex) and need to be modified, it might be better to create a sub-vi. Within the sub-vi, they can be converted from a flat to a stacked seq structure and then finally to a case structure that can be wrapped with a while loop and some shift registers to be turned into state machine. You can even use a diagram disable structure to leave a copy of the flat seq in place as you refactor. If something doesn't work, you can just use the old code until you have time to 'do it right'. If the flat seqs contain locals or property nodes that modify data not related to the code within the structures, you've got a whole big, ugly, nasty bag of butt hurt that can't be fixed with sub-vis or get better by adding a stacked sequence structure. The block diagram of your top level VI may look nice, but the next person looking at the code won't be any happier than you. When I open a piece of code that contains nested sequence structures, I become instantly upset to my stomach. My choices in order of preference: 1. State Machine 2. Flat seq structure 3. Anything else ( ) 4. stacked sequence structure P.S. Remembered this from the NI Idea Exchange: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Splitting-and-exiting-flat-sequences/idi-p/1535798

I guess all good things must come to a 404... http://www.ni.com/news/releases/april1201.htm

A weak CRC is better than NO CRC over an unreliable transport. Remember that for many years (decades) most devices RECEIVING the message were classically very resource or processor limited and simple bitwise checks on the receiver are low overhead. If the device in question is using anything other than RS232/485 then I'm guessing somebody wrapped a dinosaur in a box, hid a "XYZ to RS232" converter in it and called the product "New and improved" with a price tag disproportionate to the cost. I can make such a statement only because I've been an unwilling contributor to such a thing.

I have no idea, but I did read this post on the dark side just the other day and wondered what the heck a quadtree was...

8.2!

The spec sheet for the T-10 (http://www.konicaminolta.com/instruments/products/light/illuminance-meter/t10/specifications.html) indicates that there is a fast and slow mode for analog output. Maybe check the settings of the unit...

Do they involve registering or testing a refnum? Feels a bit like watching "What's My Line?"

Cross link from the Idea Exchange: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-References-to-be-Wired-into-Case-Selectors-to-Check-for/idi-p/1022833 Would the implementation of this idea make this situation less likely?

Also, if the queue is created as a result of an error using enqueue, the subsequent pass through the loop does not pass out the newly created queue (use default if unwired). Zombies!