-
Posts
3,905 -
Joined
-
Last visited
-
Days Won
34
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Jim Kring
-
-
Here's a new take
On 2/17/2011 at 11:01 AM, SteveChandler said:LVOOP is new ground for me but I am starting to understand it much better thanks to these forums. So the only thing you need the message name for is so that you can wire it into a case selector right?
This has me thinking of an idea for the idea exchange. What if you could wire the object right into the case selector? It would behave like a typedef with the ability to add a case for every value (child) and break if there is no default and you don't have a case for every value.
Would anyone out there kudo an idea like that?
Here's slightly different take on that idea
>> LabVIEW Idea: Enumerated Variant <<It works with, but is not limited to, classes. It's inspired by languages like Rust (enums) and Zig (tagged unions)
-
Thanks for sharing this. It inspired me to dive deeper -- I made a write-up here: https://create.vi/fixing-the-labview-icon-editor-on-linux-42e920743dc7
I've made some fixes to the LabVIEW 2023 Q1 Icon Editor and will share them once I coordinate with NI.
-
On 5/9/2020 at 8:02 AM, JKSH said:
That's what I meant by "write a bit more code"
It's not a showstopper though, especially since we can put that in a VIM.
Thanks for the video link.
there's a package such VIMs here: https://www.vipm.io/package/vipm_lib_labview_collection_extensions/
-
- Popular Post
- Popular Post
Adding a link to this new tool:
it is a thin wrapper around a popular Rust library that supports preservation of formatting and comments.
-
3
-
-
That's correct. The OpenG libraries have been migrated to the BSD3 license.
You can find links to the active repos here, which have updated license agreements:
https://github.com/vipm-io/OpenG -
Hi @KumarB
VIPM will let you download older versions of packages.
Here's what you may need to do:
- In VIPM's options dialog uncheck the option to only show installable packages -- this will show all packages, even if they cannot be installed into the current LabVIEW version
- In VIPM's package list file the package of interest and then right-click and choose Download Other version.
- After downloading, you can find the package file in the C:\ProgramData\JKI\VIPM\cache folder
- You can either install it with VIPM or change the file extension from .ogp to .zip and extract the contents.
Regards,
-Jim
-
2 hours ago, ShaunR said:
You only need a "garbage collector" to clean up garbage
It's an interpreted scripting language, with the heavy lifting done by C/C++, masquerading as a general programming language. It's also a lovey of the Linux world so expect ABI breaks often like with v2-v3.
In C/C++ *the programmer* is the garbage collector (at edit time) -- I'd rather have someone else take the trash to the dump for me 🤣
-
hey @jcstoke
I would stick with LV2020 SP1 at this point. There has been a LOT of grief around the wire auto routing behavior in LV2021.
Note: an active LabVIEW subscription will allow you to install older versions of LabVIEW (not just the most current), if you like. That's good, IMO, since it encourages people to both play with the new releases (and provide feedback earlier) and also stick with older and more stable releases when needed for production.
To your questions about PXI vs cRIO/cDAQ it really depends on a lot of different factors
Also, Python *really is* the s#!t. I probably spend as much time in Python as I do LabVIEW these days. They can play nice together, for sure.
-
Based on some conversations I had with Philippe about this, he's wondering:
If you have a VI reference at run-time, can you tell whether it is a static VI reference (via Static VI Reference node) or a dynamic VI reference (opened with the Open VI Reference) function, since the VI lifetimes (and lifetimes of references created within them) are managed differently by LabVIEW.
-
This bug has been submitted to NI and confirmed.
bug number 1289111
-
1
-
1
-
-
OK, here's a game plan I think will work to fix the issue, yet without changing the behavior of the code.
Since LV2009 (the version of LabVIEW the package is currently developed in) doesn't have the "Separate compiled code" feature), we'll implement a work-around by creating a special subVI to get the EOL that is not affected by the bug (Note: ignore the fact that the screenshot shows this VI open in LV2020).
We'll do this by calling the Array to Spreadsheet string function with empty string inputs. It appears from testing that this does not get constant folded (or at least is not impacted by the bug). And, we'll cache this value for performance on subsequent calls. It'll all be packaged into a tidy little sub-VI, so that it's obvious what we're doing and why.
I've released this as version 4.1.2.18.
Moving forward, we'll upgrade the sources for this package to LV2013 and mark all the VIs for "Separate from compiled code". We would have done that sooner, but there was a build issue in 2013, due to the fact that NI introduced a VI called "Trim Whitespace.vi" that shares the same filename and thus collides with the OpenG VI (in source code form before it's name mangled in the build process). But, that's a different story (and I think we can work around it during the build process)...
-
1
-
-
We've figured out more information.
The problem seems to go away if you turn ON "Separate compiled code from source file" for 1D Array to String
Meaning: the problem occurs when the compiled code is saved in the VI source file.
It would seam that LabVIEW is not correctly determining when it needs to recompile/save the VI when switching between RT and Windows.
-
-
2 hours ago, Rolf Kalbermatter said:
This is strictly speaking not equivalent to the originally intended implementation since this would remove multiple empty lines at the end while the original one only removed one EOL. However the Array to Spreadsheet String function should not produce empty lines (except maybe if you enter a string array of n * 0 elements) but that does not apply for this 1D array use case.
You're right, Rolf. I can see some situations where my proposed "fix" would fail -- if the last element(s) of the Array of Strings intentionally contains EOL characters at the end ["\t", "\r", "\n"]
Now, looking at the "1D String Array to Delimited String.vi" that got added to LabVIEW (I'm not sure which version), we see it has a similar implementation (although it doesn't use Match Pattern and simply removes the calculated length of the EOL at the end of the string).
I wonder if this VI suffers from the same constant folding compiler bug reported in this thread (I'm going to do some testing).
This all makes me wonder if we should be creating the delimited string in a more low-level way (instead of relying on the Array to Spreadsheet String function, which adds the EOL at the end).
Here's a simple solution:
And, here's a potentially more performant solution for larger strings:
Thoughts about the best approach here?
-
- Popular Post
Good news! There's a new release available on vipm.io with a fix.
https://www.vipm.io/package/oglib_string/#4.1.1.16
The issue
We were able to figure out what the issue is. It appears to be caused when using a NI Linux RT target.
The problem seems to happen when LabVIEW compiles/saves 1D Array to String for running on an NI Linux RT target. Then, when you open and run 1D Array to String on Windows, it isn't always getting recompiled correctly.
More Details
The current implementation of 1D Array to String uses an EOL constant (
) to build a regular expression -- the EOL is platform dependent (it's CRLF "\r\n" on Windows and LF "\n" on Linux and Mac).
My guess is that somehow the LabVIEW compiler constant folded the regular expression that is the concatenation of the EOL constant and "$" into "\n$" (match a Line Feed at the end of the string).
However, on Windows the EOL character we are looking for is a CRLF ("\r\n") at the end of the string. So, if we were searching for "\n$" at the end, the before string would have a "\r" at the end of it, which is what we're seeing (when the bug is happening).
Editing and re-saving this VI on Windows causes it to be recompiled and the regular expression get's correctly compiled and constant folded into "\r\n$"
A More Robust Implementation (work-around)Looking at that 1D Array to String code, I don't really love how it's building the regular expression using an EOL constant.
I think that a more robust solution would just build the regular expression as "[\r\n]+$" (one or more Carriage Return or Line Feed characters at the end of the string).
This would be platform independent and not suffer from the compiler bug we're discussing here.
There's a new release available on vipm.io with this fix.
https://www.vipm.io/package/oglib_string/#4.1.1.16
[Update] I've opened a service request with NI to dig into it some more. I'll post updates, once I find out more.
-
1
-
2
-
1 hour ago, bjustice said:
Sounds good.
38 minutes ago, bjustice said:Yes, we'll upgrade the sources to LV2013 (and separate compiled code on all VIs).
Let's do this, first, as a single, separate commit to git.Then, we can make the other changes.
-
2 minutes ago, bjustice said:
Hmmm... that was a long time ago
I'm not totally sure what the thinking was.
I don't see any problem renaming the enum value to "ByVal Class" (or similar).
-
I just looked at some statistics and I think it's safe for us to upgrade this library to LV2013.Can you try re-running your fixed point experiment in 2013.
-
Right, the NI Data Type abstracted away the type descriptor type codes and subtype codes.
Also, this is the original application note 154 on the topic.
-
Hmmm, 0x1E seems to not be listed in that wiki page either. Might be good to ping NI or @Aristos Queue about this.
-
-
Does this help?
-
Hi Brent,
I can work with you on this improvement. Yes, it's needed and past due.
I'll ping you off-line.
-Jim
-
1
-
We're going to miss you Kurt
in LAVA Lounge
Posted
It's with a saddened heart that I pass this news along, that we've lost a dear friend and LabVIEW Champion, @Kurt Friday.
https://www.linkedin.com/feed/update/urn:li:activity:7212115164492353541/
We will miss you, mate.