hooovahh

3 hours ago, ShaunR said:

I vaguely remember a third party that was offering an alternative solution that was implicitly geared towards LabVIEW and used the TPLAT. But I can't remember who it was or how it worked.

There was a couple, but I never used any of them.  I think BLT is one that meets the needs, and I think Wirebird Labs had one, but that hasn't had any update in forever.

6 minutes ago, Francois Aujard said:

 I'm going to stop drinking 🥴... 

Hey let's not get hasty now.  But honestly this has bitten me on a few occasions as well, so don't feel bad.

Is this a sequence editor?  If so I don't see the tab design being very scalable.  Here is a screenshot of something we do.  It has a tree control on the left with all the different step types, with categories for them.  Then the user can drag and drop an icon over to the right.  Once they do a dialog will come up with the settings for the step they selected.  They can also double click a step on the right for the settings for that step to come up again.  There's lots of extra stuff like custom step limits, which is a slide out, and visual arrows if a step has a condition for jumping.  Loops are seen as a tree on the right where you can drag and drop into or out of loops, and rearranging steps is also a drag and drop.  There is also columns for icons that can be clicked, which is actually two picture controls because you can't have multiple glyphs in a tree, and if you can hack that in the icon size has to be real small.

Each step has a typed cluster with the settings for it, that get flattened to a variant.  You might not need to get this fancy, but a listbox of step types, and a listbox for the sequence might be a good start.

5 minutes ago, jacobson said:

So when you start your "Modal" VI you'll just set the FP.Behavior to Modal and set it back to Default when the VI finishes executing?

Yup.

I don't like VIs to be set to Modal in the VI Properties.  I actually have a VI Analyzer test to find these.  This is because when the VI reserved to be ran, but the panel is open, it will be modal, but also not running.  In this situations aborting gracefully is difficult, and needs either an Abort All VI set to run when opened, or something like my Tray Launcher.  Because of this I have very few modal VIs in my code, and instead I will set them to modal using VI server when the VI is running.  If I have a VI that I want to be Model when it is running, I will set it with something like a constant of True when calling those panel manipulation VIs.  I guess that's a long way to say "For debugging benefits".

As for what VIs do I want to be Model?  I'd say things that are dialog settings that need to be filled out now.  If my user presses Start Test a dialog comes up asking about the details of the test to be ran, and that dialog is Model.

I'm convinced most of the users of my software are illiterate.  The good users of my software know the common troubleshooting techniques, and will blindly run through turning it off and on again before telling me.  Then if "The red screen" comes up again they'll tell me, or take a picture with their phone.  Honestly I prefer this over the "I don't know what it said".

Finding only 156 LabVIEW jobs, and 476 COBAL jobs could be seen a couple ways.  You could use it as an example of how bad LabVIEW adoption is.  "See how there are so many more COBOL jobs than LabVIEW, and it hasn't been used in decades", or you could say the market has too many LabVIEW developers, for the number of available jobs in that area.

9 hours ago, ShaunR said:

Considering COBOL is over 60 years old, I think most experts have long since retired and most of the US government runs on COBOL. Just a quick and dirty example from one site...

I was referring to the multiple posts on that forum looking for work, and recruiters.  They either had no reply, or replies from other people also looking for work.  This post mentions using COBOL in several projects in the 2000s.

3 hours ago, ShaunR said:

Too obtuse for my smooth brain. You link to a COBOL forum and imply something but I have no idea what you are implying or it's relevance.

I'm with you.  I just assumed it was a suggestion that LabVIEW will soon be seen, the same way COBAL is today.  Very little activity, and developers asking the void if there is any work for a thing they were an expert at not long ago.

Apparently this is DataGrid.  It would certainly have been more helpful to state that somewhere in the title or post.  I can't edit the title, it is likely a restriction on the forum.

I've never thought about adding this feature to my software but it seems so obvious now.  It would be nice to know the color the mouse is over as the user moves it, so it can change the color of some object as the user does it.  This almost seems like it should be an idea exchange so I made one.

3 hours ago, bjustice said:

Really?  You're suggesting that there's potentially a faster way to convert a u8 byte array to an array of DBLs?

I am suggesting that, yes, but I can't prove it.  My reasoning is just that every time I've been able to code around the Type Cast, it has improved performance.  I admit that converting to a double is more complicated than my other examples so I could be wrong.  I'm not exactly sure how a double becomes an array of bytes.  It might be simple but for some reason it isn't clear to me what the conversion is.  Casting a double "1" becomes 0x3F F0 00 00 00 00 00 00.

Edit: The deeper down the rabbit hole I go, the more I think Type Cast should just be used in these cases.

17 hours ago, bjustice said:

Unless I'm missing something, my understanding is that this mechanism here represents the most performant way to convert an array of bytes or a string into a strictly typed numeric array.  Thus, the optimization discovered by AQ here is very useful.

Oh don't get me wrong, what AQ posted here is great and anything to improve performance is appreciated.  I'm just saying that a Type Cast function itself, is on the slow side, when compared to a more low level option.  Lets say you are converting an array of bytes into an array of booleans.  You can use the Type Cast, but depending on the use case a "Not Equal Zero" would be a better.  Same with if you are converting to an enum.  Having a case structure for the numeric, and then having enum constants for each value would be more efficient.

In the example AQ posted you could do the raw math on the array of bytes, and get a double value.  I suspect this would be better on performance, if someone spent the time to write a conversion from 4 bytes to a double and back.

In general I try to avoid the Type Cast function.  In the example AQ gave I probably wouldn't try to code around it, since that seems like it could be a pain.  But something like a number to an Enum, or to a cluster or array, I may try to code it for better performance.

On 9/26/2022 at 11:14 AM, Aristos Queue said:

Just to close the loop: by LV2021, of the three of the Flarn-proof config tokens I mentioned in 2014, two are now public features and one was completely removed from the product as a bad idea. None of them are settable any more. I did not go out of my way to hide any new ones.

I'm going to guess interfaces, and sub VI call replacing (non class override through VIMs)?  Was there a target specific structure teased or did I dream that?

2 hours ago, Gribo said:

SaaS.

I'd like to change my vote.

7 minutes ago, Connor.Prior said:

I also have several packages in the vi.lib folder, and the longest there is 217. Does the path limit affect these the same way?

It can.  I believe the actual building will take place near the project in a hidden folder.  So if your project is in C:\Code\Repository\Project Name, then you will have a folder like C:\Code\Repository\Project Name\Hidden Folder\VI.lib\...  with all the code in it.  So the full path to the reuse and project can be an issue.  Shortening either is useful if that is the issue you are having.  This was a much bigger issue in the XP days, where people would have source code checked out in their user folder, which was C:\Documents and Settings\Users\User Name\My Documents

Yeah these suck sorry.  So you can start by clearing the compile cache and trying again.  This is in the Tools >> Advanced menu.  Then close and reopen everything.  It will take a while as it needs to compile all the code again.  Then you can try to build again.  Another thing you can try is to turn on the extra build details by adding NI_Appbuilder_logging = True in your LabVIEW.ini file.  This will make a text file along side your project file with details about the build.  It can be useful, but I've never had it tell me anything that helped with a build process.  If you do ever get it working you can remove this line from the config, it will probably make the build take longer since it generates that log as it builds.

I had a build that worked fine then it started getting harder and harder to build, needing to clear the compile cache a few times and try over and over.  Eventually I went to LabVIEW 64 bit and that issue went away.  That may solve one of your problems and create others.

Thread locked, spammers seem to like this thread. Message a moderator if you want to actually reply.

8 hours ago, Krishna16 said:

Can you please share me the link where we can see License Type for  oglib_error v2.0-1  and oglib_lvdata-2.2-1 libraries.

I know we can see in VIPM but I need a link that shows License Type. As I see from VIPM it always showing  latest version of link only.

If you right click a package you can select Get Info Other Version, then select the version you want.  I picked the String and it has version 2.0-1 which supports LabVIEW versions 6.0 and newer and lists the license as LGPL.  This license information is embedded in the spec file, in the package file which is downloaded in the cache folder.

On 9/9/2022 at 12:31 PM, David Boyd said:

Thanks, Dataflow_G!  I really needed to see all those CRT monitors to be reminded of the passage of time...

There's a bar I go to by my house that is a bit of a hole in the wall.  They have flat panel modern TVs, but the wall mounts for all of them are huge where the CRTs once sat.  Its funny to me to see such a thin light TV, sitting on a wall mount that could probably hold 300 pounds.

Maybe it is trying to output to a display that isn't there?  And on that display is a list of boot options, and pressing <CR> does the default choice?

So back in the day the way I did this was with the Hiren Boot CD.  You either burn the CD and use a USB CD drive, or get it on a USB drive and boot to it from there.  There are a couple of security tools on it such as the Windows Login Unlocker, but I think the NT Password Edit was the thing I used, which is also on it.  If you can't get to the bios I'm not sure you'll be able to change the boot order, and you might not be able to get that far anyway.  Security changed with Windows 8, and I do believe these methods no longer work with modern operating systems.

Thanks, I downloaded the vi, and edited the post adding it.

That is cool but I don't know how to help.  We did install Linux RT on a bare metal rack mount PC as a preliminary test.  We never did any performance testing, we were just looking for potential new designs for systems.  I'm sure if you get a hold of the right person at NI they would be able to help, but I don't have any contacts at the Linux RT R&D department.  However, if you contact support they will probably laugh at you, sorry.

1 hour ago, Rolf Kalbermatter said:

And really a nitpick but your title is rather inaccurate :-).

There is no opposite of MoveBlock(). The only opposite you can have is by swapping the source and target pointer here. Other than that I'm not sure what other opposite you could think off here. 

Well I was having a hard time coming up with the words of what I actually needed.  In my mind MoveBlock took a pointer to an array returned from a DLL and gets the actual array of data in LabVIEW.  I wanted the opposite, which was to take an array of data from LabVIEW, and get a pointer for it.  I agree the title is terrible, and MoveBlock can do both operations, with the only extra needed is allocating the memory with DSNewPtr, and releasing the memory with DSDisposePtr.

4 hours ago, Rolf Kalbermatter said:

Basically when you configure a Call Library Node parameter to be a pointer sized variable, LabVIEW will treat it as 64-bit integer on the diagram but do the RIGHT thing depending on the bitness it is running on. It will use the entire 64-bit when it is running as 64-bit process, and the lower 32-bit when it is running as 32-bit process. And a returned value will be sign extended (if you use a signed pointer sized integer) when running on 32-bit and zero padded (if you use an unsigned pointer sized integer) on 32-bit. Nothing special needs to be done when running on 64-bit.

That totally makes sense now.  Thanks.