Dataflow_G

I posted an idea on the idea exchange on viewing a vim's instance VI, but it looks like that ability was added to LabVIEW at some point (by AQ?). The labview.ini token allowOpenFPOfInstanceVIs changes the behavior of the Convert Instance VI to Standard VI option to instead open the instance VI. I'd been using the convert to standard / ctrl+z method but it's very easy to forget the ctrl+z bit. This token is much more useful.

Is working with the image data as a contiguous 1D array, rather than a 2D array an option? I wrote a small image library for LabVIEW (G-Image), and found working with 1D arrays of image data consistently faster than 2D arrays.

Attached is a quick version which performs the per item + row methods using a 1D array, and both are quicker than their 2D counterparts.

Raster 1D 2015.zip

Here's a couple more promotional videos recently unearthed.

NIWeek 99 Highlights:

NIWeek 2000 promotional video, with invitation by Dr. T:

2 hours ago, Łukasz said:

That fixes the problem and the basic functions ZMQ LabVIEW library works.

Thanks for confirming its working 👍

The problem looks to be zmq_labview.c is calling functions in the zeromq library which are specified as draft functions, and are disabled in stable release versions. These functions are listed in the compilation output as implicitly declared, and when configuring the CLFN in LabVIEW, it throws a warning it can't find them. This is likely the cause of error 13.

If you check zmq.h, it has the following comment:

/******************************************************************************/
/*  These functions are DRAFT and disabled in stable releases, and subject to */
/*  change at ANY time until declared stable.                                 */
/******************************************************************************/

#ifdef ZMQ_BUILD_DRAFT_API
...
/*  DRAFT Socket methods.                                                     */
ZMQ_EXPORT int zmq_join (void *s, const char *group);
ZMQ_EXPORT int zmq_leave (void *s, const char *group);
...
#endif

If -D ZMQ_BUILD_DRAFT_API is added to the compile flags, the implicit declaration warnings are no longer present. But you still have the problem that the stable release of zeromq doesn't have these functions available. So you'll either need to find and install a draft release (these don't appear to be pre-built for Ubuntu), compile it yourself with draft APIs enabled (possibly using -DENABLE_DRAFTS=ON), or replace the functions from the draft spec in zmq_labview.c.

There's a couple of videos on NI's youtube covering new hardware and software products. They're both heavy on marketing and light on details, but put things like TestScale into context.

Hardware: https://www.youtube.com/watch?v=-8VGCjzJjWk

Software: https://www.youtube.com/watch?v=hH8VFB9jtzM

Edit: That ShireyStudios youtube account also uploaded some new NI Connect videos in the past couple of days. Did they manage video recording of the event? Kinda surprised the vids aren't on NI's main account.

21 hours ago, drjdpowell said:

@AQ,  I've incorporated most of your improvements, and made some changes myself.   Question, though.  These VIMs seem plagued by (in LabVIEW 2020) strange recompile bugs: broken wires that are usually fixed by doing a manual force recompile on the VI.  Though often this still leaves some broken wires in a runable VI?!?  See image.

What do you think causes this and is there a way I can avoid it?  

I can't speak for the buffer library, but I've observed this behavior many times with malleable VIs in my own code. One thing (bug?) I've noticed (and reported on the dark side) is that nested type specialization structures within a vim can lead to broken wires. This is generally as a result of an assert vim inside a type specialization structure inside a vim. The callers wires are either visibly broken but otherwise runnable, or just broken even though the input types are supported.

The LabVIEW 2021 SP1 bug fixes mention a fix (bug ID: 1596011) for vims and erroneously broken wires, but I've not tried it out yet. I really hope that's the end of the broken wire quirks with malleable VIs, as they're a really great feature.

6 hours ago, flarn2006 said:

• The audio input/output VI's don't work, instead saying the selected device is invalid. (This does not include the audio file ones, which work as expected.) Trying to place an "Acquire" or "Play Waveform" Express VI shows no detected devices in the dialog, and if I click OK anyway, LabVIEW crashes.

Yeah, LabVIEW's Linux audio support hasn't been touched in years. It's built on OSS, which was superseded by ALSA on Arch Linux in 2002. None of the Linux distros LabVIEW Community Edition supports ship with OSS support, but I believe it can be added via an ALSA-OSS translation layer. Also worth noting LabVIEW for Linux can only write 16-bit WAV files, and not IEEE float WAVs (which can be written in LabVIEW for Windows).

If you want to play/capture/record audio under Linux, I'm working on an open source, cross-platform audio library for LabVIEW called G-Audio. It's been tested under Arch Linux and CentOS, and supports playback and capture on ALSA and PulseAudio backends, supports writing PCM / IEEE WAVs, and can read WAV, MP3, FLAC, and Ogg Vorbis files.

Sounds like a cool project, especially with a real 6502 thrown in. I remember seeing an open source Apple II emulator written in LabVIEW: https://sourceforge.net/projects/labviewapple2/ Not sure how well it runs, but might be interesting to compare notes.

The diagonals need to be in the form:

[0,1]
[1,0]
or
[1,0]
[0,1]

The 'M' only has a single pixel, or three pixels in a 2x2 grid area, so the anti-aliasing isn't applied. Not sure why it has been implemented this way.

It looks like the picture control is trying to be smart, and anti-aliases diagonal pixels of the exact same color. If the colors differ by a single bit, the anti-aliasing doesn't occur:

The picture control also does some kind of pixel hinting - try resize the picture control when the zoom factor is high. You can see it snaps the pixels to some hidden grid in an effort to align it to the picture control bounds. I don't see any properties for disabling the anti-aliasing or the hinting.

Perhaps a 2D array of color boxes could be used? With the classic controls there's no gaps between elements:

Saw this example code - LabVIEW programmers should feel right at home

Just saw Nintendo announce this programming game, and a few comments comparing it to LabVIEW. It looks pretty cool, and a fun intro to graphical programming. I don't have a Switch, otherwise I'd probably pick it up.

https://www.nintendo.com/games/detail/game-builder-garage-switch/

To add to the list of potential red flags:

• Windows Registry Access VIs
• VI Scripting calls (deleting or subtly modifying existing project code)
• Large VI file sizes / large constants (malicious VIs stored as byte arrays, so avoiding VI Analyzer's checks)
• Bugs known to crash LabVIEW
• Shortened links in VI help
• Non-standard block diagram colors (hiding a subVI on an identically colored BD)
• Obfuscated code (strings masquerading as boolean arrays, numbers with hidden precision, etc):
  • 
• Very small subVI icons (think a VI disguised as an error wire, as seen on reddit😞
  • 

In reality flagging a package based on any of the previously mentioned criteria will be almost exclusively false positives. Perhaps providing a list of function types a library uses would better help the developer assess the library, similar to the app permissions shown when downloading an app on iOS / Android. So a library may use Network, Scripting, and File System. As LogMAN said, it's ultimately up to the developer to take responsibility for the code they use.

obfuscated_LV2014.vi

Here's some more rebrand info I found by one of the design companies behind NI's rebrand, including a mock-up of a green PXI with an interesting font choice (I'm pretty sure that's a Q).

3 hours ago, Aristos Queue said:

I liked it in theory, but I'm seeing a bunch of warnings online about Stylish having become malware that is shipping private information to third-party. You might want to investigate.

There is Stylus which is a malware / analytic free fork of Stylish.

BTW, did your avatar succumb to the rebrand too?

4 hours ago, Mads said:

We might as well loop back to 2017 😉

The very first comment in that thread is interesting.

Quote

I just downloaded and installed LabVIEW NXG.  At first I thought I installed LEGO NXT by mistake...

It's no coincidence NXG looks like LEGO Mindstorms NXT. There was an R&D project in 2009 called LabVIEW Notebook Pioneer. You can see it here - video 1, video 2 and a screen cap:

It looks like a very early NXG concept (single window, panes, docked palettes, data stored with project, etc). What's interesting is Christina's comment in the linked blog post.

It would seem NXG's roots were partly influenced by NXT. Not saying it's good or bad, just interesting that it was picked up on.

Hmm, it seems the difference in resolution of primary vs secondary displays is being added to the maximized window on the secondary. In this case it's a difference of 640x320 ( or 2560-1920 x 1440-1080). If those numbers are then subtracted from the window bounds when the title bar isn't visible, they're within 1px. Looks to work for your resolutions and results too @nikp. Might be a better solution than toggling the title bar.

I'm seeing the same issue as @nikp, where the window bounds for a maximized window on the second display are way off. It looks to be related to whether the title bar is visible or not.

There are two displays in a side-by-side configuration, the primary is 1920x1080 and the secondary is 2560x1440. Running under Windows 10 with display scaling off.

I tried the examples posted in the thread @LogMAN linked to with very different results. @hooovahh's version worked for both displays, while @Aristos Queue's version only had correct results on the primary display. After trying to work out why they were so different, I noticed the title bar visibility was different between the two examples. The snippet below demonstrates the different results.

When the front panel is on the primary display, the bounds only differ by one pixel when title bar visibility is toggled. When the front panel is on the secondary display, difference between the Right and Bottom values is huge.

Calling GetWindowRect() and GetClientRect() from user32.dll on the front panel window has the same results when toggling the title bar visible, so it looks to be a Windows level issue rather than LabVIEW.

In any case toggling the title bar visible works well enough. Not sure if it will help your application @nikp.

Out of interest, what are the MD5/SHA1 hashes of the problematic lvanlys.dll? I have a LV2019 SP1 64-bit install (via NIPM, not the offline iso), and analysis functions are working. The copy of lvanyls.dll I have match the file size and modification date in your screenshot. Its hashes are:

MD5: 8b57b1ab47c00387b370d3d0fac0a246
SHA1: 7d45297d3e1d10f1de5960c116c58b7dc186fd2e

Some more LabVIEW from the past, this time from The Minnesota Apple Computer Users Group newsletter, mini'app'les (December 1989). "Hubba, hubba, hubba!"

Mini'App'LesNewsletter1989-12.pdf