Sparkette

On 12/24/2023 at 2:24 PM, Stagg54 said:

And we wonder why LabVIEW is losing out to tools like Python..

Even if LabVIEW didn't have this glitch, FOSS programming languages tend to be more popular anyway.

On 12/28/2020 at 8:24 AM, Mefistotelis said:

Baba is you is a great game for kids.

He probably already has some favorite games, and many games today use LUA. So he could also start modifying a game he knows using LUA scripts.

It's worth mentioning that Baba Is You uses Lua as well. (It's not part of the gameplay, but mods can use it, like you said.)

I have LabVIEW 2020 Community Edition installed on Linux, and when I run it, I get the following popup:

So I click "Activate LabVIEW Community Edition", and it opens a web browser to a page asking me to log in to my NI account. I do, and then it takes me to a page saying "You have been authenticated. You may close this window." But LabVIEW itself tells a different story:

The strange thing is that the "You have been authenticated" page says 127.0.0.1 in the address bar, meaning the message is coming from my own computer rather than NI's website. So you'd think it would match what LabVIEW says, but nope.

I'm pretty sure I already tried redownloading LabVIEW Community Edition and it didn't work. Anyone know how to fix this?

5 hours ago, Rolf Kalbermatter said:

I would guess that it uses the standard MgErr codes: 5 - file already open, 8 - permission error which might be a follow-up error, 6 - file IO error which means that something happens during reading or writing of a file that the programmer is not finding another error to map it too.

Those don't really make sense considering what I did though.

The main reason I'm asking is VIPM for Linux is out of date and requires an old version of the LabVIEW runtime, which it somehow doesn't detect even when I put it in LD_LIBRARY_PATH. I've had issues getting it to work on Windows in the past too, and I'd rather just use a different, less cumbersome tool to install them if possible. Plus it would also be nice in general to have an open-source alternative to such an essential tool.

As a side note, I'm pleased to see that you find my resource editor useful

I'm trying to make a simple, compact, square Boolean constant to put in an array so it looks like a grid of pixels, using XML heap editing black magic. The most significant change I made was converting the multiCosm to a bigMultiCosm so I could color each state separately. It ended up failing to load the block diagram. This isn't a surprise, as I am after all changing data in ways it wasn't necessarily designed to handle, but it did get me curious about what the exact error was, since who knows, maybe it was something I could fix. So I turned on dprintf_logging (in Ned) and tried it again, and this was the output:

LoadObjectData error 5, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 113, tag 'table' (256), dpid 0
LoadObjectData error 8, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 111, tag 'partsList' (194), dpid 79
LoadObjectData error 8, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 104, tag 'ddo' (52), dpid 19
LoadObjectData error 6, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 110, tag 'dco' (48), dpid 21
LoadObjectData error 8, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 7, tag 'termList' (268), dpid 29
LoadObjectData error 8, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 3, tag 'nodeList' (164), dpid 27
LoadObjectData error 8, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 2, tag 'root' (214), dpid 126

I'm guessing the answer is no, but is there any public documentation of those error codes?

12 hours ago, dadreamer said:

Also to note for your VI.

1. Looks like UID to GObject Reference.vi is giving away a duplicate reference instead of the original one.

Hence it should be closed explicitly with Close Reference after the work with it is done.

2. UID to GObject Reference.vi is not working in RTE. The Context Help for it has the related remark and even though the underlying UidToObjRef function is present in lvrt.dll, it does nothing.

So, for RTE another way should be found.

3. Icon picture of Pointer to Refnum.vi doesn't reflect, that reference, not pointer, is outputted. BCJ is not used here as well. Maybe, something like " @ # " should fit more or less ok.

1. I thought references to GObjects didn't need to be closed.

2. I'm not concerned about RTE; my interest is for use alongside VI scripting, e.g. for doing low-level editing operations in a shortcut menu plugin.

3. Noted, thanks. I just copied your icon and didn't really consider what it meant.

1 hour ago, dadreamer said:

For 32-bit system you should add 8 bytes to the pointer instead of 16 to read out the UID. Check my test sample from here. Anyway it mostly matters for Windows, as both Linux and macOS are 64-bit nowadays.

Thanks; I'll update it when I get the chance.

EDIT: Done. I also wired the error in/error out terminals, since I apparently forgot to do that before.

7 hours ago, dadreamer said:

Then maybe try some third party dialog libraries out there, e.g. osdialog or Portable File Dialogs or Native File Dialog / Native File Dialog Extended , there are thousands.

I'm mainly concerned about LabVIEW's built-in uses of the file dialog, File→Open for example. Is there a simple way to replace that with a call to a third-party library?

Here's a simple VI I made that does the opposite. This one should be cross-platform, though I've only tested it on Linux. I enabled maximum error checking on the MoveBlock CLFN, but I've found it can still crash LabVIEW if the pointer is invalid, so keep that in mind.

Pointer to Refnum.vi

5 hours ago, dadreamer said:

All the new snippets from here don't work for me. Tried in three browsers. I don't know, whether anyone else experiences the same. I guess, that thread relates to this issue: 

Old snippets still work fine though, for example this one.

CURSED.viTry that. I added more stuff to it, including that.

On 1/5/2021 at 9:17 AM, dadreamer said:

Finally here it is.

Refnum_to_Pointer-Linux.zip 41.9 kB · 1 download

Refnum_to_Pointer-MacOS.zip 37.29 kB · 1 download

Tested in LV 2020 on Ubuntu 20.10 and macOS Big Sur. It's assumed to work in 64-bit editions of LabVIEW only.

Forgot about this! Just gave it a try, and I can confirm it works on LabVIEW 2021 on Arch Linux. At least as far as I can tell from my initial test.

Would this work with Conditional Disable Structures so a single version can work in every OS?

#define true false
#define false true

Behold, my latest creation...a triangular constant!

8 minutes ago, Dataflow_G said:

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.

I see. Running LabVIEW through padsp appears to fix it, except the express VI's still crash LabVIEW when I click OK. Thanks though

39 minutes ago, Jordan Kuehn said:

Perhaps this same issue that is a bug, per AQ's reply:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/LV2021-Deactivate-Wire-Auto-Routing/idi-p/4183557

Looks like it; thanks for the link. Guess that one isn't Linux-specific. Though there aren't that many days in January left...

1 hour ago, hooovahh said:

Thanks for the info. LabVIEW Linux doesn't get much love.  Combined with the large variation in Linux environments can mean issues like these.  Can you post this on the dark side?  Is there a Linux desktop sub forum?  If not sending these to NI as a service request would also help.

When I do, is it okay if I just link to this thread here?

You know, like when you right-click it and select "Open Front Panel", and it asks you if you want to convert it to a standard VI. This seems to do the trick, but since it uses a private method I thought maybe I should ask here in case I'm doing something unsafe.

I love that Community Edition is on Linux now. That said, I've run into a few issues with it and I'm hoping someone can help:

• LabVIEW has issues with images from other applications in the clipboard. When I have something copied from KolourPaint (an open source MSPaint clone) LabVIEW will often crash, sometimes immediately, sometimes not until I try to paste it. (This happens immediately after launching it as well.) From other applications I've tested, LabVIEW appears to ignore the image entirely. If something other than an image was in the clipboard before the image, it'll paste that; otherwise, Paste will just remain disabled as if the clipboard were empty.
• A lot of times, I'll select a custom control using the "Select a Control..." right-click menu item, and it'll display the outline of the control for a split second, but then it'll go away as if I pressed Esc. I don't recall whether this has happened with subVI's, but it's possible. (edit: it just did, so yes.)
• Sometimes, often when I drag something on the block diagram, wires will suddenly move to illogical locations. One place where I've noticed this often is with tunnels on the bottom edge of a structure, where the wire will suddenly arrange itself so it connects from the left instead (while the tunnel remains on the bottom.)
• 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.
• Dragging and dropping files into LabVIEW does not work; instead, the files go to the window behind the LabVIEW window.
• I'm not sure whether or not this is actually a bug, but whenever LabVIEW opens a file dialog, it uses the crude built-in one, like in the Windows version when you select an LLB, instead of the normal system dialog. (If anyone knows of any way to replace the dialog with a custom VI, that would be great.)

I'm using Arch Linux with KDE Plasma, in case it helps.

On 12/28/2020 at 8:32 AM, ShaunR said:

But be careful what you wish for. The probable solution to the demands for free stuff will ultimately end up as LabVIEW-as-a-service.

You just had to say it...

Whoops, not sure how that string constant got there! And no, Basic Object Flags (AFAIK) isn't enough to do this; this was made through manual heap editing.

EDIT: https://static.needsmorejpeg.com/i/qaJ20.jpg

When I click "Go" on the YControl wizard, LabVIEW just sits there seemingly forever, all the while logging this error every second:

<DEBUG_OUTPUT>
01/27/22 11:52:33.767 PM
DWarn 0xFCC058F4: An item recompiled in the final iteration should not still have recompile needed set: [VI "Y Control Isolators and Misc.lvlib:Insert Info In Error.vim" (0x000000000a5b12a0)]
/builds/labview/2021/source/compiler/compiler.cpp(643) : DWarn 0xFCC058F4: An item recompiled in the final iteration should not still have recompile needed set: [VI "Y Control Isolators and Misc.lvlib:Insert Info In Error.vim" (0x000000000a5b12a0)]
[ExecSys:0; NOT InExec]

</DEBUG_OUTPUT>

0x00000000006D9611 - <unknown> + 0
0x00007FFFF6DDB5F5 - _ZNK11DebugStream7ProcessEv + 25
0x000000000064D329 - <unknown> + 0
0x000000000064D991 - <unknown> + 0
0x000000000064E1B8 - <unknown> + 0
0x0000000001D14136 - <unknown> + 0
0x0000000001D15369 - <unknown> + 0
0x0000000001D18333 - <unknown> + 0
0x0000000001D1AC85 - <unknown> + 0
0x0000000001DB393D - <unknown> + 0
0x0000000002032563 - WSendEvent + 253
0x00000000020339A4 - <unknown> + 0
0x0000000001F6BABD - <unknown> + 0
0x0000000001F658F8 - <unknown> + 0
0x0000000000608599 - <unknown> + 0
0x00000000006087A8 - <unknown> + 0
0x00007FFFF6802B25 - __libc_start_main + D5
0x00000000006069F9 - <unknown> + 0

I'm using LabVIEW 2021 Community Edition on Linux.

When is this necessary? FPGA I assume?

CURSED.vi

Open the block diagram and see for yourself. (Make sure you have everything saved in case LabVIEW crashes.)