ShaunR

Yes. The path isn't passed through but I figured out what it was supposed to be. this is the one in my installation: It's a trivial change though. The important part is the adding the extra case and your new VI. I was about to go all Neanderthal on the "Write Linker Info" before you posted the proper solution.

Sweet. It's not quite the same but I'll figure the rest out. You've done the hard part Thanks.

There is a "Copy Resource Files and Relink" in "<program files>\JKI\VI Package Manager\support\ogb_2009.llb" and "<program files>\JKI\VI Package Manager\support\ogb_2017.llb". Is it "Write Linker Info from File__ogb.vi" that you have modified? I'll have to have a closer look.

Can the JKI builder be modified to do this? I've already hacked some of their VI's in ogb_2009.llb so it didn't take 6 hrs to build. It's a huge problem for me when building. I have a solution that sort of works, sometimes, but not a full proper solution. Can you detail your process?

Welcome back. Retirement not all it was cracked up to be? My only comment about this (because I still use LV 2009-best version ever) is that generally: Never do it in the middle of a project. Upgrading LabVIEW is a huge project risk. Don't upgrade if the software already works and you are adding to it (only use it on new projects). Only upgrade if everyone else in your team upgrades at the same time. Upgrade if there are specific features you cannot do without. Upgrade if it will greatly reduce the time to delivery (unlikely but it has been known). Upgrade if there is a project stopping bug that is addressed in the upgrade you are considering. Remember that you can have multiple versions on the same machine. You don't need (and should never) go and recompile all your old projects.

Nobody has met me, right? I might be A.I. without the I

Ask it how I can get past the sign-up CAPTCHA to use it?

You want EVP_PKEY_verify.

I have the binaries as arrays of bytes in the Post Install. I convince VIPM to not include the binary dependency and then write out the binary from the Post Install. You can check in the Post install which bitness has invoked it to write out the correct bitness binary. Not sure if that would work on Linux though.

Installing both binaries huh? Don't blame you. It takes me forever to get VIPM to not include a binary dependency so I can place the correct bitness at install time with the Post Install (64bit and 32bit have the same name. lol)

The longer it is unresolved, the less likely users will bother to return. I used to check the forums every day. Now it is every couple of weeks. Soon it will be never. Some might see that as a bonus

The objection is that I (as a user) do not have end-to-end encryption (as advertised by the "https" prefix) and there is no guarantee that all encryption is not stripped, logged and analysed before going on to the final server. But that's not just a single server, it's all servers behind Cloudlfare, so it would make data mining correlation particularly useful to adversaries. Therefore I refuse to use any site that sits behind Cloudflare and my Browsers are configured in such a way that makes it very hard to access them so that I know when a site uses it. If I need the NI site (to download the latest LabVIEW version for example) then I have to boot up a VM configured with a proxy to do so. I refuse to use the NI site and the sole reason is Cloudflare. So now you know how you can get rid of me from Lavag.org - put it behind Cloudlfare

Any site that uses Cloudflare is completely safe from me using it. As far as I'm concerned it is a MitM attack.

Not exactly a software solution though. I wrote a plugin for my CMS that uses Project Honeypot so it's not that difficult and this is supposed to be a software forum, right? The problem in this case, however, seems to be that it's an exploit-it needs a patch. Demoting highly qualified (and expensive) software engineers to data entry clerks sounds to me like an accountants argument (leverage free resource). I'd rather the free resource was leveraged to fix the software or we (the forum users) pay for the fix. The sheer hutzpah of NI to make you a no-cost employee to clear up their spam is, to me, astounding. What's even more incomprehensible is that they have also convinced you it's a privilege

Port 139 is used by NetBIOS. The person in the video is using port 8006 which is not used by any other programs.

By now, you really shouldn't have to be deleting them manually. If it's an exploit then it should have been patched already (within 24hrs is usual). If it's just spam bots beating CAPTCHA then maybe we can help with a proper spam plugin (coding challenge?). This is a software engineering forum and if we can't stop bots posting after a week then what kind of software engineers are we? It's also quite clear to me that this is no more than a script kiddie. You can watch the evolution of the posts where originally they had unfilled template fields that, as time went on, became filled.

They are signing up when new registrations are disabled. It looks like an exploit.

I've no experience with Redis. For monitoring/supervision/alerting, you don't need local storage at all. MQTT might be worth looking at for that. Sorry I couldn't be more helpful but looks like a cool project.

My tuppence is that anything is better than Network Shared Variables. My first advice is choose one or two, not a jenga tower of many. What's the use-case here? Is the data real-time (you know what I mean) over the network? Are the devices dependent on data from another device or is the data accumulated for exploitation later? If it's the latter, I would go with SQLite locally (for integrity and reliability) and periodic merges to MySQL [Maria] remotely (for exploitation). Both of those technologies have well established API's in almost all languages.

I can't even find threads I posted in last week. It's a skill, to be sure.

These are for shared libraries.

Because I can immediately test the correctness of any of those VI's by pressing run and viewing the indicators. Nope. That's just a generalisation based on your specific workflow. If you have a bug, you may not know what VI it resides in and bugs can be introduced retrospectively because of changes in scope. Bugs can arise at any time when changes are made and not just in the VI you changed. If you are not using blackbox testing and relying on unit tests, your software definitely has bugs in it and your customers will find them before you do. Again. That's just your specific workflow. The idea of having "debugging sessions" is an anathema to me. I make a change, run it, make a change, run it. That's my workflow - inline testing while coding along with unit testing at the cycle end. The goal is to have zero failures in unit testing or, put it another way, unit and blackbox testing is the customer! Unlike most of the text languages; we have just-in-time compilation - use it. I can quantitively do that without running unit tests using a front panel. What's your metric for being happy that a VI works well without a front panel? Passes a unit test? It may be in the codebase for 30 years but when debugging I may need to use the suspend (see below) to trace another bug through that and many other VI's. There is a setting on subVI's that allow the FP to suspend the execution of a VI and allow modification of the data and run it over and over again while the rest of the system carries on. This is an invaluable feature which requires a front panel This is simply not true and is a fundamental misunderstanding of how exe's are compiled. Can't wait for the complaint about the LabVIEW garbage collector. We'll agree to disagree.

ECL Version 4.5.0 was released with CoAP support. Next on the hit-list will be QUIC (when it's supported by OpenSSL properly). I'm also thinking of opening up the Socket VI's as a public API so people can create their own custom protocols.

You want a table per channel. If you want to decimate, then use something like (rowid %% %d == 0) where %d is the decimation number of points. The graph display will do bilinear averaging if it's more than the number of pixels it can show so don't bother with that unless you want a specific type of post analysis. Be aware of aliasing though. The above is a section of code from the following example. You are basically doing a variation of it. It selects a range and displays Decimation number of points from that range but range selection is obtained by zooming on the graph rather than a slider. The query update rate is approximately 100ms and it doesn't change much for even a few million data points in the DB. It was a few versions ago but I did do some benchmarking of SQLite. So to give you some idea of what effects performance: