Sparkette

1 hour ago, Rolf Kalbermatter said:

LabVIEW on non-Windows platforms has no license manager built in. This means that if you could download the full installer just like that, there would be no way for NI to enforce anyone to have a valid license when using it. So only the patches are downloadable without a valid SSP subscription, since they are only incremental installers that add to an existing full install, usually replacing some files.

Ah right, I forgot about that. Though I swear I remember using a trial version on my Mac at some point back when I used one.

I wonder though, do they really need anything elaborate for a license manager? I doubt it would be difficult to put something together from scratch. I guess it wouldn't necessarily be worth the effort for a free product though—hell, I wasn't expecting them to ever give away LabVIEW for noncommercial hobbyist use at all, as much as I hoped they would.

I already filled out the Site Feedback form reporting it as a bug, but I guess if nothing else it'll make them aware that the message is misleading.

I'm going to try bypassing the NI Package Manager by copying an already-completed installation from a VM into Wine.

Has anyone mentioned how long it takes to start up?

1 hour ago, JKSH said:

It's not related to latest vs. older. The patches don't require a login to download (even 2009 SP1 Patch). The full versions require logging in with an account with an active SSP.

It specifically says "previous versions" in the message.

25 minutes ago, JKSH said:

I haven't tried WINE, but there is a Linux installer for non-community versions of LabVIEW: https://www.ni.com/en-us/support/downloads/software-products/download.labview.html#344886 (It uses RPM packages)

It seems to think that LabVIEW 2020 isn't the latest version, saying an SSP subscription is required to download it. My guess is there's a bug where it thinks "2020 Patch" is the latest, even though it requires "2020" in order to install.

Still though, it doesn't have Community Edition. But it does make me wonder about something: IIRC the only reason they don't have it available for Linux is because of technical issues with the license manager, rather than any desire to force people to use Windows. So if I were to download a different edition for Linux and crack it to work without a license, while I'm aware that would be against the EULA, would I really be violating the spirit of the EULA as long as I don't use it for anything I wouldn't be allowed to use Community Edition for? It would only be as a necessary part of a workaround for something they'd presumably allow if it were technically feasible, so maybe NI wouldn't care. That's how I see it anyway. Don't take that as legal advice though!

I've tried both NXG and 2020 (both Community Edition) and get the same problem: the "NI Package Manager" window appears, but it's solid black, and just hangs. I know LabVIEW probably wasn't designed with Wine in mind, but is anyone aware of a fix? It would be nice to run it on Linux without all the overhead of a VM.

On 8/25/2019 at 10:33 PM, Porter said:

I wonder if they will also release a community edition for Linux.

I hope so. It would be nice to not have to bother with a VM.

On 5/9/2019 at 1:36 AM, Michael Aivaliotis said:

I have no idea. That seems to be a URL in the old format which died a log time ago. The post probably still exists but was converted to a new URL format and there is no redirect.

Seeing as you're the admin, is there any way you can set up a redirect? Maybe something on the site where you can paste a URL and have it find the current link?

On 4/19/2019 at 5:26 AM, gb119 said:

Is this the problem of handing 'volatile' state where you need to track state during the run-lifetime of the XControl but do not want to persist it to disk? Using the display state and setting the corresponding boolean in the action cluster then marks the host's dirty bit....? For my XControls I ended up storing a copy of the state in an LV-2 style global. To support multiple instances of the XControl, the LV-2 global is actually a variant and I store the state in attributes of the variant using the container refnum (cast as a string) to provide the attribute name. The first thing the facade does is to read the state and the last thing is write it back to the LV-2 global.

XControls are a bit of a pig, on that I guess everyone can agree....

Isn't there an optional ability VI you can add to an XControl that will modify the state before saving? It says it's specifically for this purpose.

On 4/17/2019 at 12:22 AM, Aristos Queue said:

If QControls come into LV 20xx, they'll be as they are today -- no additional bells and whistles. That's a big "if", by the way. Several of us continue to make the argument, but since they're available as a toolkit, it's hard to make the case that they need to ship with LV. Being owned/maintained by NI only makes them more generally available and means no one has to worry about third-party IP licensing. We will see how this plays out. The kudos on the Idea Exchange has been useful.

There are no plans to extend LV 20xx capabilities of XControls or anything similar. All work into improving G-based UI components is being done by NXG teams. I and others continue to push requirements to them (such as "let them be included in arrays"). (In case y'all are wondering, my role with NXG is largely "lead user kibitzer". I have worked on various parts of the code base over the years, but at this time, I am 100% tasked with adding features to LabVIEW 20xx, especially language extensions (there are others on my team working on editor improvements). The channel wires and the malleable VIs have been my work; there's a couple new data types in LV 2019 that fill some serious long-standing language holes. And LV 2020 should... well... let's say I'm kind of eager for it.)

Aww, that's a shame. It would still be nice to get it added to LabVIEW though; then it will be possible to use this framework without adding a big dependency.

New data types sound exciting though; are you allowed to say what they are? (A hint at least?)

@X___: I'm curious, how did you make that class wire look like that? I know how to do it; I'm just curious if you used my tool to do it.

I haven't used this toolkit much but I'm using a Windows 7 VM as well and I haven't noticed any issues.

This'll be a feature in the next version.

Also wtf, those six characters in the screenshot filename just came from an RNG

When I mentioned manually manipulating the resources I was actually thinking something like #3. Well to be more precise, I was picturing my own tool (linked in my signature) that can do the same thing, but NI certainly has their own that they use, that's probably better than mine. (lets hope it leaks :p)

On 3/16/2018 at 11:15 AM, Aristos Queue said:

No mechanism exists to launch it.

Attached to this post is a VI that has exactly the same front panel as the Edit Events dialog from LabVIEW 2017. You could put code behind it if you wanted to use it elsewhere, but the only thing currently on the block diagram is a bunch of FP terminals.

Edit Events Dialog.vi

I'd think you used this but I don't think it works in LV 2017. Did you manually pull the VI from lvdialog.rsc and copy the FPHP to a new VI?

Here's a shortcut menu plugin I wrote that does something I've found myself needing every now and then. You select some objects, right-click, select "Ad-Hoc Scripting", and then it'll open a new VI with pre-populated refnums in a cluster. All selected objects will be included in the cluster, as will a refnum to the VI, its panel, and its diagram.

Ad-Hoc VI Scripting.llb

2 hours ago, The Q said:

As for making it a single terminal as XControls are, I have found no way to do that. It would have to be functionality NI would add.

Yes, that's what I meant. If it's being added as a native LabVIEW feature, then maybe NI will add this functionality. I'm asking whether or not they will, as it seems obvious that they would if they were developing the feature from the start, and it would be a shame if they didn't. I'd like to know what they have planned. Also, what about clusters and arrays?

21 minutes ago, smithd said:

2019 is almost certainly done already. Since its integrating an addon, it could come in SP1, but I'd bet 2020 if it happens.

In that case I'm hoping for 2020, because what you're saying makes it sound like SP1 would mean the stuff I'm asking for isn't there.

How long do these things usually take to go through? Is this likely to be in LV 2019 if it's accepted? Or more likely not until 2020? (or later?)

17 hours ago, ShaunR said:

We've been asking for that since about LabVIEW 6. Instead, we got xcontrols (xcontrols do a lot of what you are asking for, by the way. They are just buggy and unpredictable).

NI can also have some DLL controls using a completely undocumented API. Sounds like that might be right up your street 

Yeah but I want the best of both worlds, extending existing controls while also being able to use it via just a block diagram terminal. Also I'd like something I can put in an array or cluster; XControls can't do that and I don't think QControls can either.

I've actually been meaning to see if I can figure that out, lol. I already know how you would load a control from a DLL: there's a hidden "Plug-In Control" object that, when placed via scripting or a modified palette, allows you to load a DLL from the context menu. You can place it via my Place by Style Quick Drop plugin. Incidentally an uninitialized plug-in control is the only way I know of to get a control with "void" as its type. (And I don't mean empty clusters or void arrays.)

Wow, I love that idea, and it's great to see there's already an NI employee on board with it. I posted a comment on it; I'll quote it here:

What would be REAL nice would be if we could use them just like regular controls. That is, you just place it from the controls palette, just a regular terminal on the block diagram that you use like any other, and (most importantly) they behave as expected inside clusters and arrays. Just like with regular controls, you don't need a reference to the control for basic read/write functionality; if you want to do something more advanced that requires a reference, you can use the VI Server Reference node. Maybe even have the reference wires automatically (or through To More Generic Class) coerce to the refnum type of the control it's based on without anything extra.

Basically, if this is implemented the way I hope it is, using a QControl would be no different from using any other control. And of course, the current way of using them would still work, for backward compatibility.

Think this is a possibility to any extent?

 

Yeah I could see that being helpful at some point.  What happens when you have more than one primitive/Subvi on the diagram in the node?  Does it just place another entry at the bottom of the unbundle?

Yep.

 

Yeah this is neat and useful...how much of this black magic is built into LabVIEW and how much did you develop?

What do you mean specifically?

 

Next to your custom.vi there was statediagram.vi

Is it the source code to NI's Automation and syncing of state machines?

I would love to customize their tool and create automation for my own flavor of a state machine that will keep in sync with a UML diagram.

It was tried in other languages and failed but for basic usage, it could be nice

Very observant! This is making use of an obscure, probably unsupported feature in LabVIEW called an "External Editor Wizard". The only official one that exists to my knowledge is the State Diagram Editor, which works similar to the Statechart Module (which, incidentally, is what the functions supporting the editable embedded diagram were built for) but it has fewer features and is available for free. The way External Editor Wizards work is you place one from the palette, and draw a box like with a structure. Then a VI generates some stuff with scripting, and it opens an editor to manipulate the code. You could call it a type of "Express Structure"—it works like an Express VI, with how you can configure it, except it exists as multiple objects in a structure on a block diagram, instead of as a single node. From what I can tell, the structure can be of any type, except a Flat Sequence Structure, as for some reason that doesn't descend from the Structure class. (I'm using a stacked sequence here, as with only one frame it looks and acts identically.)

It appears that this feature was never intended to be used for anything other than the State Diagram Editor, as if I right-click the structure and select Properties, it tells me I can't edit the properties because the structure was created by the State Diagram Editor.

As it happens, I think I actually thought of a better way to get this same functionality, that doesn't even rely on anything unsupported. So I'm probably just going to do that. I'll still release this (incomplete) version when I get home from work though, just so you all can see how it works.

https://gfycat.com/formalgentlelemming

Not this particular use of it of course, but just in general.

Sorry the cursor isn't there; you can still easily see what's going on though.

EDIT: I rewrote this as a shortcut menu plugin that just opens a regular block diagram window:

Here's the old version in case anyone wants to play around with the External Editor Wizard stuff, or my subpanel diagram code:

Old AHS Editor.zip

Just pretend it means you're one of the Knights. :p

From old URL's like this one for instance: http://forums.lavausergroup.org/index.php?showtopic=1524

It's not on archive.org. I figure it's safe to assume the staff wouldn't have deleted all the old stuff, so where is it?

There's a private method on the Application class called Enable External Proptypes, that has a single Boolean "Enable" input. The description says "Enable or disable external G-based proptypes call". That sounds interesting; it makes me think perhaps it's another hidden, likely-buggy method for doing internal LabVIEW stuff in G, like XNodes/External Nodes, or External Editor Wizards (like the State Diagram Toolkit.) I'm pretty sure "proptypes" is an abbreviation referring to type propagation, so that could be fun to mess with. Anyone have any ideas?