hooovahh

Finally got the confirmation I can go. Now to frantically buy everything. Also Hooovahh Incorporated a division of Hoover Corp is donating a Teensy 3.1 microcontroller.

Or have moderators around to split topics...

So whenever I go to use this function for simple programs, I always open the VI copy away the functions it calls (which admittedly aren't much) and paste those into my VI instead of calling that VI directly for that reason. Wouldn't it suck if all VIs on the palette didn't return an error but instead had a simple error handler in each of them? Then why do that for this function?

I agree with the error message. But I found that if you go to File >> Open Package File(s) and select multiple packages, one or more of which is built with 2014, then choose to Add to Library, a error comes up explaining that it was built with 2014 which is incompatible. Not sure why this error wasn't used in more places.

This is generally because the package was built with VIPM 2014 which had new features not compatible with previous versions of VIPM.

Would the UID work? It looks like it applies for all GObjects. The help states that it is only unique for objects within the same VI but you could try to hash the UID with the VI name or something like that.

It is voodoo magic. Explain to me why Copy 1.vi gets executed when you drop the XNode on the palette? This is a neat feature, but it doesn't help us get more insite into XNodes.

That is some voodoo magic. I was wondering how that was done too but never looked into it. If I had to guess I'd say Xnodes have the capability to run something on loading of the Xnode into memory. There are obviously at least 3 files in that library, the _Copy 1.vi, _GetHelp 1.vi, and _State 1.ctl. The two VIs are password protected, and don't really go anywhere. EDIT: So it doesn't have to do with the XNode getting into memory. If you load the XNode file as a library it doesn't launch anything. From there you can't do much other then read the library name, get the locked state, and get the Icon of the library. DOUBLE EDIT: So the GetHelp appears to do nothing and loads nothing other typed controls into memory. It never returns an error and does nothing. The Copy function always returns "FailTransaction" as the reply, and never returns an error and appears to do nothing with the XRef input. It does however run the <LabVIEW>ProjectFind LabVIEW Add-ons.vi with the input Source having a constant. Still not sure how the XNode runs this VI when you select it from the palette, or drop it on the block diagram.

It isn't clear what you are trying to say. On the second PC, what happens when you run the EXE? Does it run? Does the EXE have a broken arrow? What do you see? Have you only been able to run the EXE on the PC that the software was developed on?

If you changed that VI, and restarted LabVIEW, and the behavior of the dialog didn't change, then I would say that that VI isn't part of the low level dialog that you see in that control. That dialog that you see could be buried in the LabVIEW.exe file and there might be no way to edit it.

I was just in the middle of saying this. Make a copy of the PickTime.vi and name is something different. Then have on your front panel the time and date control, but don't show the button for picking the date, instead have a boolean that calls your copy of the PickTime.vi

Yeah I'm guessing Tim is right. You'll need to either install all the needed driver, software, and run-time engines on the other machine, or create an installer that includes all those things. In the project under build specifications right click and create an installer. In the install go to the Additional Installers section and choose the software tools you used. Then when the installer is built these things will be in it. Expect your installer to grow into at least 1GB but it sounds like a big program so it will probably be bigger. Once these things are installed new installers don't need to include all of this extra stuff, but it must be there the first time or else you won't be able to run.

After a Read, Write, Get Property, Set Property, or List Contents I know that the reference is not changed. Meaning the TDMS reference going in, is the same as the one going out and there is no need to update the reference. I think that is what you mean by is the pointer maintained. An open operation does take a long time on large files, and is likely very hard drive intensive. Like most file I/O it is best to open it once, at the start of your application, perform all the read and writes with the reference, and then close once. I wouldn't recommend doing an open, then operation, then close, every time you have any data you want to read or write. I've never used the Asynchronous versions but I would assume they work the same way where the TDMS reference doesn't change between operations.

Who wants to resurrect a post . I have a white board in my cube and posting this example has been on my list for a while. Attached is an example of this progress bar loading splash screen I tried to describe a year ago. Nothing too special but I use something similar to this in my production applications. Build the Normal EXE and you'll end up with a 6MB file that when ran shows no UI for about 3-5 seconds. To make it worst add the 8th actor to the main VI along with the other 7. I removed it because it took way too long to build an EXE. The total VIs in memory with it added was around 4500. If you are missing any VIs feel free to delete them, or that entire actor, it is only meant to bloat up the number of VIs in memory and they are never even ran. Then build the With Progress version and you still get the 6MB file but the UI is shown within a second showing the progress of each actor being loaded into memory with an option to cancel. Then once each actor is loaded it loads the main and runs it. For this to work the Launcher is the top level VI and Main is set to always include. And there is a Pre-Build action that gets a list of the actors, and their relative path to the VI to load and writes it to the config file used in the EXE. This Pre-Build action is more elaborate in my production applications because not all actors sit in a folder called "Actors". Instead it opens the project and navigates based on library names, and connector panes but the idea is the same. EXE Loading Progress.zip

Yeah the merge solution is probably the right one, which sucks because I just got the post install hook idea to work, where it scans the installed files for MNU extensions, and then adds them to the root palette (the blank one) automatically. I guess the only downer is that you would then have to manage another VI for every XNode you have, editing the icon, description, and terminals to reflect what you want the XNode to be but that seems like such a minor complaint.

Okay thanks for the info. One more question (for now). What magic did you use to get this to work in the Package Builder? See I realize you have a custom MNU because VIPM's Package Builder doesn't recognize XNode files (as mentioned in the VI Shots). But how did you convince Package Builder to have a sub palette, that is linked to an MNU file? I can do this in a post install hook VI no problem, but what is interesting is if I open you package source in Package Builder, change something small like a description, resave and close, when I go to open it it will complain that a file has been removed from the palette and that connection between the subpalette and the custom MNU is lost.

Thanks for your help. Obviously the best solution is to just go to VIPM 2014 and use the newest, and also abandon support for 2011. Upgrading VIPM is a cost that I haven't talked to management about yet. But leaving 2011 behind is a decision I can make. Thanks again for the info.

Old topic I know, but the recent VI Shots got me interested again. I noticed that the Filter Array will be broken if the "Items to Filter" is a scalar and not an array. The original OpenG ones accepted either an array or scalar. This was on version 1.3.1.31 because I don't have VIPM 2014 yet, and I also want to support a reuse library of 2011 so to be fair this might be changed in the newer versions.

I had hangouts open in a chrome window not maximized. When they started doing demos I maximized my screen, which kicked me out of the hangout, and started from the beginning again, so I skipped to live. Then the demo was done so I unmaximized, also kicking me out and starting it over.

Well, in typical Hooovahh fashion I have a quick and dirty solution. You could set the control to be not visible, and instead make a picture control visible that is in the same location as the control but have a picture constant of the way the control should look when greyed out.

It really sounds like you want something embedded, and it really sounds like you don't have something embedded. Is there a reason for this choice? Work all you want at setting priority loops and avoiding the UI, but as soon as Windows feels like defragging, or indexing search, or update anti-virus, or timeout talking to a driver that doesn't exist, you will be at the mercy of Windows as far as loop rates are involved. Embedded cRIO, Real-Time, FPGA, or even a micro with CAN is going to give you better performance. What driver are you using for CAN? XNet comes with a driver level wait for messages so you don't need to poll the hardware for new messages. It works almost like a trigger on a message with an optional timeout. This might help performance as well.

Topic Split, new topic being discussed. http://lavag.org/topic/18305-fpga-dvr-tdms-log/

Hope you don't mind, I made a thread here.

I knew I saw something like this. Thank you I will look into automating it in the future.

That is neat. Have you posted it on NI's forums, or made NI aware of it? Obviously this should be made into a CAR.