ShaunR

Any 3 values between 1 and 9 in any order.?

I think SQLite is shipped with the Linux RT. There is a how-to-update thread over on the dark-side at any rate.

The VI "UNIXPathStringToPath" is an unused placeholder on windows. It is replaced with a platform specific implementation when loaded on Mac.

I see no problems. Only a solution to the question asked and the beginning of other solutions

Control Refnums don't really work like that. It is a container that assumes the type of the contents a bit like ,NET and ActiveX containers rather than LabVIEW objects, per se. So you have to do something like this. You will notice that by inserting the control into the reference; the reference now assumes the [type] name of the control. ChangeRefnumClass Folder.zip

There are two VIs in "vi.lib\Advanced String\" Path To Command Line String.vi Command Line String To Path.vi These take in to account the platform separator when converting to and from strings and paths. Use those instead of the palette primitives.

Yes. I tried posting a link to the wikipedia page but the editor kept truncating the address. hopefully this works for you. You are after the TCP_NODELAY option of SocketImpl (set to true)

Just turning Nagle off would be good enough for a quiz buzzer, wouldn't it?

I don't see any issues with the algo at first glance. You did say it used bit reverse (the two other functions) and I don't see you doing that, however.

Is this really a box you want to open? You can't inherit from multiple parents and the Character Lineator is designed for this.

The easiest way by far is to use the [un]Flatten to XML primitives, which can take objects and variants as arguments, and convert the XML to/from JSON. with simple regex/search/replace. Why they didn't make the native JSON ones like the XML is beyond me

If you can't give me some numbers I can put straight into LabVIEW, I'm not going to even try. You also haven't told us what the polynomial is so we don't know which flavour of CRC it actually is. Google should have told you that the code is 3/5ths of "this one" Once you know which flavour just put LabVIEW in front of your search term (e.g. LabVIEW CRC16 xmodem) and you will find plenty of pre-written VIs like "The Inline CRC Reference Library",

Is there a CAR or some document detailing the findings?

My oldest software that hasn't become "vapourware" seems to be the "windows_api_1.0.llb".It was written in LabVIEW 5 in the late 1990s but think I had it internally for a couple of years before I released it. It is posted in the CR after someone asked for it and is identical to the original except it was recompiled for 2009 and later so people could actually use it. Here is the original in LabVIEW 5. I can't actually open it any more but I'm pretty sure it is identical to the CR one. windows_api_1.0.llb

I doubt if you are willing to elaborate on that. I expect it was an obtuse, back-handed, compliment. Programmers that advocate "Ad-hoc reuse" are cut from the same cloth as those that say they are green minded, concerned for the environment and recycle just because they reuse their shopping bags as bin(trash) liners.

It's starting to sound very much like you have a race condition or two somewhere. Extra messages could be due to retries but could also be due to reading the same value twice (especially happens with notifiers). So you are losing messages sometimes and gaining messages sometimes. All seemingly randomly tied to arbitrary and unconnected system conditions. That is a code smell I am very familiar with.

"Data mining" just isn't a phrase I use for programming at all. I don't see software as data - more a tool for manipulating data. I wouldn't say I "data mine" a laptop to recover components and I see software the same. So whilst I could write software to "data mine" I would never think to use it as a phrase for code reuse. No and no and no and no. Not only are you hell bent on the tortured use of "reuse" but now you want to torture "reference" as well. Just stop it "Ad-hoc reuse" is a phrase made up by script kiddies because they can't write proper code at all and have to steal others'. It isn't a thing..

Well. don't keep us in suspense. Where's the rest of it? Components, yes but........ I know that was probably a throw away statement but it's something that annoys me and I see/hear newbies and oldies parroting without thinking. If you meant by "data mining" the process of taking an unmodified chunk of an old project and use it "by reference", i,e, place the VIs on diagrams or link via code interface nodes then yes, it is reuse [of an informal library]. You just haven't reused it enough to make it formal. However. Copying and pasting or copying and modifying (forking) of an old project/code isn't reuse - it's replication. It is just a tortured interpretation of the English word to make an anti-pattern sound like a good thing when making a reuse library is too much effort or its reuse would be too limited. "Your Honour! I just copied the dollar bill onto another piece of paper. I was simply reusing it " I now use the term "reuse-by-reference" to explicitly exclude these abominations from the definition. If you are "data mining" by copying code then it is an opportunity to define a reuse-by-reference subsystem/library but is not, in and of itself, reuse.

Rolf's given you the technical reasons and history. So ignoring cross-platform (big one for me, especially as I'm now moving away from Windows) , performance and falling to pieces when IT push out a security updates. Here are some real world, LabVIEW specific examples. Thread Starvation Obsolecence. Deadlocks.(see note at bottom) Like Rolf says. When they work-fine. When they don't; they are self contained bundles of nightmares that you can only remove (if you can get into the IDE ). I just prefer not to put them in in the first place.

Memory [re]allocations in diagrams are expensive and Boolean operator performance is trivial in comparison?. If you have to worry about a few nanoseconds of fundamental operations, then a general purpose desktop is not the platform to use?

I think you should. This thread prompted me to hunt around to see if I could find a Eurotherm Controls serial driver (Modbus and EI-Bisynch) that I wrote thousands of years ago It was the first driver I ever wrote and was my first public submission to the world. I think I even submitted it to the NI drivers library but it's not there now - there is a newer one there now without the EI-Bysinch. I guess it was my first vapourware :

​That's really sad. It probably means that it wasn't modular enough to be re-purposed or adapt to changing requirements. I expect your software has come a long way since then. I think it's lying that reuse is 98% though I must admit I don't use the Gateway thing. It may have changed since I last used it, some 5 years ago but it was more of a trace-ability function which isn't all that helpful for day-to-day programming and customers are only really interested in acceptance tests. As in internal tool I can see it might have benefits, but it doesn't provide what I need on a say-to-day basis. Like your tool, I have software that does the bits of it that are interesting such as coverage but I don't care about complexity or pretty graphs or a myriad of other metrics that are just numbers to "ooh" and "ahh" over. I care about broken VIs, orphans, re-entrant or not etc that affect the performance and operation rather than the accountancy.. Complexity or nesting depth is a poor indication of that. However, the tool that I've had for several years now is plug-able and extensible so it hasn't suffered the same fate even though it started out as pretty much the same sort of tool. In fact, 6 months ago it had a face-lift from the standard millennial white, system front, panel to a moody dark which is all the rage now ​ ​

Eliminate that and see if it goes away (simulate the data if you have to). There is a very good reason why ,NET (and it's grandpapy, ActiveX) is banned from all my LabVIEW projects and this stinks of ,NET threading and LabVIEW root loop.

Actually there are company overheads. your mortgage, car payments, medical insurance, food and so on. These are taken into account (I hope) when you decide on your hourly rate. If this is your first foray into contracting, I highly recommend quoting on a time and expenses basis and providing a preliminary project plan with deliverables and milestones for them to sign off. Fixed price quoting is very dangerous for the inexperienced. If you are fixed price quoting then your "profit" is on the hardware and services as a value added supplier (usually 5-10% of cost), and your hourly rate which you make up based on how much you think you need to live your lifestyle and how much the market can bear. There is no overall "project profit percentage". When you negotiate, you negotiate less time and less hardware provisioning until you and the customer agree to the minimum effort and hardware supplies (from you) required to do the task. If that is still not good enough then your extra "margin" is on the hardware so you can go from, say, 10% to 5% If that is still not good enough - walk away because you aren't making any money!

​ ​Yes - fundamentally impossible from your perspective LabVIEW (or more specifically, G) isn't an interpreted language like Javascript or Python and it can evaluate the components of your expression in parallel, unlike procedural languages. So "b OR c" might be evaluated 10 hrs before "a" since an expression, or a component of an expression, is evaluated when the data is available, not when a program pointer steps to the next line.- that's dataflow for you ​