smithd

I find it amazing how convoluted licensing gets..considering thats literally how all money comes in. And I don't say that to pick on JKI -- I say that to pick on a company I saw today which has no less than 7 core software packages, plus for 3 of them you have to buy an add-on for support, plus there are several add-ons compatible with all base versions, plus one specific add-on only compatible with the upper 2 tiers, plus an additional add-on cost per seat which varies based on which base model you selected. It made me ? NI vision is another example -- not quite as bad, but I still have no clue which imaq functions are included with what license.

(2) I think I've mentioned this elsewhere, but its more accurate to say that NIPM has no knowledge of labview. Its simply a system-level package manager, akin to opkg, apt-get, chocolatey, etc. You can make the same source distribution in say, Labview 2015, but since its an OS-level package manager, you have to make a different package for each of Labview 2015, 2016, ..., 2015 x64, ... One comment on that, is if you look at the NI installers, they often just make one package and install the VIs anyway. I only have 2017 installed, and yet I have a labview 2014, 2015, and 2016 folder for whatever reason. So nothing stopping a more lazy package developer to make a single package that deploys the same source distribution to 12 different directories. (3) I believe NIPM can technically do this through a custom XML file, pointing at a simple batch or at cmd.exe: http://www.ni.com/documentation/en/ni-package-manager/latest/manual/instructions-xml-file-packages/#GUID-29BE2213-93C1-4281-8570-7CE1338AEB4A http://www.ni.com/documentation/en/ni-package-manager/latest/manual/assemble-file-package/ (6) Yeah, an otherwise empty package with dependencies is the traditional fix for this (8) Actually this is the part I like better about the NIPM build process -- its much more explicit and it seems easier to me to figure out when stuff goes wrong. Also, a good landing page for NIPM is: https://forums.ni.com/t5/NI-Package-Management/NI-Package-Management-Portal-READ-THIS-FIRST/ta-p/3805952

For a counter argument, ask NI marketing "is DSC dead?" Last time I heard that question they bent over backwards to claim it's not, and yet...

https://github.com/jkisoftware pulled a few of the repos over to github but it doesn't look like any work has been done (the updates shown are just licenses/readmes). I definitely agree with most of those as 'this would be nice' Also, and I realize this is kind of petty...but why green? Why on earth...snowy mint?

I thought it sounded familiar Thats definitely true, I just think that in the case of openg theres no real reason not to merge a lot of them (bool, string, error, comparison, array, data, numeric, time, file) because all of those are basically vilib++. While people might not really want all of them, I doubt many would object to "too much bloat". But to that point, any attempt to modernize openg would have to look hard at whats there. For example, from the error lib: Labview has all of the red items on the palette already, filter error codes is just a for loop around clear errors (from 2014+), and the case structure is...just a case structure with error wires in and out. Personally I use this, although admittedly it took me >5 minutes to find it and I'm the one who wrote it. And this error lib is a dependency of pretty much every other package, because its also a dependency of the string library.

Just for myself, I don't really use openg and never have. I've definitely been using lv for shorter than many on here, so I'm curious if thats part of it (ie lv has picked up the slack over the years) or if its just me. Distributing code that uses it to other people always ends up being annoying. I'd rather write a for loop to remove duplicates from an array than try to explain to some coworker that they need to first install vipm and then look for the specific package and then when it asks to install 17 other dependencies install those too, etc. The for loop is easier.

Link is now dead, they got the feedback I guess. Well, the feedback that this particular install is bad. Not the feedback of "maybe you should test these installers before uploading them" ?

Yeah VIMs are pretty buggy although I'm still back in 17.5. For one particular set (using classes of course) I've had to just convert every instance to static manually, else the exe won't compile. Fortunately I just use them as helpers at the very top level, and drjd's json ones haven't caused any issues.

https://dotnetcademy.net/Learn/4/Pages/1 Its roughly analogous to combination of VI server/scripting + lvoop class loading + variant data type inspection VIs + openg type code inspection VIs...except with a more consistent design His point is just "if you can't call the constructor directly because labview is broken, you can have .net call the constructor manually, by name, using reflection". The direct labview equivalent of what he posted is https://zone.ni.com/reference/en-XX/help/371361P-01/glang/get_lv_class_default_value/

Did they fix your issue here? https://forums.ni.com/t5/LabVIEW/TDMS-Excel-Add-in-18-Crashes-Excel-2013/td-p/3796275 I ended up just removing all of 2018 and reinstalling the driver set because I couldn't make that stupid plugin revert properly (in part because I had NIPM installed)

Yeah, chrome, and I have ublock but its disabled on lava

any ideas why this might be happening? Specifically, everything is bold, regardless of being new or not. I only see this on one computer, but its the same profile (and browser, extensions) on both.

Yes they fixed some of those silly things in more recent versions. Also turning off the call chain on error cluster to code so that RT systems didn't do tons of string manipulation. If I remember his posts correctly shaun uses some ancient version like labview 8.1 or something

Indeed

Having spent this morning trying to deal with vipm I have two additional suggested requirements: 1-Dont require a GB of RAM to unzip a few files 2-Dont dick around with the windows API every few seconds in an attempt to get the user's attention 3-while performing long running operations, don't queue up 10M instances of a 'refresh' message so when the long running operation completes your user is still sitting there for five minutes watching the screen refresh.

also, google immediately gives several examples.

I don't fully understand what you're wanting to do, but as a starting point it sounds like you want to use the producer-consumer pattern where the daqmx code is a continuously-running data producer and your UI is a data consumer. They communicate using a queue (eg a first in first out buffer, as you suggest). There are sample projects included in labview (eg "continuous measurement and logging" here http://www.ni.com/product-documentation/14031/en/) which may give you a better starting point than a blank diagram. It also sounds like you may need some assistance with how to trigger and fetch your data -- it sounds like you need something like this (https://forums.ni.com/t5/Example-Programs/Finite-Acquisition-with-a-Software-Retriggerable-Reference/ta-p/3530011) but you might also read through this: http://www.ni.com/tutorial/4329/en/ Also, depending on how much you want to do or how far you want to go, it may be worth the money to just buy an application like FlexLogger: https://youtu.be/hoNoJjMsuGI You can download a demo and see if it does what you want http://www.ni.com/en-us/shop/data-acquisition-and-control/flexlogger.html

Except that in this case we're talking about a reference which refers to a type def. Saying this is consistent behavior would be like saying "its OK for any queue refnum that references a type def to break whenever the type def changes" -- something that obviously does not happen.

Probably did not explain it right, but attached is an example. Open main.vi, open the type def and add a field to it (eg a 2nd string). Save and close the type def and the code breaks because while the VI ref is tied to the type def, the controls appear to be tied to the version of the type def at the time of their creation -- eg, type prop fails. The solution for bigger projects is to type def the control or wrap it into a class or whatever, and then you only manually update it in one place, but I find that pretty annoying as well so I do the variant form (terriblesolution.zip) as this requires zero manual updates. On a related topic, I would have no objection to someone coming here and saying "you're an idiot, you can make it update if you just do X" but I haven't found any X so far. bug.zip terriblesolution.zip

Never heard of this, but makes sense. I do the same (using variants of course) when it comes to static VI refs (eg 'call and forget') because any change to a type def in the connector pane breaks controls/indicators -- type prop doesn't update them. So I have my create reference in one subVI that spits out a variant and then everywhere I want to launch an instance I just have another copy of the static ref and a variant-to-data function which casts it back. Avoids annoying labview bugs that way.

I tried this out and can confirm that accidentally swapping types has the following behavior: dbl->dbl = OK string->dbl = always displays the prior value of the DVR -- probably something bizarre to do with the fact that I started with dbl-dbl and its in debug so the memory space stayed the same. No error though, and the value didn't update as I changed the dvr (string) value. int(0)->str=OK int(positive number)->str=crash

DD doesn't work directly on a DVR (except property nodes), hence my malleable VI suggestion. Of course malleables just make it easier to call -- you still need to have the method in the class, so your tool would still be useful. To clarify, it can crash labview if you get it wrong and uncast to the wrong type. Or so I'm told. I've never attempted to do this because a variant is a type-safe way of accomplishing the same task.

As a general rule I prefer this style to the DVR-of-a-class (eg session framework: https://forums.ni.com/t5/Reference-Design-Content/Extensible-Session-Framework-ESF-Library/ta-p/3522019) The argument against it, which is also very valid, is that its hard to indicate that your class has by-ref features because by definition that dvr inside is private. So they must operate as if your class is by-value unless they know the class and all children have no by-value components. You could make the same argument about sticking a visa reference in your class -- its a reference, but you wouldn't go calling your class a by-reference class. Using a DVR-wrapped class and the malleable VI features added in 2017sp1 would seem to be a nice route. You can template the DVR unwrap and define an interface which the malleable VI will adapt for you. For context to the below post, I previously commented that I'd prefer a tools menu item because the project provider scares me, but I looked around and theres a lot of examples out there so I decided to remove it...at the same time it was being replied to.

Don't do this, it can crash labview. If you need to cast, I think a variant will at least be safer (var to data should return a NaRefnum if its the wrong type, while cast to and from int will have labview attempt to dereference a random pointer you told it was good). There may be guards against it, but its not worth it.

I've always done a separate 'data' or 'data formats' library. Its generally useful for your situation as well as the lv real-time situation (don't want to load up a bunch of PC-side libs/classes into RT land, but still want type-safe messages). If its all on a single target, I'd probably be lazy and do what I think you said: the target of the message owns the data type. But of course that breaks down if more than one target uses that type.