Phillip Brooks

Sounds like a sourcender situation to me...

Congratulations!

There appears to be a common perception that examples show the "right" way to do a particular task instead of "a" way to do the task.

Is there ever a "right way"?

I learned from my wife years ago that there is "her way" and the "wrong way".

I was suggesting that if the FTP progress is an issue, vote for my meager idea.

I had some off-line correspondence with NI folks regarding the SSH, but I'm more of a consumer and not qualified to provide the level detail that would be required. I still think this should be implemented in NI-VISA .

There was a progress bar question on the NI forums a couple of years ago related to the FTP functions in the Internet Toolkit.

In that case, the file to be loaded was of an exact known size, but the function that transferred the file did not expose the bytes transmitted. Brute force suggestion to the poster was to use a global. A better solution would be to add a notifier that could be monitored for each file transfer session.

Vote for it if you use FTP, but what I'm really looking for is a total rewrite of the toolkit and native support for SSH/sFTP.

For a loader, the percent progress for loading a VI hierarchy could be approximated by knowing the number of VIs to be loaded and the current number in memory. As Aristos pointed out, the 99% issue exists when the last VI to be loaded happens to be the biggest (code size or data/memory allocation size).

No idea. Just assume LabVIEW was out for a night of heavy drinking and was hungover the next day. Dock its pay and put it back to work.

But NI week isn't until August...

If your number of ports is more than eight, maybe you could use a terminal server instead. Our ESS setup uses two 16 port terminal servers to attach up to 32 UUTs via RS-232.

We have a mix of code that uses NI-VISA configured for a raw socket and/or use the Internet Toolkit Telnet VIs to the ports. We run from four to 16 hours using TestStand to execute command line tests on the UUTs. Our biggest problem to date has been the reliability/quality of the UUT diags...

Most terminal servers can be configured for 232/422/485 on a per-port basis. I haven't used any of the latest, but some include COM redirect drivers much like the USB-Serial devices to make interfacing easier...

Maybe use compare elements and then exclude the items you're not interested in; a variation of this:

http://lavag.org/topic/7335-wildcards-with-search-1d-array-prim/page__p__42656#entry42656

This same code was posted on the dark side, and promoted on LinkedIn with the same link (below)

https://decibel.ni.com/content/docs/DOC-18612

Self promotion is fine, but spamming every possible forum with password protected code creates a negative impression of the poster (for me anyways).

I recall having some weirdness with "Get Text Rect" not working well with italic and bold fonts.

I ended up padding by +(x)% of the width to make things 'pretty'...

is anyone a member of the LinkedIn group that Martin mentions?

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

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 woods are lovely, dark, and deep:

After several weeks of research, the conclusions are:

• Results are significant but not statistically so.
  
  • It is clear that UDP can be made reliable.
    
  • Packet loss was due to buffer issues and not network congestion.
    
  • Software architecture has an impact on buffer maintenance.
    

  [*]More discovery/research needs to be done regarding:

  • ​Optimum signaling for threads receiving UDP.
    
  • What is the interaction of buffering between VMs and the Host.
    
  • What is the impact of different NIC driver parameters on buffering/responsiveness.
    
  • Need for education (e.g. back to basics)
    

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

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?

Imagine if one of the significant LV users who has a high trust/recognition among the community were to say, "I have created one VI package that installs everything free that I consider valuable to upgrade my LabVIEW experience."

...

A lone developer deciding to maintain such a package and add to it whenever he/she saw something interesting on the forums would be valuable. An ad hoc group might form around him/her to advise on "posts that should go into <Your Name Here>'s LV Patch".

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'm going to throw my R&D two cents in here in support of "what Lynn said". You've built a flat sequence structure when what you need is a case structure inside a while loop. You can popup on the flat sequence and choose "Replace with Stacked Sequence" and then you can pop up on the stacked sequence and choose "Replace >> Replace Case Structure". Having done that, put a while loop around it and wire the terminal to the ? terminal.