JKSH

4 hours ago, X___ said:

I've got to ask: what is the second oldest?

Your last Wikipedia link has a link to the answer(s) 😁 https://en.wikipedia.org/wiki/World's_second_oldest_profession

You mentioned a number of different permissive licenses; Shaun and Rolf also mentioned copyleft licenses.

Here is a simplistic ranking of the "forcefulness" of different open-source licenses, from most copyleft (#1) to most permissive (#5):

1. GPL
2. LGPL
3. MPL 2.0
4. MIT/BSD-3/Apache 2.0
5. BSD-0/Unlicense (virtually Public Domain)

On 6/24/2022 at 11:00 PM, Heiso said:

Most of which basically say if you're selecting from among the most permissive ones it's all personal choice.

That's a fair statement.

I agree with Rolf: In terms of the common permissive licenses, MIT, BSD-3, and Apache 2.0 are very very similar in intent. Your project will probably end up in the same place no matter which of these 3 you pick (unless you or your project become super famous, as you said). Apache 2.0 is considered more complicated that the others though.

BSD-0 and Unlicense are even more permissive; they are virtually at the level of public domain.

On 6/24/2022 at 11:00 PM, Heiso said:

The non-promotion part in the BSD-3 appeals to me

Apache 2.0 has a similar clause.

On 6/24/2022 at 11:16 PM, ShaunR said:

Any strong copy left licence.

How strong is strong for you?

• GPL is the ultimate copyleft license: all software that uses a GPL library must also be published under GPL.
• You can release your software under any license you want if it only uses LGPL libraries, but you must still allow your users to swap out the LGPL'ed part for a different version. This makes it difficult to use a LabVIEW library under LGPL, because it's not trivial to write a LabVIEW application that lets users replace certain VIs.
• MPL 2.0 is a middle ground between LGPL and MIT. And it is easy for LabVIEW devs to use MPL 2.0 libraries.

15 minutes ago, Rolf Kalbermatter said:

The ones that clearly stand apart from these are the GPL and LGPL licenses which, while open source too, try to force any user of it (to some smaller degree with the LGPL) to open source their entire code too.

The difference exists because GPL is primarily concerned about freedoms for the end-users, while the permissive licenses are more about making developers' lives easier.

LGPL does not require you to open-source your code at all.

11 hours ago, Jordan Kuehn said:

At risk of derailing this thread,

Perhaps a mod/admin can fork this thread? (The last several posts have been about SystemLink authentication)

11 hours ago, Jordan Kuehn said:

where is the documentation for these methods? I'm aware of local windows users and LDAP. Further, you do rightly point out the difference between systemlink and webvis. My conflation is due to wanting to utilize systemlink *and* webvis to serve data and dashboards to customers utilizing the same authentication method.

My apologies, I just realized that I was conflating SystemLink and NI Web Server myself.

As far as I know, NI Web Server -- which can also be used for LabVIEW-based web services without SystemLink -- uses LDAP + Local Windows accounts like you said, plus Microsoft Active Directory only: https://www.ni.com/docs/en-US/bundle/ni-web-server-18.2-20.1-feature/page/choosing-an-authentication-setting.html "Regular" SystemLink hooks into the NI Web Server for authentication.

SystemLink Enterprise (the one announced at NIWeek 2022, not the older releases which were also touted as enterprise-level) uses completely different technologies, from what I gather from the presentations. I haven't been able to find any documentation for SystemLink Enterprise yet.

12 hours ago, Jordan Kuehn said:

As noted above the workspaces have issues with filtering properly using the system filter. I am only aware of workspaces as the ability to segment out accessibility of systems to users and even then I may want to limit data views via certain dates (system is on rent with different customers at different times), but that is another can of worms.

I don't know of a solution for this either; we'll have to see if SystemLink Enterprise offers anything. Try asking at https://forums.ni.com/t5/SystemLink/bd-p/1020

26 minutes ago, Jordan Kuehn said:

Which is partially why I haven't implemented the method in the video I linked.

To be clear: That NIWeek 2019 video doesn't contain any SystemLink at all.

SystemLink asks us to use its integrated 3rd-party user management tools, not to implement our own. In other words, SystemLink doesn't want us to follow that video!

I agree (and NI agrees) with y'all that we should not be rolling our own user management system. (This applies to all software, no matter what price it is)

On 6/8/2022 at 4:02 PM, Mads said:

Has there been any movement in such a direction (Enterprise?), or would you still need to have separate system link servers to ensure restricted access / user specific content?

That would be a good question for https://forums.ni.com/t5/SystemLink/bd-p/1020 -- The NI Engineers have been reasonably engaged/accessible there.

• SystemLink 2020 R2 introduced the concept of "Workspaces" in SystemLink Server Advanced: https://forums.ni.com/t5/SystemLink/Announcing-SystemLink-2020-R2-SystemLink-Enterprise/m-p/4074358#M1478 but I don't know how fine-grained the control is.
• The new SystemLink Enterprise for 2022 (see Jordan's first post from Friday: https://lavag.org/topic/22548-interesting-announcements-from-ni-connect/?do=findComment&comment=140832 ) should give much better control, assuming NI integrates the components well.

Note: Advanced != Enterprise

18 hours ago, Mads said:

The presentation seems to show that we need to implement custom user account handling...(helpful in that regard, although just browsing quickly through the video it does not seem to be a particularly secure method - sending user names and passwords(perhaps I overlooked an underlying encryption?).

The 2019 presentation only shows WebVIs' ability to interact with generic web services. It does not show any SystemLink capabilities.

Even if there is underlying encryption, storing passwords as plain text in a database is extremely bad practice.

18 hours ago, Mads said:

What we were hoping for... was that that the user account administration and logon was handled securely by SystemLink itself

I wouldn't want this.

User management is difficult to develop, maintain, and keep secure. It would be unwise for NI to roll their own manager; they should integrate existing, tried-and-true technologies.

Currently, non-Enterprise SystemLink does use LDAP and Windows Active Directory for user management, which is good. I haven't looked closely at what new technologies are available under Enterprise (Jordan mentioned OAuth?)

17 hours ago, Jordan Kuehn said:

we were hoping for.... that the selection of dashboards and/or what data those had access to would then depend on the user account (then only the last part might require the G-code to know anything about the user).

If I'm not mistaken, we used to be able to specify permissions for specific Groups of users, and a WebVI could query what permissions are available to the the current logged in user.

However, NI changed the permissions management system significantly in SystemLink 19.6 which broke this, and I don't think it was ever fixed: https://forums.ni.com/t5/SystemLink/Query-SystemLink-Account-Privileges-from-a-Custom-WebVI/td-p/4103386

7 hours ago, Rolf Kalbermatter said:

It could have been done even without the VIs having been set to use separate compiled code. In the worst case the VIs would have been compiled the first time you open a project that uses them. So what?

Inconvenient? I don't think so, at least not nearly as much as having to always chase the right drivers.

Try to develop a distributed SystemLink project where you have both both desktop and real-time targets. Every time you switch targets, you need to wait for all the ~100s of VIs to be recompiled.

1 hour ago, dadreamer said:

https://www.gnu.org/licenses/gpl-3.0.html

Actually, your earlier screenshot shows https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html (or, if you prefer reading something shorter: https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1))

If I recall correctly though, other parts of OpenG are available under the BSD-3 license: https://opensource.org/licenses/BSD-3-Clause

14 hours ago, LogMAN said:

Don't tell him about Excel...

Nothing wrong with Excel! https://interestingengineering.com/80-year-old-japanese-man-uses-excel-to-create-dazzling-paintings

12 hours ago, jake42 said:

I suspect it's as much or more that people arent happy with NI's serious degradation in customer service. In other words, because it's not NI. 

I think it's very unfortunate because I've found LV (and NI) in the past to be an excellent solution.   I'm at the end of my career (30+ years) and mostly just consulting these days.  Meaning I don't have to deal with NI directly very often.  But when I do it becomes apparent why I hear almost constant criticism from my clients, friends, peers.

I don't have an answer for your activation issue, but you're not alone:

• https://lavag.org/topic/22358-nis-new-software-subscription-model/
• https://forums.ni.com/t5/LabVIEW/LabVIEW-subscription-model-for-2022/td-p/4204448

10 hours ago, hooovahh said:

Now that I look at these I think the original page you linked to at Farnell is incorrect.  I think that is a normal RT non-Linux variant license and the page is wrong based on the product number they listed.

3 hours ago, Rolf Kalbermatter said:

I'm pretty sure it is really the Pharlap ETS license and the information on the Farnell site seems therefore bogus. Considering that NI discontinued support of Pharlap ETS for all options already in the latest LabVIEW version, it's amazing that you still can buy it.

That's rather worrying then, given that Farnell is now an "Authorized Distributor" for NI.

6 hours ago, Rolf Kalbermatter said:

So until NI decides to sell an actual NI Linux realtime runtime license

Ain't this it? https://uk.farnell.com/ni/777849-35/labview-real-time-deployment-license/dp/3701592

6 hours ago, infinitenothing said:

It's all headless RT code targeting a ZYNQ [sb,c]RIO.... If I can get the run time engine working then I'll just keep everything as LabVIEW.

NI Linux RT is just another Linux distro. If you can install Linux on your device, you can probably install NI Linux RT which comes with the LabVIEW runtime. I'm not sure what the licensing implications are. You probably won't get NI hardware driver support, however.

The Zynq FPGA is a completely different beast.

6 hours ago, infinitenothing said:

Speaking of data flow, do you think some languages are better targets than others?

The only other widespread dataflow language in industry (that I know of) is Simulink, so...

The best language is one that you are experienced and competent in. The next best language is one that you have resources and drive to learn.

4 hours ago, Arthur Lima said:

I've used a similar system before and after some adjustment to Rate and Samples to Read managed to get it stable but this time I have not been able to.

Some hardware has a minimal sample rate. Double-check that the "SampClk.Rate" property does return exactly 250 Hz -- If it's actually higher, then you'll never empty your buffer and it just keeps growing.

4 hours ago, Arthur Lima said:

I've managed to narrow it down to the issue happening when I'm attempting to save the data into a file (using the Write to Measurement File VI) so I've moved to trying to use the save TDMS functionality but could use some assistance in trying to improve my VI to be more reliable

Use a producer-consumer architecture (example: https://forums.ni.com/t5/Example-Code/DAQmx-Encoder-Measurement-with-Producer-Consumer-Architecture/ta-p/3493445) Your DAQmx while-loops should be dedicated to calling DAQmx Read.vi only. The data should be sent to a different loop (via a queue or a Channel Wire) for writing.

Beware: Since you are writing waveforms but you discard some data chunks, your file timestamps will be wrong.

4 hours ago, Arthur Lima said:

and be able to save data to a single file

When you send your waveform to the data writing loop, send the relevant TDMS Group Name too.

5 hours ago, Phillip Brooks said:

I tried a few years ago to participate on Stackoverflow re: LabVIEW questions, but there was little or no ability to include graphics/images. Whenever I did (using off-site links etc...)

They do provide a built-in image uploader, which we're expected to use instead of off-site links:

I had no problems like this: https://stackoverflow.com/questions/36852665/adding-delay-in-data-acquisition-in-labview/36857051#36857051

4 hours ago, Tim_S said:

I was looking at UEI products many years ago, but never had a project could use them on. At the time the PCI cards were very similar specs to NI at less cost, but the front end didn't appear to be as robust. They also had a 'cube' product where it was stackable boards on a base module; it looked interesting, but again didn't have a project that it would work on.

Got a sister division that uses Beckoff remote I/O. The sampling rates would be slower. Recall the prices were pretty good for remote I/O systems when tried to get a feel for the product.

I don't have experience with Beckhoff products, but a customer asked us to integrate a UEI Cube a few years ago. I remember thinking that their API was a bit more convoluted than DAQmx.

This customer got non-rugged accessories so they struggled a bit to get good shielding, but I have seen MIL-STD compliant hardware in UEI's product line.

6 hours ago, X___ said:

"The number of 176 day reamaining, it is the time you have until your  active license expire, I can assure you that version 2021 SP1 will continue to work after the license expires."

...

So the so-called "perpetual" license expires...but the software still works afterwards.

That is... different from my experience.

I had an old installation of LV2017 which has no expiry. When I added the LabVIEW Real-Time Module 2017 to it in April 2020, it was given an expiry date of August 2020. When August 2020 came, I had to re-activate LabVIEW Real-Time Module 2017 (but not LabVIEW 2017). And this repeated itself in August 2021.

My employer had been using the old NI Developer Suite for over a decade and this still kicked in -- we never had expiry dates before.

19 minutes ago, X___ said:

Older versions do not show anything in the "expiration" date column.

This is unrelated to the LabVIEW version, and unrelated to perpetual vs. subscription licenses.

In recent years, NI's license servers have changed things such that all activations are only valid until the next August -- Even perpetual licenses must now be re-activated annually. So if you install and activate those same older versions on a different PC today, they too will expire in August 2022.

22 hours ago, AutoMeasure said:

Have any of you tried using NI's G Web Development Software as a UI for Python? I know that NI charges for the package, but that could be OK for most industry work. Is it practical to implement and responsive to interaction? I see on NI's website that they recommend the SystemLink API for bidirectional data communication between the WebVI and the Python program.

I used the Web module with SystemLink, but not with Python. It is somewhat (not very) responsive; there is a lot of room for improvement. See the 2022 posts at

22 hours ago, AutoMeasure said:

Have any of you tried calling NI-DAQmx from Python for continuous data acquisition? Does it work?

Not personally, but NI does have official DAQmx Python API. It should work: https://nidaqmx-python.readthedocs.io/en/latest/

20 hours ago, bjustice said:

I've used the G Web Development Module (fairly heavily) once for a project....  Worked out quite well.

The most alarming aspect of the G Web Development module seemed to be the lack of a user-base.  I struggled to find any examples online excluding NI's own examples.  The darkside forum felt like a ghost town when I asked for help with a problem.  Even now, looking online, I don't see any published roadmap or planned features for the G Web Development.  It's kinda sad.  I really liked working with what existed.

I used the NXG 5.0 Web Module (direct precursor to the G Web Development module) for a large SystemLink-hosted project.

The biggest issue for me is missing functionality. Despite SystemLink touting Tags + Messages + Files as the 3 pillars of data transfer, NI did not provide a Web Module API for downloading/uploading files from/to a SystemLink server. I thought... "That's OK, I'll just use the raw HTTP API instead". And then I found out that the HTTP API itself was unfinished. NI provides a WebVI for making a HTTP Multipart request (which is required for uploading files), but if you open up that VI it simply spits out an error constant that says, "feature not implemented". So I had to implement it in JavaScript in the end.

The next headache is the rigid UI. It is near impossible to get the UI to even resize with the browser window; the result feels rather unprofessional next to non-NI web UIs.

The Web Module is fine for making very basic, static dashboards. But if you want to do anything complex/interactive/dynamic, you'll need to delve into HTML + CSS + JavaScript.

26 minutes ago, Rolf Kalbermatter said:

While technically related it is bordering spam based on the repeated marketing style postings.

It's more than "bordering spam"; it's a common tactic used by spammers in forums across the Internet: One account posts a link and another extols its virtues while speaking as if they are a 3rd party.

33 minutes ago, r_good said:

I had to abandon VMW as I'm using WSL as well and Windows Hyper-V isn't playing well with others anymore...

VMware 15.5.5 and newer can run alongside Hyper-V: https://blogs.vmware.com/workstation/2020/05/vmware-workstation-now-supports-hyper-v-mode.html

On 1/2/2022 at 12:11 AM, ShaunR said:

undetectable by visual inspection of the source code. It isn't a programmers application with a bug - you can't trust the source code is doing what you think it is doing.

Perfectly doable in LabVIEW too!

2 hours ago, Gribo said:

There was a page full of evil VIs that played tricks on the poor programmer trying to read them, I don't remember where I saw it.

Not the example you were thinking of, but this one was hilarious: https://forums.ni.com/t5/LabVIEW/Compiler-is-Too-Smart-for-My-Own-Good/td-p/4188524

46 minutes ago, Heiso said:

Assuming this fixes it, if I can't use the Set Time.vi to set the system clock, how can I synchronize multiple systems that are geographically isolated and have no common network timing source (e.g., NTP, PTP, etc.)? GPS is something that's readily available so I'd like to use that, but not if it's going to cause lockups days after I call the function a single time... Again, this is all predicated on disabling GPS fixing the issue.

I'm pretty sure remote time syncing ("remote" as in "light-years from civilization") is a core use-case.

Try asking at the Linux RT forums. Relevant NI engineers are quite active there: https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/bd-p/7111

On 11/30/2021 at 12:06 PM, Mahbod Morshedi said:

Unfortunately, having a tutor is out of the question, no low-level programmers at the research school of chemistry.

Does your institution have a school of computer science, software engineering, or similar? If you are allowed to, perhaps you could sit in on some of their introductory lectures.