JKSH

There are 2 separate sets of limits: Scale.Maximum/Scale.Minimum and Data Entry Limits.Maximum/Data Entry Limits.Minimum.

The digital display simply shows the value stored in the Slide -- in other words, it shows what you'd see from the Slide's terminal, local variable, or Value property node. The underlying issue is that the Slide's value remains unchanged when you update the Scale limits.

The Scale limits set the visible range on the GUI but they don't set the range of allowable values. To get the behaviour you want, you don't need to use a property node on the digital display but you must:

• Set "Respond to value outside limits" to "Coerce" instead of "Ignore"
• Programmatically update the Data Entry Limits

7 hours ago, Neil Pate said:

The more I think about hooovahh's idea the more I like it.

...

As long as my cRIO can talk to my cloud then it can store its own IP address somewhere in there.

Important: Make sure you sign up for a 4G service that does not use Carrier Grade NAT. If your cRIO is behind CG-NAT, then knowing its public IP won't help you.

• If your service gives you a unique public address, then the public IP address points directly to your modem. In this case, you're good to go with hooovah's method.
• If your service is under CG-NAT, then the public IP address points to your carrier's modem which is outside your control. In this case, hooovah's method won't work.

7 hours ago, Neil Pate said:

Maybe I am thinking about this all wrong and should just embrace the dynamic IP address issue.

Dynamic IP addresses are a fact of life now unless you're willing to pay up, or unless you obtained a static address many years ago and you've never cancelled the service since then.

(Hopefully, IPv6 will solve the problem -- but it's not supported everywhere yet)

8 hours ago, Neil Pate said:

Does anyone have any recommendations for companies that offer this kind of advice as a (paid for) consultancy?

...

Is this how the IoT hubs work? Like azure IoT?

I'll haven't used any of these before so I'll leave this to experienced people.

8 hours ago, Thoric said:

Thoughts anybody? Every actor I've created has typedefs from libraries and toolkits in it. But only these five actors appear to have a problem with incoroprating them. 

My gut feeling says that a Mass Compile could make this problem go away.

32 minutes ago, hooovahh said:

in NIPM the package must be built for a specific version of NXG.  So a package made for version 3.0 can't be installed in version 5.0, until the creator of the package updates it and rebuilds it for version 5.0.  For reuse to be more adopted in NXG, this limitation needs to be removed.

There's an Idea Exchange entry about this for LabVIEW CG, but it really should extend to NXG too: https://forums.ni.com/t5/NI-Package-Management-Idea/Install-the-same-package-to-multiple-versions-of-LabVIEW/idi-p/3965419

7 hours ago, Neil Pate said:

I don't really want to hand edit 700 VIs. As I said, if I do release it I really don't mind what others do to it. Sorry my question was a bit vague, I actually wanted to ask if I *have to* put a license on every VI. I would be more than happy just putting the "do whatever you want" license (probably MIT License) on the GitHub page if that was sufficient for me to not get sued if someone's heart lung machine stops working due my code.

If I'm not mistaken, this is a gray area because no court or judge has ever contemplated this question before.

The general broad understanding is "No, it's not a strict requirement, but there are reasons to do so": https://softwareengineering.stackexchange.com/questions/125836/do-you-have-to-include-a-license-notice-with-every-source-file

11 hours ago, Neil Pate said:

I use a commerical third party toolkit for the TensorFlow stuff, and so without a license nobody else would be able to run any of the object detection stuff.

That's OK. It's a bit like the Ur-Quan Masters project -- The code is open-source, but not everyone can play it with the non-open-source 3DO assets unless they already own a copy: https://wiki.uqm.stack.nl/The_Ur-Quan_Masters_Technical_FAQ#How_do_I_use_the_3DO_intro_and_victory_movies_in_the_game.3F

Anyway, by making your part open-source, you already make it much easier for others to achieve the object detection stuff!

6 hours ago, Mefistotelis said:

And if you completely don't care about license and want to mock it a bit, there's always DBAD - it's quite popular for underground tools.

Here's an even shorter and blunter license: http://www.wtfpl.net/about/ (altough you might be less likely to receive a pint when someone becomes rich from your work)

11 hours ago, Neil Pate said:

I can not really just make public my GitHub repository for my actual commercial project as it contains a bunch of stuff my customer would probably not want in the public domain

Note: "Public domain" has a specific meaning in copyright law, and it doesn't just mean "viewable by the public". If a work is said to be in the "public domain", that means either copyright has expired, or its authors have formally renounced their claim to copyright.

As @jacobson said, a piece of code can be publicly viewable but the viewers might not have permission to incorporate the code into their own work.

If you want to disclaim copyright (as opposed to using a license that says "I own this code, but you can do whatever you want with it"), see https://unlicense.org/

6 hours ago, Mefistotelis said:

o modify a lot of VIs, you may use pylabview - if you know how to use use python or bash, you can make a batch to extract, modify and re-create any amount of RSRC files with it.

You only need to make the script which does the modification, ie. add the documentation to one file, and compare extracted XML before and after the modification to get a patch to be applied to all other files.

You can do it all in LabVIEW itself:

3 hours ago, Michael Aivaliotis said:

A for loop will do it easily:

That's what I meant by "write a bit more code" It's not a showstopper though, especially since we can put that in a VIM.

Thanks for the video link.

30 minutes ago, Michael Aivaliotis said:

Curious, does this change your choice in using them or is it purely academic?

It makes me relieved that my fears were unfounded.

In the beginning, I was under the impression that LV 2019 maps were like C++ maps as @smithd described, where the value type is chosen by the programmer and fixed at edit time, and no variant conversion was involved. All was fine and well.

However, when I read AQ's comment ("Variant attributes and maps use the same — identical — underlying data structure.... the conversion time to/from variant for the value tends to dominate for any real application"), I misunderstood him so an uncertainty crept into my mind. I thought, "Hang on... could it be that LV maps are simply a nice wrapper around the old variant storage structure? That same structure that always stores data as variants? If so, that means maps require variant conversion which makes them less awesome than I originally thought!"

The subsequent replies showed that I had nothing to worry about. Also, if I had thought it through more carefully, it would've been obvious that the LV 2019 map can't possibly be a simple wrapper around variant attributes because the old structure doesn't support non-string keys.

---------------

TL;DR: I misunderstood AQ and didn't think clearly, so I got worried that LV maps had a flaw. The worry was unfounded. Maps remain awesome.

--------------

Anyway, even if maps did require variant conversions, that wouldn't make maps any worse than variant attributes. The map API is a lot cleaner^ than the variant attribute API so maps would've still been the better choice.

Since maps don't require variant conversions, that makes them far more awesome than variant attributes.

^One exception: I have to write a bit more code to get the list of map keys, compared to Get Variant Attribute with an unwired "name" input

On 5/7/2020 at 9:41 AM, Aristos Queue said:

No. That's not what I said at all. 

My apologies. I just wanted to make 101% sure that "Variant attributes and maps use the same — identical — underlying data structure" does not mean "maps store data as variants just like variant attributes".

I'm now 101% sure; thanks for replying.

2 hours ago, drjdpowell said:

I think LabVIEW CG doesn't automatically resave files, when opened in new versions, anymore

I think that's because @Neil Pate was doing the Right Thing™ by enabling "Separate Compiled Code from Source".

Unseparated VIs will ask to be re-saved if opened in a newer version.

9 hours ago, Aristos Queue said:

Variant attributes and maps use the same — identical — underlying data structure.

Does that mean a LabVIEW map converts the data to/from variants behind the scenes, even though the datatype is fixed at edit-time?

8 hours ago, Aristos Queue said:

Friday, May 1 10am, CDT
Join here (Microsoft Teams required): LabVIEW 2020: G Interfaces

Thanks, @Aristos Queue! I'll be tuning in.

Quick note about branding: The event title is currently "Intro to G Interfaces in LabView 2020" (I peeked at the event on Microsoft Teams)

One feature I miss dearly in NXG is the ability to create type definitions inside classes. Want a typedef'ed enum inside a class's namespace? LabVIEW CG says "No problem", LabVIEW NXG says "No can do".

For example, I could previously have multiple enums called "State" in my project because each copy is in a different class/library: ClassA.lvclass:State.ctl and ClassB.lvclass:State.ctl. However, NXG forces globally unique names for enums/clusters.

* I last checked in NXG 3.0 -- perhaps the ability will exist in NXG 5.0?

16 hours ago, Neil Pate said:

The GUI is so dull in general. The colours are washed out and grey everywhere is just depressing. It sounds silly but it makes me not want to use it.

I think this trend started a few years ago: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Restore-High-Contrast-Icons/idi-p/3363355

2 hours ago, Thoric said:

My code is not broken. It runs from source perfectly fine.

It's a common problem in LabVIEW.

• Here's one potential "fix": https://forums.ni.com/t5/LabVIEW/Building-LV8-5-application-EXE-error-1502/m-p/2387406
• Another potential "fix" is to close all your Windows explorer windows, restart LabVIEW, and try again.
• Yet another one is to restart LabVIEW and clear your compiled object cache.

8 hours ago, drjdpowell said:

All copies are presumably running in the same LabVIEW runtime engine; could there be any relation to the Runtime Engine?

Multiple instances of the same LV executable spawn multiple processes in Windows 10 (tested on 2017 SP1 32-bit), which means they (and their DLLs) have separate memory spaces even if they use the same version of the LabVIEW RTE. My test used a 3rd-party DLL which contains a global "quit()" function; calling the global "quit()" on 1 instance did not affect the other instance, which confirms the separation of memory.

Other things I'd check:

• Does the crash occur if you only run 1 instance of your test with simulated random data?
• Does the crash occur if you run your multi-instance test on a different PC?
• Does the crash occur if you run one instance built with LV 201(x) and another instance built with LV 201(x+y) on the same PC? (Preferably with older versions of LabVIEW, before NI introduced backward-compatible LV RTEs)

9 hours ago, drjdpowell said:

(they were running independently on simulated random data)

How does the DLL cope with invalid data? (e.g. divide by 0, Inf, NaN)

9 hours ago, drjdpowell said:

The dll just does a calculation (complex, but does not access anything external)

Are you 100% sure that the DLL doesn't attempt any inter-process communication, network access, file access (including the temp folder), etc.?

12 hours ago, X___ said:

your next step DLL is fooling you (or is it?) if it reports 1.4...E-45 as the next value after 0

Taylorh140's result is correct. He was talking about SGL values.

When you're using a 32-bit SGL, 1.4013E-45 is the smallest possible positive value. In other words, 1.4013E-45 is the next SGL value after 0.

When you're using a 64-bit DBL, 4.94066E-324 is the smallest possible positive value.

2 hours ago, Neil Pate said:

this is a brand new CPU with a Ryzen 3600 in it.

I don't know if this is related to your issue or not, but there are known problems with some brand new AMD Ryzen CPUs: https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-destroyed-my-weekend/

See if updating your BIOS helps at all. (Even if it doesn't solve this problem, I'd imagine you want a functional RNG on your PC!)

8 hours ago, bmoyer said:

The issue comes and goes (it doesn't work more times than not).  Incognito mode is disabled by IT here.

...

Clearing the cache and history and logging out of Chrome didn't help. 

Judging by your screenshots, there is a problem with the DNS server that your Chrome and Firefox are trying to use. IT might have configured your Internet Explorer's DNS settings differently. I recommend asking IT for help -- describe your issue to them and show them your screenshots. Mention that the DNS server works reliably for Internet Explorer but not for Chrome/Firefox.

(I'll qualify my previous question: "What happens if you try on a different computer that is not managed by your IT department?")

3 hours ago, bmoyer said:

if I use Chrome (or Firefox) to access LAVA G, it hardly ever works (doesn't show the website).

LAVA opens fine for me in Edge 80.0, Chrome 80.0, and Firefox 74.0.

What happens if you try on a different computer? What happens if you try in Incognito/Private mode?

26 minutes ago, Michael Aivaliotis said:

Does anyone know the proper way to clean up the NI crap?

Using SpaceSniffer, it show the bulk of it is used by the Update Service and NI Package Manager. I'm sure it's just leftover installers that may be needed.

I don't know if a "proper" way exists, hence https://forums.ni.com/t5/NI-Package-Management-Idea/Add-ability-to-reclaim-space-taken-by-cached-packages/idi-p/4024241

I've been manually deleting the *.nipkg files, and the very old folders in C:\ProgramData\National Instruments\Update Service\Installers, without ill effects to my day-to-day work.

I think NI Package Builder or LabVIEW Application Builder can't bundle a dependency if its package or local installer is gone, however.

12 hours ago, Mefistotelis said:

though it prepares only small chunks of code linked together by the LVRT.

You mean like how a Java compiler prepares only small chunks of code linked together by the JVM?

7 hours ago, FixedWire said:

Creating a wrapper dll for the SDK really complicates this as it will need to be validated. The http://weblog.ikvm.net/  .NET interface seems dated and no longer supported.

I don't understand: Doesn't your test software need to be validated too? And IKVM.NET is a generic wrapper of Java in .NET -- it is not a direct interface for the Bluetooth driver. Why won't this need to be validated?

In any case, someone else forked IKVM: https://www.windwardstudios.com/blog/ikvm-is-alive-well

There are some examples online about using CANopen in LabVIEW: https://forums.ni.com/t5/Example-Code/CANopen-Reference-Example-for-the-NI-9853-C-Series-CAN-Module/ta-p/3996129?profile.language=en

Your last FFT image shows that most of the noise content is in 50 Hz and its harmonics. I'm guessing that you live in a country with 50 Hz mains power, and the electromagnetic radiation is being picked up by your system. You wrote that the system "gives noisy reading even if bias resistors are used" -- Why would you expect the bias resistors to reduce noise? If anything, those long, unshielded resistor leads make them even more sensitive to radiation.

Ways to reduce electromagnetic interference include:

• Using shielded and/or twisted-pair cables.
• Using shorter cables.
• Checking your grounding.

Your first plot shows huge voltage drops from 1.25 V down to 0.2 V. I'm guessing you have a group loop or short-circuit somewhere in your system when your laptop's power adapter is connected.

4 hours ago, Ricardo de Abreu said:

Raspberry Pi4 vs BeagleBone Black Vs arduino.....

Raspberry Pi and BeagleBone are full-fledged Linux computers. Arduino is a microcontroller.

Compare their specifications and I/O to see which one meets your requirements.

See also https://forums.ni.com/t5/NI-Blog/LabVIEW-Community-Edition/ba-p/3970512, especially the part about "Hobbyist Hardware".