ShaunR

Meh. Had that for years

Is not? Or do you mean is.

1. It is a call parent method. 2. Placing the Call Parent Method (located in the cluster, class & variants palette) will adopt the parents method if the criteria in the aforementioned document is satisfied.

I've resolved the issue. Zlib Library for LabVIEW (BSD-3)

Take a look at the "Align and Subtract" example in the example finder under resampling.

Prepend the packet size to each message in your python script then you can use the following method which is the most efficient Watch out for the endianness of the size bytes. LabVIEW is big endian (or network byte order). Once you do this you can get fancy later by adding timestamps and whatnot, if you want, since you effectively just using a custom packet header.. Next. find out about the Nagle Algorythm settings on the RPi. I think on Windows the default window is 8K bytes but I have no idea for RPi what it is set to. This will limit transmitting to be either sent immediately (if greater than the buffer) or after N millisecs if less. (Again, windows is default to 250ms). Decide if you need to turn it off to achieve what you need. Note that this only affects the server side. You haven't said how you are connecting (wired ethernet or Wifi). Wired ethernet is far superior for high speed acquisition than Wifi. wired ethernet will easilyget you up to 80% of the the bandwidth available - Wifi you'll be lucky to get 50%.

I hate Win 10 just for making me chase tiles around the start menu for 10 minutes trying to get them into menu folders.?

Ask them about BridgeVIEW

Lava serves this purpose well. In fact. my last interaction with openG was here

Of course not. But some of the toolkits haven't been updated for a few years because of the reasons I stated. So it's an example of why the trope about no development activity is untrue. This is why I don't put dates on the public version history. By the way. The idea that development activity is a sign of a "live" project only came about in recent history once people got used to buggy code and alpha releases purporting to be a release proper. I view continuous updates and lots of activity as unstable and therefore unusable code. If one is contemplating using a library or piece of software and think it is less a project risk if there is lots of activity, then, IMO, one has admitted that ones own software will be unstable and bug ridden. I don't exactly know at what point alpha software was accepted as the the norm for final product but it seemed proliferate in the switch to Agile Development.

That's a trope initially perpetuated by marketing people. There is no message. If developers discontinue a product they will [almost] always say so in the notes, comments or website unless they were unexpectedly hit by a bus. I have a similar problem with this perception. Many of my toolkits are feature complete at initial release. There is usually a period of bug fixes shortly after release and then no updates because there are no new features and no reported bugs.

No library is dead whilst at least one person is using it.

I a similar vein. The toolkit gives new starters a lot of examples on how to use prototypes in LabVIEW - in small, easily digestible chunks IMO it has enormous value as a teaching resource and as an exemplar of coding style.

Yeah. I can't claim that one. It was originally a criticism of OOP

I don't think it's just you. For my part. I work with companies that require approved suppliers so using any third party software is an admin nightmare. Because of that and the length of my whispy white beard, I have accrued my own software which is unencumbered by other licences and can be used by the aforementioned companies because I am approved. Certainly there are some features that have been added to LabVIEW when before only openG had those features (getting type def info and auto indexing array springs to mind) and Rolfs zip package is much, much faster than NIs. But a lot of the functionality was just replication of NIs (like most of the string functions). There were a few gems in there like the inifile being able to write anything (but I think MGI toolkit outpaced that and besides, I moved to SQLite a while ago now). And, as you mentioned, removing array duplicates and it's ilk. But, like you say, they are not hard to write and the incestuous dependencies means that when you want a banana you get a banana, the gorilla holding the banana, the tree the gorilla sits in and the whole jungle surrounding it. Package that with some BSD 2/3, LGPL, GPL and god knows what else ad nauseum and it makes an otherwise fine package difficult to actually use in anger.

Agreed. But it's the unhandled ones you have to worry about. and the ones that annoy customers the most

It's the nature of the beast. I had something similar today but not quite on the same scale. Every time I tried to build a zip archive with the option "Recurse Directories" .. it didn't. So I went through the code checking paths and and found it was because the boolean wasn't being set for some reason. So having gone down the hierarchy checking hte file paths I then went back up checking the boolean only to find that the control on the front panel wasn't wired to the unzip sub vi for that option. Now you might say DUH! But in my defence, it wasn't obvious because two boolean controls where vertically compressed and the wire of boolean control above (which was a function to be worked on next and therefore expected to be unwired) went underneath the "Recurse Directories" and came out looking like it's wire.. So if I had tried the other option (Include Empty Dirs) it would have recursed and I would have known immediately rather than 20 minutes later .

Thanks Michael. Things seem to be much improved.

I often wondered about the legality of that. Technically, you need never buy a copy of LabVIEW if you just use a VM and are happy with the trial logo permeating the front panel. M$ have particular rules about VMs (and Apple actively prohibit their OS on them) but NI have never (to my knowledge) explained their stance on them.

As per usual, I'm n outlier here. I hardly ever disable Automatic Error Handling and prefer to use Clear Error.vi where necessary (although I have my own Clear Error.vi which is re-entrant rather than the native on which is not). My reasoning is thus. It demonstrates that the error condition has been considered and a specific decision has been made to ignore it. Automated test harnesses reveal uncaught errors (by never completeing) wheras they may pass if AEH is turned off. I'd rather an error dialogue pop up on a customer machine which at least gives me some iinformation of where to look if an unconsidered error occured rather than them saying "I press this button and it doesn't work". Turning it off is is a code-smell for "cowboy coder"

In a pinch, you can download the trial of the latest version and use that to back-save. It's not a permanent solution as the trial period is something like 7 days. Most developers subscribe to the NI SSP (Service and support package) and get yearly updates of the latest version but that doesn't mean there are no "issues" and the only workable solution is if everyone, in the entire company, is on the same version and upgrade at the same time.

This is one of the reasons I still use 2009 (apart from performance and robustness ). The only viable option is to program in the minimum LabVIEW version you intend to support. It's one of the main issues with cooperative, group development and requires a strict regime of everyone sunchronizing versions in repositories. It can be done with different versions by back saving, but it usually ends in tears. Backward compatibilty in LabVIEW is exceptional. Forward compatibility requires a crystal ball and unicorn droppings.

You're not liable, though. JKI is. That is my point. You gonna sue?

Have they? The zlib library isn't GPL or LGPL and the Vis are BSD. I assume that Rolf is intending to make an intermediary library to be LGPL and that means compliance with, now, 3 licences - the most onorus being LGPL. That's not my vision and would argue that it would be no better than under vi.lib. I think we both see the value of install but for uninstall you don't want to touch the target packages - just delete or recreate the links.

Practically speaking. If you delete a hard-link, you delete the target. If you delete a soft-link, you only delete the link. There's a little more to it than that, but not much. Windows file APIs are link-aware. The in-built LabVIEW ones are not.