DTaylor

49 minutes ago, bbean said:

I want to say I've seen this when one of the modules has gone bad.  Have you tried pulling them all out and then installing them one by one to see if one of them causes the problem?

This is without even connecting to the RT target. An empty chassis on a new target in a blank project gives the same error. We're trying re-installation one more time.

I have a coworker trying to load a project that uses a cRIO. He is encountering errors I've never seen before. I had him uninstall all NI software and reinstall LabVIEW 2017 SP1 (+patch), LabVIEW RT 2017, and CompactRIO 20.5. The issue persists. Has anyone seen anything like these before?

The issues happen even in a brand new project with any added RT target.

On 4/28/2023 at 1:28 PM, infinitenothing said:

Does anyone have an opinion on "in memory" key-value stores that are accessible over a network?

I do. REDIS is great. It's much nicer to work with than shared variables or OPC. The downsides I can think of are:

1) You need a Linux server or Windows new enough to have WSL2 to run the server. There is no official Windows build

2) The protocol is simple, but the API is pretty big. I don't know if anyone has created a publicly available LabVIEW client. You can put together a client library with only the most common commands pretty quickly though.

What awesome thing(s) do you have in the basement? Or is that a garage?

Thanks for sharing this. This is awesome!

On 9/29/2021 at 10:09 PM, ShaunR said:

Since NI released their poultry offering

bocboc

3 hours ago, Antoine Chalons said:

So just out of curiosity, has anyone ever tried to use TOML?

It is a really nice format, but I'd recommend using something else in LabVIEW because of lack of support, unless the EM library covers everything you need.

3 hours ago, Antoine Chalons said:

Intersting, have you considered submitting your bug-fixes on the github repo?

The repo is unmaintained. (source: I'm the author)

My biggest disappointment is how sluggish it is compared to 20xx, though it has improved since the initial release. Loading an empty project takes 3x as long in NXG for me.

I do like the single window environment.

On 1/3/2020 at 1:24 PM, Aristos Queue said:

Unwilling, not unable. I'm proposing it as a research vein over the next couple weeks. If The Powers tell me there's zero chance, I won't even bother getting into it ... it's a brainstorming rabbit hole that I think has benefit, but few others agree with me, even among customers. If I get a go ahead for it, I'll probably be discussing it at the CLA Summit in September.

Sounds interesting. I'd love to hear what it was even if it gets shot down.

Do you have any stories of ambitious/controversial proposals that never had a chance?

26 minutes ago, Aristos Queue said:

c) Your timing is impeccable. Status changed to In Development (should've been set that way six months ago... we missed it in the list):

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/SSL-TLS-Support/idi-p/3314187

Finally!

4 minutes ago, Aristos Queue said:

Well, it isn't interfaces... those are at "priority zero... in beta... conditions look good for launch in T-minus 4.5 months."

!!! Is there anywhere we can read about specifics?

You've given us priority #0 and #2, are you unable to share #1?

4 hours ago, Aristos Queue said:

... It is priority number two ...

What's number one?

On 7/13/2018 at 9:17 AM, crossrulz said:

I can't say I support the use of the Write DVR Value.  The point of using a DVR is to protect critical sections of code (ie avoid race conditions).  If you are just randomly writing a value to a DVR without doing the Read-Modify-Write protection, you might as well use a Global Variable and get better performance.

I think it can be useful in cases where you don't need RMR protection and the DVR is part of some sort of data structure that you may have more than one of, making globals not an option or a poorly scaling option.

There are lots of design decisions with C++, C#, and Java that in hindsight are poor, but I don't feel like the author focused on the problematic parts, and maybe confused/conflated encapsulation and abstraction.

In my opinion, this style of OO can be best described by:

• the ability to bundle data (something like a struct or record) and operations on that data (methods, which are essentially functions with an implicit "this" argument) into classes
• the ability to extend classes via inheritance, and automatically and irrevocably get subtype polymorphism, which can be ad-hoc through overrides
• the ability to hide implementation details within a class (private fields & methods)
• Additional ad-hoc polymorphism via interfaces

I don't think I have a problem with a language having any of those features.

I don't know if bundling data and operations is helpful, but I certainly don't think having the option is harmful. I do appreciate that the <class instance>.<method>() syntax is ergonomic. This can also be achieved by "." being syntax sugar where <expression>.<function>(...args) is equivalent to function(expression, ...args).

I do think it's a problem when developers shoehorn their data types into convoluted inheritance hierarchies, but this isn't an OO problem. It's equally problematic when developers shoehorn data types into any convoluted data representation. I acknowledge that there may be some times where the type extension along with the subtype polymorphism may be an elegant representation.

Hiding implementation details is not something I see as problematic at all, and it's not unique to OO languages. Other languages allow private struct fields and other definitions that are only usable inside the module where they're defined.

It's nice when languages have something more powerful than these style of interfaces like Rust's traits or Haskell's typeclasses, but I don't think that makes interfaces bad, maybe just less useful.

The big problems with these languages are:

• null - Anywhere you expect a class instance you must also expect the possibility of null. Terrible!
• unchecked exceptions - effectively an implicit potential return type of every function you write. Terrible!
• lack of type-safe sum-types/discriminated unions/tagged unions. Abstract parent class and multiple concrete children, the OO equivalent, is comparatively clunky. Scala's case classes are a nice implementation with an OOish flavor.
• lack of robust treatment of functions as data (this is improving as functional concepts are making their way into other languages)
• inability to extend the functionality of classes without subtyping
• Unsoundness in Java's type system via inappropriate generic covariance
• C++ being enormous and complicated
• loads of safety issues in C++, but it should get a partial pass for being a lower level language
• C++'s lack of package manager - this is an ecosystem problem, not a language problem
• verbosity

What are the alternatives?

• Maybe<T> instead of null (a generic sum type which is either T or nothing. It must be cased on)
• Result<T, Error> instead of exceptions (another generic sum type that is either T or an error. It must be cased on, and what an "error" is a different language decision)
• Give the option for sum-types! Please LabVIEW!
• Give facilities for functions as data, lambda functions, partial application, etc.
• Rust-style traits, typeclasses
• Appropriate generic covariance/contravariance (invariance if you can't be sound otherwise - restrictive is better than unsound)
• Good package managers & build systems
• type inference

What languages do these things well that are easy to use? In my opinion: TypeScript, F#, and Scala, which all also support OO stuff. Rust is probably my favorite language, but it is not easy. Haskell is great as a learning experience, but is definitely difficult and is so high level that it makes it hard to reason about when your program will do what at runtime because of laziness.

On 3/5/2018 at 5:14 PM, David_L said:

I can almost bet that if I were to start over fresh and run LabVIEW as an admin before installing the first time, it would work fine.

Did RegisterAddon.exe not run at all, or are you thinking it ran with incorrect privileges? I do see RegisterAddon.exe run every time I install.

18 hours ago, David_L said:

Hey David,

It looks like a cool concept, but just FYI, this didn't actually work on my system after installing it.  It seems there's an invalid license which causes the library to be broken.  Using version 4.0.3.2 on LabVIEW 2016, Windows 10.  

Best of luck,

David_L

I think the included license is OK, we have a handful of users successfully using the trial, though you're the first to try it on Windows 10 (I don't see why that would matter). I did see the invalid status come up once when I was testing, though I don't remember the cause. If you uninstall the EM Control Refs package and re-install it, does it fix the issue? Would you be able to post a screenshot of what you're seeing? Thanks!

Language-independent update just landed!

For those curious, the node was creating some property nodes and setting the selected properties by the property's name, which varies from one language to another. We just needed to update it so that they were set by the property's unique ID.

For right now, this node only support English LabVIEW installations. We are working on a language independent update.

We have an internal tool at Erdos Miller that we've turned into a product. It's a node that outputs a cluster of references to all controls on the front panel. A free trial is available for download here:

http://info.erdosmiller.com/node-control-references-software-download-v1

It replaces code like this:

With a single node:

It also lets you:

• Bind the output type to a typedef.
• Include a reference to the owning VI and/or the owning VI's front panel.
• Exclude references to controls above or to the left of the origin.
• Optionally exclude controls individually.

Controls on tabs are organized into page clusters. Try it out and let us know what you think!

10 hours ago, Antoine Chalons said:

AQ, this VI seems to be password protected, at least in LV 2014 and 2016.

9 hours ago, Neil Pate said:

And 2015

Using this is almost assuredly a violation of license agreements:

http://www.hmilch.net/h/labview

Why stop there? It seems like there are a few nodes that disallow inlining even though it seems like it should be fine. Now we can just wrap them in an Error Ring.xnode!

I think there is just a special case that LabVIEW knows the XNode named "Error Ring.xnode" can be inlined. If I rename an XNode to Error Ring.xnode, the aforementioned error goes away.

I wonder if there is a way to whitelist other XNodes.

4 minutes ago, hooovahh said:

Somehow telling the IDE that it can or can't be placed into a VI that is inlined.

There is a VI in the same directory as the Error Ring XNode named XSFP_ReplaceSelfWithGenCode.vi. I don't know if this has anything to do with this behavior. I've seen some private methods prefixed with XSFP - any idea what it stands for?

That VI is not a member of the XNode, but I agree that none of the XNode's abilities or properties look like they have anything to do with the inlinability.

4 minutes ago, smithd said:

The xnode right click menu (i forget the ini key) lets you see the generated code. I'd suggest just opening the butterworth generated code and copying it directly onto an inline vi diagram, and see if that works or has an issue.

I did , and the owning VI shows no error when it's replaced with it's generated code.

15 minutes ago, hooovahh said:

If you drop the Error Ring XNode (made by NI) it appears to work as expected, working on inlined VIs.

Hmm Error Ring XNode does work for me, but others that I think should be inlinable are not, like the Butterworth Coefficients XNode.

11 minutes ago, hooovahh said:

So if your XNode contains something that normally can't be inlined, then the XNode is fine, but it can't be in a VI that is inlined.

I'm also seeing this if the XNode contains only nodes that can be inlined. It appears that a VI that uses any XNode cannot be inlined, regardless of whether the generated code can be inlined or not.