hooovahh

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.

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.

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.

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?

I'd like to change my vote.

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.

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.

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.

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. That totally makes sense now. Thanks.

That's what I thought, which is why I was confused by the datatype that the DSNewPtr returned for an Integer Sized Pointer as a U64.

Aw man, you're telling me an undocumented feature that can make my program perform better, but also unstable, isn't the right approach. Fine I'll stick with the CLNs. But it is very tempting to use this node, and just lock down the VI and put up all kinds of warnings. About the 32/64 bit through. So on my 64 bit Windows, but 32 bit LabVIEW, the memory pointers are always 64 bit, and but it looks like it is always only using 32 bits for the address. This is using the "Integer Sized Pointer" for the nodes. This is apparently an I64. Shouldn't it be an I32, and only on 64 bit LabVIEW, be an I64? Also these should probably be unsigned right? But likely doesn't change the functionality?

Thanks, I did figure it out. Using the linked example was very helpful. First I think the pointer wasn't being put at the right index, so data was being read at an address and then that was being sent. Then the example used I32 not U8 as the data of the array, and there were extra zeros between data points. Seems all good now.

So I'm dealing with calling some DLLs for external communication. When you call the DLL one function returns a pointer to an array of data. Using the MoveBlock I can successfully get the array of data back into LabVIEW. But one issue I'm having is that I also need to go the opposite way. I have an array of data in LabVIEW and I need to send it to the DLL. I realize the normal way you would do this is by calling the DLL with the Array Data Pointer on the Call Library Node. The problem is the data I need to reference, is actually a reference in the reference. In LabVIEW I have an array of U8 like this: [0]=0xFF [1]=0xAB [2-5]=Pointer to Data [6, 7] = 0x1234 I'm already calling the DLL passing in the array of 8 bytes using the Array Data Pointer, but within that array needs to be 4 bytes, referencing another pointer for another array of data. Is there a way to create a pointer in LabVIEW to some array of data? Then I can put it in my array, and send that? Sorry my C and DLL calling experience isn't as good as my LabVIEW experience and even finding the words to search for are difficult since it returns all kinds of information about MoveBlock, and LabVIEW control references. Thanks. Edit: Okay looks like I might need DSNewPtr to make a pointer, that I can then pass into the DLL. It is partially working, it just isn't the data that I put into the pointer.

Sorry I'm just trying to work out how I'm going to support helping the community, in the event that management decides to not go the subscription route.

I messaged the site admin again. Also remember there is a Community Edition, and presumably there will be for 2022. So a subscription and payment aren't required for 2022, but an NI account in this case would be.

I'd first ignore LabVIEW and just look at the theoretical limit using command line tools. I used Iperf in the past between two computers with one setup to be the server, and one the client. The fact that you see 100% makes me think there is a different bottleneck.