Neil Pate

Sorry I thought I had replied here, but it looked like I did not click Submit!

Thanks for everyone's comments. I have passed them on to my customer.

A bit more information.

According to the Dependencies application the LV2020 also has a dependency on this System.dll that is located in the GAC.

I have tried copying that DLL to various locations (I think I am not supposed to because this is system stuff!) but it still gives me the same error.

Recently I have tried to package up some code as a .NET Assembly. I managed to pack some pretty complicated LV2019 code (including some LabVIEW classes and dynamically called code) into an assembly and was able to call it just fine from a simple C# console application. However, this does not work when I moved over to LV2020.

To make things simple to try and get to the root of it I created the simplest possible example I can think of. One copy is in LV2019 and it works fine, the other is LV2020 and it does not work.

The assembly builds fine in LV2020, and indeed is callable from LabVIEW code. The test is just a simple Increment VI.

This works fine when the assembly is built using LV2019, the num variable is correctly 2 after running this line of code.

However in LV2020 I get the following exceptions after running that line

System.TypeInitializationException
  HResult=0x80131534
  Message=The type initializer for 'MyAssemblyNamespace.LvClient' threw an exception.
  Source=Increment2020
  StackTrace:
   at MyAssemblyNamespace.MyTestClass.Increment(Double input)
   at Increment.Program.Main(String[] args) in C:\dev\Scratch\DLL Build Test (2020)\Source\C#\Increment\Increment\Program.cs:line 10

Inner Exception 1:
FileNotFoundException: Missing Dependency in:

Inner Exception 2:
VIAssemblyException: Missing Dependency in:

I have tried playing around with including the LabVIEW Interop assembly in the C# application (C:\Program Files (x86)\National Instruments\Shared\LabVIEW Run-Time\2019\NationalInstruments.LabVIEW.Interop.dll) and changing this to 2020 for the LV2020 version, it does not seem to make any difference.

The LV2019 version runs without this assembly included in the project.

Is this something to do with the GAC? This is now getting into the details of .NET that I am not really very familiar with.

Does anyone have any tips for things I can look into? I have attached a zip of everything for anyone curious.

Build Test.zip

One of my old customers is having an issue with the TSM-1017 losing its ability to be calibrated. The system runs on a cRIO and the screen is attached with a USB cable as well as the DVI cable. On Linux RT there is an application you can run that brings up a four point calibration, but apparently this application does not run anymore.

This did all work once upon a time, but the system has been out of my hands for a very long time.

NI support gave some very manual linux-ey commands to reinstall drivers or something, but I do not think this worked.

Has anyone come across a situation like this before?

https://meh.com/forum/topics/building-the-plane-on-the-way-up

tl;dr the ground based decoder for some of the comms on Voyager was built *after* the craft was launched, and it still to this day reliably receives data. Wow!

Posted here: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/idb-p/labviewideas/tab/most-recent

There is a video linked in that post that pretty simple shows the behaviour. It is quite nice to use.

If you like it please add your kudo on the Idea Exchange!

6 minutes ago, Rolf Kalbermatter said:

No, but without a legal license for NI-LabVIEW Realtime Runtime and all the various NI-other software, it's a complete nogo for anything else than your home automation project.

Exactly why we need NI to buy in to the idea, otherwise it will never get off the ground.

20 hours ago, hooovahh said:

I searched and couldn't believe I couldn't find an idea on the idea exchange for this so I made one here.  There is a related idea of having a VM of the Linux RT environment, and some comments in the post outline how to do this.  Using the method described you can have Linux RT on a desktop, but there is no support from NI, and in my experience network driver support is limited.  It is also a licensing issue as others have pointed out, since NI's drivers aren't licensed for this unofficial hardware even if the kernel and Linux core is less restrictive.

Excellent idea, I have added my kudo! I don't think this will get much traction from NI but it would be really nice to see this as something semi-official.

Once you know what you are doing it is not super complicated to get RT linux running on a desktop.

I have created some code that allows me to translate the GUI language on the fly at runtime. Is anyone else interested in this? At the moment it is a bit coupled into my actual application but I think I can extract the relevant bits.

It supports pretty much any latin codepage language and once upon a time did also support Chinese (but I have not tested that in quite some time).

Obvious disclaimer here: I just want to share what I made, but use at your own risk, and I am definitely not a UTF8/16 whatever expert so there might be some stuff that is just plain wrong.

2 minutes ago, LogMAN said:

You could create a custom git hook to push local changes on every commit but you are probably better of with a different VCS.

I am not *that* paranoid, but certainly I like to push my work at the end of each day. I am not actually anti-git, it is just taking me a while to get used to its best practices and nuances. 

I guess what I mean is I find it strange that people would even have local branches that are not pushed to the server. Maybe I am just paranoid about my house burning down, my computer getting stolen of my hard drive dying. For me one of big benefits of cloud based VCS is that I almost always have an up-to-date geographically distributed copy of my code.

The thing I still find a bit strange is how it is possible for the remote and local branches to be totally different (even different names). I totally get that the local branch can be out of sync if you have not done a push/pull to the server, the thing that seems weird to me is that the local can have a totally different structure. This is just something I need to get used to.

This morning I finally realised why I semi-regularly get into a detached head state (I think I know why...).

In git there are several different options for checking out a commit (checkout commit, checkout branch etc) and I never really paid much attention to the subtleties of these. As far as I thought they all did the same thing, that is revert the local code to the state of that commit.  It turns out that my understanding was flawed, and every time you check out a single commit (rather than the actual branch) the current state will not point to any particular branch and you will be in the detached head state.

I find this a bit weird, as I presumed if you checkout a commit in say the middle of a branch somewhere you would still be on that particular branch. Checking out a branch will always checkout the latest commit of that branch.

This article explains it nicely.

I have not been too scared of detached head for a while now as I know it can be easily fixed just by making a new branch, but it is nice to know why this actually happening.

Happy gitting!

(next step in my git mastery is to understand the subtleties of local and remote branches).

I use InnoSetup for a custom installer and I also install the 2019 runtime this way.  It may not be the "right" way to do it, but the way I solve this problem is to manually extract the runtime installer and then just include that directory in my installer and run the Install.exe from the installer.

I think LabVIEW is going to be around in some form for at least another ten years, primarily due to how entrenched it currently is in the niche it fills. However, if I was starting my career again in 2021 I would definitely not choose LabVIEW as my primary language of specialization. I think the poor decisions NI have made over the last ten years will lead to its irrelevance/obsolescence, which I am genuinely saddened by.

It pains me to think where current gen LabVIEW could be if the money and time funneled into NXG had been put to overhauling current gen.

9 hours ago, X___ said:

I just spent a whole day setting up a VM and installing an older version of LV with the right toolkits and driver versions needed on my deployment machine because... versions and toolkits are incompatible and exclusive from one another. 10s of GB most of them useless for my purpose.

Awesome.

I didn't say perfect...

Being able to drop pictures on a block diagram is so amazing.

I tried with a longer row replacement, 6000 elements, and the MoveBlock technique starts to become marginally faster.

I am going to stick with the simple replace an element at a time method.

1 hour ago, dadreamer said:

I did a test like yours with For Loop and MoveBlock is a bit faster here. I'm getting 0,03 ms for RAS and 0,01 ms for MB.

I took Initialize Array on MB diagram out of the Sequence, because it's just an extra operation. Also make sure you are not timing and filling the output indicator simultaneously, because the latter vastly impacts the measurements.

It really makes sense to me to have the MoveBlock be the fastest when replacing a row (or subset of a row). I wonder if the difference is also more exteme as the size of the replacement changes? In other words replacing a section 1M elements long is probably much slower when doing it element by element compared to a single MoveBlock call.

2 hours ago, dadreamer said:

Only when I disable the wrapper generation on the CLFN, I see some small performance gain in MoveBlock against Replace Array Subset:

So, in all other use-cases the native nodes do their job just fine and they're much simplier to use (and more safe also). That is just a PoC method to show, that the work with arrays could be done "traditional way" in LabVIEW too as in text-based languages. I even suppose, Replace Array Subset and In Place Element Structure were both optimised/tweaked in some ways to behave better even in a dumb memory copying.

Sure, but I am surprised that looping over an array doing individual array element replaces is quicker than doing a single MoveBlock! Seems suspicious...

In another plot twist it looks like my original naive method of just doing a for loop is actually quicker than the MoveBlock. I do not really understand this but am going to leave it here for now.

Method 3 using MoveBlock seems the fastest when you want to replace without starting at zero

11 hours ago, dadreamer said:

Yeah, I guess it's obvious for (almost) every programmer. And well illustrated by the 4th method with MoveBlock call. Looking at that one might say, this is how the replace operation is made internally.

 

By the way it's possible to speed up MoveBlock method a little disabling the wrapper generation. But still it is inferior in speed to the native methods (i.e., Replace Array Subset and In Place Element Structure).

I actually have a scenario where your MoveBlock method might be faster. Using the primitives you cannot replace a portion of a row (which is actually what I want to do). This should be a lightning fast operation but I have to either do it item by item or index out the row first, replace a portion of it and then replace the 2D array.

My code might be sped up a bit with an In Place structure, I have not yet tried this.

1 hour ago, Darren said:

Do you see similar results when running the benchmarks separately, i.e. one at a time in separate VIs as opposed to in parallel in the same VI?

Yes I did. Actually my first benchmark was just to make the change manually in the VI and re-run it. The results are the same.

Sorry my picture was not good, if you look closely I introduce some forced data flow from the first structure to the second so that they do not run in parallel as I did not want to bias the results in any way.

1 hour ago, dadreamer said:

Maybe then you will find that VI interesting as well. I made that to compare different methods to replace rows/columns in the array (four known at the moment).

Risky click of the day running that VI!

But hey, life is short so I tried. My Russian is a bit rusty but I guess you came to a similar conclusion?