ShaunR

You are running it in the root loop (Orange Node), rather than run in any thread. right?

I was actually working in 2013 at the time but have just checked 2018 and it is indeed in there. So it was obviously added after 2013.

I know. You obviously didn't get the dig at a keyboard warrior vs a mouse clicky, coffee in hand, reclined on the sofa, coder layabout like me

Quick drop? What's that?

IC. I'll have a play around with the XML now that you have shown me how to do it (many thanks). Maybe I'm just being a bit OCD about it but once/if it's done, I won't have to revisit it anytime soon.

Many thanks. I thought that might be an issue. I can move it around using a property node (if I scan the FP objects to get a reference). Like you said. You can't select it (not that you can with the vanilla splitter either) which means you can't create property nodes either so scripting would be the only way of doing anything. Is it possible to make it 1px in edit and 0 in run modes? I've no idea how these controls are put together but xcontrols can be different in run or edit.

Yes. If you can get rid of the gaps created by the splitter and array border (marked in red on the second image), that'd be great.

The picture control is just what I'm looking for (thanks Hooovahh). that eliminates the gap between elements The array border and the splitter wouldmake it perfect

I'd be interested in a 1px border array and/or picture control if you're hacking them. The element separation on an array control is huge and annoying. Oooh. And a 0px separator or can make it transparent

Yeah mine were a little more obvious that an xcontrol was really the only elegant half-way decent solution. One was a string control with markup and the other was a tab control that works like the native one should. So it was really about encapsulation.

If that scares you then I don't give you good odds on "fixing" the LabVIEW source when it's released I've just written two XControls. (First time in about 6 years). They seem to be ok but some of the ways they work can be a bit unintuitive.

Surely it would have been easier to just add the CRC check in the openG.

Nope.

When you edit a palette set, there is an option of "Place VI Contents" when right clicking on a VI, which will drop the code contained in the VI rather than the VI itself (like a template). Maybe it has something to do with that.

Well. You could make an XControl.

That only tells you if the bytestream has been modified in transit rather than if there is a corruption in the archive itself.

Well. Rold is particularly thorough, so In the interim. If it's windows only, you could try Zlib Library for LabVIEW 1.1.0 It has a compatible VI with the native LabVIEW but I didn't notice the conpane for the OpenG ones. I'd be interseted if it passed your tests too.

Actors? (AKA Throwing lots of cats in the air then trying to herd them.)

If you've ever started up Wireshark, you'll see occasional TCP retransmits due to differnet factors - especially under load and especially with Wifi.. These don't get retransmitted with UDP. It sounds like most of your losses was were due to packet collisions.

I don't see a check in there at all. It's not much of a change in the bowels of the LabVIEW code, but does require a new CLFN to call the CRC which fortunately does exist in the DLL.

Itseems to me that that this is an extremely poor cure of the symptom rather than addressing problem. If it ever gets deployed somewhere other than your particular network, with your particular data needs; it will undoubtably run into problems. RUDP is an application overlay. So you would need to code it yourself (from the spec I linked to). I don't know of any LabVIEW implementations but there are quite a few similar ones (RTP?) since UDP is used all the time with VOIP and video streaming.

ARP is part of address discovery. It links MAC addresses to IP addresses. Yes you do need it. Ditto gleichman or implementing something like RUDP at the application level.

I don't care what version of .NET is required. All .NET is banned from my projects and some of my hair has grown back as a result I too have products in 2013 and have found it relatively stable. It was my next choice if I were to be dragged kicking and screaming from 2009 Anyone else prefer an earlier version than 2013?

What should the source code minimum version be? By that I mean the source code of the package manager itself, as it would ideally be open source. Obviously 2009 is my preference but that requires 3rd party toolkits for HTTP and HTTPS; which is not really tenable for most people. Later versions are plagued by stability and performance issues so I guess what I'm asking is what is the minimum stable version of LabVIEW that should be supported based on prevalence.

I know you are looking for the most precise method for this type of waveform, but is there a reason you can't do a peak detect to remove the lead-in?