Chris Davis

I would have sworn that I couldn't use >> as a separator for a second argument, but I just did a quick test and it works just fine. One could also use a comma to separate the values too. I've used the second argument as a modifier for the first i.e. Set Disabled Property >> Start && ENABLE Set Disabled Property >> END && DISABLE This kind of capability has allowed me to use a Macro case to enable and disable controls on the front panel via state machine cases. I usually broke apart the argument list using the OpenG Split String and a pair of trim string subVIs. This subVI is much more generic and can be used with an infinite number of arguments. Thanks Brian!

I've used a && between arguments as a delimiter.

https://nicommunity.jive-mobile.com:443/#jive-document?content=https%3A%2F%2Fnicommunity.jive-mobile.com%2Fapi%2Fcore%2Fv1%2Fdocuments%2F17214 It's not the bit.ly address but it iswhere it leads. Enjoy.

I've done both of the first tasks you mentioned, and had no problems. Take a look on the web to find guides on setting up apache2 with subversion, to help you get it right the first time. I don't use a LabVIEW project extension, although from the information I've seen on LAVA, the JKI version should integrate better with LabVIEW than the PushOK one. Enjoy, Chris

Sorry, I think you mistaken when speaking about LabVIEW 8.6. What you are saying may be correct for LabVIEW 2010, but I don't know for sure. In LabVIEW 8.6, if you "inline" a subVI, the subVI's code is literally copied into a flat sequence structure on the parent VI while you watch. You get a choice to "hide" or "show" the code by allowing LabVIEW to shrink or expand your block diagram with the code from the subVI. If you choose to "hide" the code, you get a flat sequence structure that is approximatly the size of a subVI icon, if you choose to show the code, your diagram is expanded to hold a flat sequence structure with the code from the subVI.

I think you could you this information to allow you to inline the code, in the development environment, and still keep the code semi pretty. You can inline to a flat sequence structure and it takes about the same amount of space as a sub vi. Bad part is that the inline is one way. Of course if you did this right before you made an exe, and you had your code in version control, you could revert back after the exe was made. I believe JKI did this sort of thing in a build script, so it is possible to use this technique to inline subVIs at EXE build time, but you'd have to build your own build script. On a side note, I believe LV 2010 can be told to inline VI's on a VI by VI basis. I believe it inline's new VIs by default.

I believe I have found a bug in the IMAQ Bayer Decode subVI that is shipped as part of the Vision Acquisition Drivers, August 2010 (NI-IMAQ 4.5). Inside this subVI, there is a call to imaq.dll to convert a grayscale image to a color image, to pass pointers to the memory space for the source and destination image, 32 bit pointers are used in a 64 bit OS. Obviously this is incorrect and could cause crashes if the program is working with the large amounts of memory on 64 bit systems. It is possible to work around this bug by manually changing the first two calling parameters of CLN from int32's to i64's or u64's. Since the Map Pixel Pointer subVI returns u64's for pointers on 64 bit OS's, this CLN should probably use u64's as well. You could wrap the CLN call in a conditional disable structure with flags for 64 or 32 bit operating environments, if you want. I've been happy with that solution when I've needed to make code work on 64 bit and 32 bit LabVIEW. I've tested this work around in my appliation, after I discovered the issue, and my application works fine now. Until the bug is fixed, I'll be sticking with this solution, unless a better work around is provided in the comments below. I know this may not be the best place to post this bug, but I wanted others to avoid the issues that I've faced when dealing with this bug. Immediate crashes when calling this subVI, unmodified from the initial install were hard to track down. When an NI engineer reads this, please post the CAR for future reference. I've tested this with LabVIEW 2009 64 bit on Windows Vista Business 64 bit and Windows 7 Professional 64 bit. <a href="http://forums.ni.com/t5/Machine-Vision/Bug-in-IMAQ-Bayer-Decode-on-64-bit-systems/td-p/1312549">Cross-posted at NI Discussion forums</a> Cross Post Link

Thanks. I assumed you were talking about LabVIEW Classes when I saw that section. I wasn't at NI Week this year, so I haven't seen the keynotes, yet. I'm hoping to get to view them this week, assuming I can find them on NI's website.

Where did you see this statement?

I don't zip them to save space, just to make it easier to distribute. The space saving is a side effect. You don't really define what you mean by "bigger" in your sentence. Are you trying to get your Report Generation Toolkit plugin down below 1 MB, or 10 MB, or 100 MB? What kind of penalty will you face if the Report Generation Toolkit plugin is "large"? How does the size of the Report Generation Toolkit plugin compare to the size of other plugins? If you have a working solution with the Report Generation Toolkit, or could easily make a working solution with the Report Generation Toolkit, I would think that the cost and risk of implimenting another solution, that wasn't as debugged as the Report Generation Toolkit, wouldn't prove worth the 3-10 MB of storage you saved on a machine with a 320 GB hard drive... All that being said, if you actually have a stiff penalty for your plugin being "large", you should look at ways to reduce the footprint of the plugin. Of course, if you are generating HTML reports you probably aren't worried about space on the hard drive... Did you know, someone on LAVA posted an extension to the Report Generation Toolkit that allowed it to create Open Office Documents? Word 2007 and Open Office can create PDF's from any type of file they can read, so you might be able to use these programs to create PDF's of the documents you create from the LabVIEW Report Generation Toolkit.

for simplicity, you could distribute your plugins as zip files that are automatically unzipped at program start up, or on demand, then deleted (or not) when the program is shutting down. I'm doing that now with a project and the system works well. One issue I've found is that Windows Vista and Windows 7 computers don't like it when you delete things from the Program Files or Program Files (x86) directory. If that is an issue for you, you could unzip your plugin into a temp directory and work on it from there.

I've used the ones from B&B electronics before with LabVIEW and had very good results. The models they sell will do 4 ports, with RS 232, 485, or 422 options in the same device. At 1/2 the price of NI's 4 port box. The driver they ship make the ports show up as local ports on the computer. Downside, you'll have to provide a 9-30 VDC power source, the NI box takes AC directly in. For your application, that may not be an issue.

I think you will have better luck with the Icron extenders, they are designed for USB2. I'm still not sure they will work, but they have a better chance than the blackbox USB1 extenders. If your client is up for another purchase, you might want to checkout NI's Ethernet DAQ devices. If they meet your needs, and don't break the bank, they are much more reliable over long distances. They can also be clocked together so that you can get more channels of input. I have used three NI-ENET 9215's in such a way and have been very impressed with thier abilities. It looks like the 9205 has 32 channels, and a very small package, but you didn't mention your rate/channel or channel count needs, so I don't know if it will do what you want. You might also consider bringing the computer closer to the USB device, via a "weather proof" box and the appropriate connectors. You could then use VNC, or a KVM extender from blackbox to extend the monitor, keyboard, and mouse.

Just a shot in the dark... Do you have the quick-drop helper option on, "Load palettes at startup". If so, "converting toolkits" might just be the last thing the splash display prints before starting to load the palettes.

Thanks, that is what I thought I was gathering from my unit tests, and my online reading. Thanks for the real world example, I was hoping you would provide one from JKI's products. I think its time for me to make those decisions on the project I'm working on. Thanks, Chris