hooovahh

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.

I kudo'd the second post talking about how the reuse mindset is more important then the actual code. In addition I deal heavily with VIPM, as I hope all reuse libraries do. Making a package is easy and can install things to the palette, change LabVIEW.INI keys, add tools items, add quick drop functions, add templates, add quick drop shortcuts, add glyphs for the icon edtor, and do all kinds of things. I work at Magna where we have many packages. One issue that comes up is if you have a package, that has a dependency of another package, and the second package has a dependency of the first package, then strange things can happen and it is generally a bad thing. Because of this I have made a handy reuse dependency map. I wish this could be done automatically but it probably wouldn't look nice. Basically this shows each package in our package configuration file, and what internal packages have dependencies on what other internal packages. When making creating new packages, or updating old ones this helps me understand what links already exist, and helps avoid the situation I mentioned earlier.

Here is a handy table. http://digital.ni.com/public.nsf/allkb/2FF365A6FAB7B34786257ACD004BA15A Basically these are properties not ready for prime time. Maybe their functionality only works in some limited cases, or maybe NI is unsure if they want to allow non NI people to be able to use it, or maybe NI hasn't got around to documenting the functionality, or any other reason NI wants to not make the function well known. Because of that these functions may change from version to version, or be removed all together. It is said that private methods should not be used in production code, and NI will not support applications written using them. But they are powerful tools and LabVIEW experts love to dig into these types of things and make tools that normally wouldn't be possible. I made a tool a while ago that goes into the Tools menu when turns on and off these private methods. http://lavag.org/topic/16612-enabledisable-private-methods/ Basically yes there is a "super secret" ini key that enables these features.

As mentioned before this is just the App.UnattendedMode property node in a subVI, and the other VI posted is just the DoNotShowSaveChangesDialog property on a VI reference. Turn on the super secret key to get these properties. Here is one method.

Why are you using the old Series 2 CAN drivers? Is this a legacy program? Does your device support XNET? If so I highly recommend using the XNET drivers. They are superior in almost every way. That being said it is your choice and if you are more comfortable with one driver set versus another then use what you like. Back to the question. Start with the basics. You said that you can see the CAN write works fine using another tool, can you see the CAN message come back from the ECU using this other tool? What do you see there? What I'm trying to get at is, is the problem that the ECU doesn't actually send what it should? Assuming it is sending the data it should try opening the example in the example finder. I think it is called something like "Read write same port" where you can setup a write a frame, then read the frames back. Does this work as expected? Maybe also look at MAX. There is a bus monitor that can look at raw frames coming in. I can't remember if there is a way to write frames there, but maybe your other tool can send the request and see if the bus monitor sees the request, and the reply from the ECU.

Very neat I didn't know this feature existed. Back to the TDMS question. I'd recommend you stick with the three separate logs at different rates because of the mentioned issue with huge log files, and the TDMS header being written all the time. The good news is that TDMS files can be combined easily using a command line "copy /b" command. So you can log to 3 separate files, each in their own group, then combine them into one file with 3 groups.

Your google-fu has failed you. That feature of Quick Drop has been called Super Quick Drop, and on the dark side I had a very similar issue. http://forums.ni.com/t5/LabVIEW/Super-Quick-Drop-Fails-Me/td-p/2833156 For me I first suspected DisplayFusion because I use that as a multimonitor program, but it turns out that it was TeamViewer and the QuickConnect feature. For it I suspect it is some software interaction, but might not be TeamViewer.