X___

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.

1 hour ago, hooovahh said:

Also you do know those last two links are April fools jokes right?

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):

Quote

> Without hijacking the discussion, I wanted to jump in and make a couple of
> points in response to Vito's comment on Silverlight. Despite recent
> (mis)statements by a (former) Microsoft executive, Microsoft is not
> abandoning Silverlight. In fact, Microsoft is investing heavily in this
> technology, but also recognizes that it can't ignore HTML5. In the end,
> Microsoft will support both and let developers decide which to use given
> their different strengths and weaknesses.
>
> With respect to HTML, this "standard" technology is still (will likely
> remain) a moving target. HTML support is is implemented differently in
> every browser and across versions of the same browser from the same
> vendor. One of the key advantages of Silverlight is that an application's
> user interface will be consistent on every platform where it is viewed.
> However, the fact that Web UI Builder currently outputs Silverlight
> applications doesn't mean that NI does not have an interest in HTML or
> that long-term NI wouldn't support generating HTML code. We just released
> the very first version of Web UI Builder and anticipate that we will be
> adding features to it for years and years to come.
>
> Best regards,
>
> Mike Neal
> Senior LabVIEW Product Manager

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 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.

11 hours ago, LogMAN said:

http://www.ni.com/product-documentation/7900/en/

"LabVIEW 7.0 or earlier used a 64-bit double (DBL) to represent time, yielding 15 digits of precision. The number of seconds between 1st Jan 1904 (the timestamp Epoch or year zero) to 1st Jan 2000 is 3027456000. Representing this as a DBL would use 10 out of the 15 digits of precision. That leaves a very small resolution space to perform hardware timings using most of the resolution by simply going from 1904 to today.  Representing time as a DBL was not ideal since it did not meet industry requirements."

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.

I understand that NXG dropped units, is bug free and makes programming easy for those who will still need to program when it will be finally ready.

Not that I could care less, but VIM, which were introduced in ODG (old gen) are challenged by them (this is of course not the only problem with units, but VIM being recent, this problem is).

Take the scalar to string.vim that comes within vi.lib\Utility\Debug Log.

If you feed it a numeric, it will work fine and spit out a string reflecting the value fed in.

If you feed it a numeric with unit, it spits out garbage, as the cases in the VIM do not know how to handle units.

Instead of treating the culprit as a "all other types not handled by the first few cases", it recognizes is as... a timestamp:

The point is not so much that scalar to string.vim doesn't work as expected, but that you need to take this into account if you are writing VIMs and plan on using them with scalars with units (or any structure containing those), as they will not be recognized by the cases you will have written for scalars (which is how I discovered the problem).

Some will say: well, obviously, since a scalar with unit is a different type than a scalar without. Shall the all-knowing among us be praised!

I will argue that:

- since VIM will in general have a garbage collection case, a scalar with unit might look like it is treated correctly by a VIM you do not check the internals of, but in fact will spit out garbage. Could be tricky to debug.

- units are part of ODG, and the current VIM concept doesn't make it easy to handle them generically. Is it an easy thing to do? Maybe not.

Anyway, programmer beware.

No interest in NXG from this neck of the woods would be the feedback to the Powers that Were.

I believe a LabVIEW Jupyter kernel is out of the question without NI involvement.

And it wouldn't address my use case, as I would want users to work with data in python.

Moreover, I would for instance lose access to all the parallel job tools that I have access on my local cluster supporting Jupyter notebooks 🙂 

1 hour ago, ShaunR said:

Um. Can't we?

If you select the objects on the front panel and press the "Reorder" button in the toolbar. There is a "Group" option. That will group the selected controls and you can move them around as one unit.

Maybe I'm just misunderstanding what you are asking.

Sure. But then you cannot move the elements independently. Unless you ungroup, move, regroup.

A modular object (such as a Graph) should be moveable as a whole, but its components should ideally be moveable individually. I have no idea how NI does that with their native controls, but this is obviously feasible. This is for instance something that was completely destroyed in XControls (an XControlled-Graph is frozen solid if I recall my now forgotten attempts to expand Graphs, unless you rebuild the whole independent component grabing and moving, as I was told by NI).

On 4/23/2019 at 6:23 AM, shoneill said:

You might want to get in touch with Wiebe for that....

just forgot to add that my comment about the lack of flexible grouping in LV referred to edit time behavior, which Wiebe's tool doesn't cover.

Basically, we need to be able to group objects so as to be able to grab them and move them around as a whole (at edit time), but also be able to grab one inside the group and reposition it (ability which most graphical software provide; not sure about NXG). Essentially what one can do for members of a cluster, without the drawback I was illustrating above.

I thought it might be helpful if I clarified my use case.

Most of my development is LV-based, but I can hardly find anyone interested in working with that code (proprietary language, expensive, graphical, etc.) therefore, in order to be able to share and make what I do expandable by others, I need to interface it with something that is exactly the opposite. Jupyter notebooks are that thing today. What I am looking for is:

1) a way to send markdown text and graphing instructions to reproduce plots generated in LV (or plots that can't easily be produced in LV) in the Jupyter Notebook. The goal is to replace a custom-designed Notebook I based on a .NET rich text box control, which works fine, but is not interactive.

2) a way to pass data structures generated in LV (which the user will have extensive documentation about) to the Jupyter Notebook so that the user of the Notebook can do some processing on their own.

3) a way to send instructions (think custom scripting language) and data to LV.

Point 3 is to some extent covered by your tool, as long as LV polls the kernel (and knows which variable to look for). Whether or not a better communication protocol (with user events?) can be designed is up.

Points 1 and 2 are pretty much the same thing, the only difference being that 2) might involve bi-directional communication (LV sends data that is processed in the Notebook, which then sends back the result (see Point 3). The original use case, however, is merely to provide data for the user to do whatever they want with.

A big unknown to me is whether it would make sense to have access to the Notebook structure within LV (cells, history, data).