Jimmy Chretien

Hello guys,

I had issues like that also. The 5V supply I was using was 2.1A, after changing for a 2.5A as specified the installation won't fail anymore, hope this helps.

Another problem I had was that I had both LINX versions installed on my PC at the same time, make sure you're using the one from NI that works with LabVIEW 2020, the other one uses 2014.

Jimmy

You could use the Type Specialization Structure and perform conversion, U8->I16, U16->I32, U32->I64 and U64->EXT before your String to Number conversion.

There's a primitive for that.

Cheers,

Untitled.vi

Hello Bear,

you can click the "Highlight Execution" Light Bulb in the top left corner in the Diagram window and run your VI to observe the dataflow.

I think your bug is in the case structure that checks which OS it's running on, your case "Linux, Default" is always used I think, the other cases are greyed out so that's probably where you should double check how to implement that part.

Let me know if that doesn't help.

Cheers,

Jimmy

In your middle loop, the queue reference is not passed outside the case structure, so at the next iteration, the shift register returns a null reference which the Dequeue function doesn't know  what to do with, returns an error.

There's no point to use a shift register for references, unless you need to generate a new reference or something, just delete the shift register and use a simple tunel, or wire the reference all the way.

Hello LAVA,

I'm making a .NET interop assembly from a few similar VIs which have a cluster as input, some of them have 3 DBL inside the cluster, some have two DBL..

Using some magic, the compiler creates a .NET class for each cluster found. And then, when using that dll we have to Construct a cluster object which we can set the values and then use the object reference as input to the method...

After the first attempt I realized I had different clusters with the same name "Parameters" among my VIs, but the DLL will need different names for each of them. This makes sense so no big deal let's give them a meaningful name.

Here's the bug, even if I give different names to all my controls, when the compiler finds a second "3 dbl" cluster it will not create another "3 dbl" class, resulting to the impossibility to construct that class when using the dll.

If I try to use the same "3 dbl" class for my two methods, the wrong named one will crash for the name difference...

The only workaround I found so far is to make the second cluster "3 sgl" instead so the compiler sees a different type and creates its class.

I think it's not ideal to workaround like that so I will try to avoid clusters in these cases because they are simple unarrayed clusters so I can just take 3 inputs on the VI.

Anyone familiar with this?

Cheers

Is it possible to create some sort of compiled (block diagram removed) library "modern LLB"?

When I create a packed library, it will include all the dependencies from other lvlibs, I have a core build exe that already includes all those dependencies so I don't want them copied in each packed libraries.

I can assume that any subVI will be in memory at run-time, how can I organize this?

Cheers!

By the way, I created my own subVI but just found this native VI used by the formula parser, the idea is similar as Ton's.

..\vi.lib\gmath\parser.llb\Dot or Comma.vi

Have you calibrated your Zebra?

I was wondering if there's a trick to get the last selected item in listboxes when more than 1 items can be selected.

On screenshot we can see on the GUI which one is the last selected, is there an easy trick to catch it in the code, without needing the previous value of the control.

The value array will always sort them out.

Yes you're right, I wrote to quickly.

Hello everybody,

is someone able to tell me why the Min-Max functions doesn't return an exact same value as connected on the inputs?

Attached an example you can easilly reproduce at home.

Cheers,

Jimmy

Dear LAVA,

I'm trying to figure out how I could make custom libraries that an exe would load dynamically, and those external libraries could use as subVIs some VIs that are "included" in Main.exe

I made this simple diagram to show how I see it, perhaps someone already faced that issue and found some workaround technique to make it possible.

The idea is to keep Main.exe as standard as possible, without having to make a new build each time we make slight new features in custom.vi

Cheers!

Basically you need 2 more Property nodes if you want to keep your headers color.

you must do what QueueYueue said first.

Then :

Active Cell.Active Column Number = -2 (this selects all columns)

Active Item.Row Number = -1 (this selects the column headers)

Active Cell.Background Color = Desired color

Then :

Active Cell.Active Column Number = -1 (this selects row header)

Active Item.Row Number = -2 (this selects all rows)

Active Cell.Background Color = Desired color