viSci

It appears that in a built application, the Undo from the App menu works for all UI control value changes.

I seem to remember that at one time the LV runtime did support a basic Undo functionality.

I have found that disabling the Nagle algorithm (using Visa Property TCP NoDelay) greatly improved the responsiveness of my tcpip communications and alleviated intermittent lockup between the raw socket ping and my TCPIP transactions.

So far, the best solution I have found is based on the Raw Socket Ping library where I can consistently achieve 50ms pings. Thanks Rolf! https://forums.ni.com/t5/LabVIEW/Ping-Ping-Ping-Native-Win2k-LV7-code/m-p/708672?view=by_date_ascending#M324556

Thanks for all the replies! I tried the ICMP approach courtesy of https://forums.ni.com/t5/LabVIEW/A-list-of-IP/td-p/4174564 but still cannot seem to get the timeout to work for values <500ms. IcmpSendEcho_Ping.llb

Greetings All - I would like to quickly ping an array of instruments to determine their availability. If the ping is successful I open up a tcpip port, transact and then close the port. The problem is that the ping vi's I have experimented with do not respect the timeout parameter or have memory leak issues when opening and closing socket resources. I have found an intermediate solution using a raw socket approach but sometimes the socket hangs under various circumstances. Probably the cleanest solution would be to use the .net ping libraries if I could get the timeout to work correctly. Any ideas? BTW I am an admin on the test computer.

Experienced 5S purges at a large aerospace company recently. Truckloads of semiconductor and component stock Many dozens of Monitors, Xeon Workstations Dozens of Huge HP programmable PS's, Freq. Synths, Logic Analyzers Many CRT based LeCroy Scopes, Older Tek analog scopes (I took one of those!), Spectrum Analyzers NI GPIB, Serial, M Series, USRP's Boat loads of stainless steel fasteners, titanium metal stock DEC VAX and PDP11 computer peripherals (unfortunately I was too late to get the PDP 11/70 CPU that was trashed.) Many nice calipers, micrometers, Bausch Stereo Microscopes (I took several home) Hundreds of wire cutters, needle nose pliers, soldering stations, misc tools Miles of silver coated, teflon hookup wire. I was friendly with a maintenance guy so got early Dibbs on stuff. Once the word got out, the other Engineers converged like vultures so management decided to hide it from sight. Now and then my inside man would unlock the store room at night and let me rummage through the stuff

Been there done that with NSV's. For cRIO connectivity I now use the RTI DDS toolkit or the messenger library which are both free and excellent.

Greetings - After much experimentation I have concluded that the standard waveform pulse and transient measurement vi's in LabVIEW are not adaptive enough to handle analysis (High, Low, Tf, Tr and Pulse width) for a generalized pulse that can be rectangular or in some cases triangular with zero pulse width. I am thinking that the solution might be a type of piecewise linear regression. Has anyone accomplished this without making assumptions on the number of linear segments in the waveform? Is there another way to try to model this?

Hello again - Well its been a year so I wonder...have you been able to do any 2019 or 2020 LVRT testing on the messenger libraries yet?

Pretty easy to setup and keep running. If you give me more specifics on your application I could provide more relevant information...

https://www.rti.com/products/benchmarks

Yes I have been using it quite a bit on a roadway monitoring project with 50 cRIO's. I use it to handle all of the cRIO system state and tag data publishing. We are still in the early stages of testing but it seems to be working very well. The LabVIEW version of RTI DDS is a subset of its full capability. RTI has been slowly adding features but it still does not support basic things like events. Judging from the forum posts, the toolkit is largely unknown in the LV community. I think if more people adopted it, it would garner more love and attention by RTI.

It is disheartening for those of us who develop for the cRIO to see NI come out with a cool product like systemlink but in a misguided marketing strategy have totally ignored those of us toughing it out in the trenches trying to develop secure and robust DDS capability for the cRIO. Even basic stuff like cRIO image management and software deployment, which systemlink handles nicely have been bundeled exclusively in the prohibitively expensive package that NI is trying to sell to electrical utilities.

It's not exactly native but the RTI DDS api has been included in the past few LabVIEW releases.