X___

Can't use it with 64-bit LV, AFAIK...

Actually, the nipkg.ini is in \ProgramData\National Instruments\NI Package Manager\Settings\nipkg.ini

Can't get that to work systematically. Sometimes it does the trick, sometimes it doesn't. I believe this is worth reporting as a bug. While this could be a wrong hunch, I wonder whether this might be due to the narrow scrollbar width in the NXG graph legend. Notice that it is narrower than that of a NXG array (shown on the right below). It is definitely narrower than that of the silver style graph legend (shown second from the top left), which is narrower than the modern graph legend (shown last on the left). The latter is of the same width as the classic graph legend. The reason I am suspecting this is that I have seen something similar in a utility that was supposed to return the clicked element in an array (https://forums.ni.com/t5/Example-Code/Determine-Clicked-Array-Element-Index-in-LabVIEW/tac-p/4040339/highlight/true#M14360) and failed with silver and NXG arrays because the border sizes and other details of controls have changed from style to style, and the underlying routines have not been updated. In any case, this is annoying enough to be reported.

That was a trick question.

OK. What is the idea of password protecting those CLN and not, say, those in the Analysis VIs. Are we at risk of blowing up the planet?

Are you sure of that? The hierarchy shows System Exec call, so it might be even cruder than a .NET call indeed:

The NI_Unzip.lvlib VIs are all password protected (probably because underneath, they are using some .NET calls they don't want people to mess up with). So yes we don't know what they do, although the help tells us what they can't do: Unzips the contents of Zip file to the Target directory. Set Preview only? to TRUE to preview the list of files in Zip file before you unzip the zip file. This VI cannot unzip a zip file that is password protected. Why wouldn't it support password protected archives? Anyway, the compression/decompression algorithms are not necessarily particularly well described or unique for that matter and it is therefore not surprising that some implementations might be incompatible (although they shouldn't): .NET documentation https://docs.microsoft.com/en-us/dotnet/api/system.io.compression.deflatestream?view=netcore-3.1 An old 40,000 ft description: https://zlib.net/feldspar.html quoted in this interesting "from-the-ground-up" implementation (quoting the previous reference): http://www.integpg.com/deflate-compression-algorithm/

It does seem to do exactly what I needed though, which was emulate that piece of MATLAB code: zipbuf = fread(fid, offset, 'uint8=>uint8'); tmp_dir= tempname; [SUCCESS,MESSAGE] = mkdir(tmp_dir); if SUCCESS fnz= fullfile(tmp_dir,'temp.zip'); else disp(MESSAGE); error('Cannot create folder.') end tmp_fid = fopen(fnz,'w'); fwrite(tmp_fid, zipbuf); status = fclose(tmp_fid); fnu=char(unzip(fnz,tmp_dir) ); tmp_fid = fopen(fnu, 'r'); data = fread(tmp_fid, length, type_str); status = fclose(tmp_fid); [SUCCESS,MESSAGE] = rmdir(tmp_dir, 's'); if ~SUCCESS disp(MESSAGE); error('Cannot delete folder.') end end

A simpler way might be to do this using native LV functions: Of course you need to create two temporary files, but this is year 2020...

Ah Ah ! I had noticed this "non working scrollbar" thing for a while, but couldn't find the time to investigate the nature of the problem. I had also figured that the mouse wheel worked, and indeed I play with the visibility as you do. Thanks for nailing it. Now write the simplest standalone VI you can that demonstrates the problem and please file a bug report with NI (https://sine.ni.com/srm/app/newrequest), answer the questions of the engineer who will contact you and let us know when you get a CAR number. Or if that is too much to ask, let us know and I will do it (you will need a current SSL to be able to file a support request). As Hoovah said, Graphs are bug-ridden and have for eons and with NXG around the corner decade future, I wouldn't hold my breath for a fix. But who knows...

There will be Ph D thesis written on the Boeing MAX debacle. I am starting to wonder whether there will be, regarding the NXG one, if no insider information ever leaks out. In the meantime, some food for thoughts: https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22

Absolutely. I'd be interested in examples of good open source practice for G code. My feeling is that there should be some way to visualize the diagrams as PNGs (not necessarily snippets) for those not having access to the proper LV version (or LV period) to be able to "see" the code. Last time I checked, the "print" diagram function of LV was useless for that purpose.

Luckily the context of the emails they were embedded in made it clear and pointed this out to the overly graphically oriented. But thanks for checking.

Dug up from the info-labview mailing list... on April 1, 2011 (can't make this up): Keep in mind that at the time of its disappearance (at least from public eyes), LabVIEW Web UI was in par with ~ LabVIEW 3.1 (no undo, no event structure, etc. for instance). It would be very instructive, from an historical perspective, to have an insider's view of NI's development plans at the time (2011 and before) and how this unfolded up to now, with this bizarre "perpetual alpha" release strategy of a development product supposed to replace a flagship product, which itself is not officially discontinued, but in practice will have little bug fixes or added features. In fact, from a sociological perspective, it would be interesting to have an idea of who is leading this effort, as I have a hard time admitting that NI can find enthusiastic young developers working on somethings that is so painfully uncool. Somewhat premonitorily, the same newsletter contained these two links (found on the Wayback machine): https://web.archive.org/web/20100406005233/http://www.ni.com/news/releases/april0701.htm https://web.archive.org/web/20110402173747/http://www.ni.com/news/releases/april1101.htm You can 't help but wonder what will pop up when the next time capsule will be opened in 2036...

The IDE was in fact pretty much here when NI launched LabVIEW Web UI: https://www.youtube.com/watch?v=RiY35znIdUg which used Microsoft Silverlight. Since that must have been in the making for several years before it was released, this is more like 10+ years old. Does the IDE look 10 years old or older? The fact that pretty much every traditional LV developer feels horrible pain at the mere look of the IDE is saying either we are all hopelessly outdated or indeed the IDE is a step backwards in terms of nimbleness (agility?). The IDE should be modular, since the underlying code itself is not. In fact, it should be open, offering the ability to third party developers to hook their tools and customization. I am not particularly depressed anymore at the unfolding of this slow motion catastrophe, and in fact I am even willing to believe NI that indeed there is a new crop of developers who are going to prove us all wrong. But right now, this is not the direction we (academia) are going. We want openness (for reproducibility purposes), we want flexibility, customizability, and we are certainly not going to have our users pay runtime licenses for toolkits simply implementing public domain algorithms. I am still much more efficient at programming in LV, but there is zero incentive for me to choose NXG over Python at this point, based on my 25 years of dealing with NI.

The problem with LabVIEW is, they send you a mug, but they don't make the kool-aid resupply free. And unfixed bugs after 2 decades get old, literally (my mug is fading though, which makes it "NXG", I guess). The really exciting prospect is all these brand new bugs which will never be fixed, yeah! Bottom line though, none of my students or colleagues will touch it with a pole if they can avoid it, and NI hardware products can be interfaced with MATLAB and python anyway, so why bother?

OK, my vision is in a state of exponential decay. For my defense, the second diagram shows DBL, as far as I can tell.

I am not sure what you are saying: your code shows exactly what the blog post (and the linked Stack Overflow thread) is saying. The machine epsilon's definition is clear about what it means. It is not what you are looking for, granted, but that was not the part I was sort of meaning to focus on in the blog post. Sorry about the confusion. The VI below does essentially was McNally talked about in his blog, and you can see that for a Numeric input of, say 1E-34, you get a next step of 2.138211768073757E-50, so your next step DLL is fooling you (or is it?) if it reports 1.4...E-45 as the next value after 0 (obviously, a Numeric value of zero will not get you any useful answer).

This blog post: https://devs.wiresmithtech.com/blog/tag/labview/page/2/

Works nicely, except that if I input 3 lb/min, I get 22.679618 ms^-1 kg. ms is not a SI unit.

What happens after December 31, 3000 at 4 PM though? (timestamp value 34618060800 = x80F65B000 = b100000001111011001011011000000000000)?

Seems to work except that it will basically strip the unit from the number, which probably should be documented. I would "expect" a "united" numeric to result in a string with the unit label appended. <OT> I had to check what "Cast Unit Bases" does, as I never used it before. The help is quite unique in its warning: Essentially, if no unit is provided (as is the case in the new Scalar to String.vim), it takes the input and drops the unit (after conversion to the SI unit). The conversion is weird, as illustrated in the attached VI (Control with unit to Cast Unit Bases): I copied the first control and changed its unit: the result after Cast Unit Bases appears the same... ????? But it also allows you to transform a value in oz/min into one in liter... assuming that you have an indicator with the proper unit to collect the output. I am kind of at a loss as to what this was designed for (turns out to be useful for the VIM, bit other than that?). </OT> Control with unit to Cast Unit Bases.vi

Try typing s^-1 in your control... Or mi/s/Hz... This is the power of units. Not mentioning a convenient way to check the dimensionality of a formula (but that's because complex formulas in G tend to explode into spider webs quite quickly, unless - as one should do - one switches to the text alternatives where G does a poor job of visualization).

I do like units for UI. If my users want to use MHz rather than kHz, or ps rather than ns, I do not have to worry about any fancy UI gimmick. It works (it even will not let the users change the dimensionality of the unit of a control at run time, which saves me the headache to fight against mischievous or distracted typers). They are clearly out, for the worse in my opinion. As we all know, units have never been an issue in major earth-based engineering projects... As for why the x^2 and Quotient and Remainder, etc., "incompatibilities" were never fixed, NI has always had the convenient excuse that they were understaffed, had other priorities, etc. I wouldn't be surprised if the same pattern reproduced itself with NXG.

These comments are all right. Most users will only see the VIM though, which is what my warning was about. Feed a unit-scalar to a VIM? Better check whether the different cases in the VIM are equipped to handle it properly.