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

I'm sure this will do the job too, but I'm not sure if it is the best way. In fact, my main concern is how it will scale when I have more subVIs. Any thoughts? I'm looking at a project with ~30-40 subVI's that I want to verify have error propagation. I've done 10-15 and it didn't take long to create the tests, and the tests run quickly. One thing going for this method is that it is simple, and from my reading on unit testing, simple is good. I think I'm reading that unit tests should test one thing, and one thing only. If you need to test 5 different ways your subroutine could fail, you should write 5 different unit tests. I guess I'm just wondering if I'm missing a shortcut, or if the long road (writing more unit test subVIs) is the better (or only) road to take in this case. Thanks for your thoughts.

Omar, Thanks for your reply. I'm trying to make sense of it and having some difficulty. I'll try to explain what I think you are saying and then let you correct me, if needed. I think you are saying I would write a specific VI to test error prorogation for each of the VI's I want to test, which was what Chris suggested, and similar to what I've pictured below. I'm guessing that I might be able to create VI's like this for every subVI I want to test, via scripting, if I put my mind to it. Then if I use your method of carrying the error in the object, I can use a method to change that error in the setup VI, or in individual unit test VIs. If I want to check how a VI reacts to a specific error, then I can use that "Set Test Error" method to provide the specific error to the VI under test. This would allow me to test how a VI reacts to a specific error, or specific set of errors by running the unit test with those errors set. I've also attached a picture of a unit test that I'm working with now, just to make sure I'm on the right track.

I'm new to unit testing, and new to using VI Tester, so I have a question for which I would like to get some group thought. If I want to test that my VI "under test" passes an error through on its error In connector; should I do that as a separate unit test? I realize that the answer may be, "it depends", but I wanted to get some opinion on this idea before I move forward to modify unit tests, or make new ones. I'm new to the idea of creating unit tests, but I like the idea, and the results, and I'm curious what the group response is.

You might want to check out the w3 schools tutorial on SQL. They also have one on HTML, if interested. You may also want to study up on Relational databases (sorry no tutorial link here), square tables are just the most basic use of a database.

I think you are seeing the fallout from this discussion... Other LAVA Link

I'm not familiar with this cRIO module, but is it accessible to the RT system? If so, I believe you could FTP into the file system to see it. If not, you would probably have to build a custom server / client application to download the data through the 10/100 port. If none of these options appeal to you, perhaps an SD card that has the ability to upload the data on its own? I've seen such cards that work with digital cameras, uploading jpgs as you take them to your home computer... Just some random thoughts.

Me three, that Burger King dude is creepy. In so many, non-humorous ways.

Name: Example - Create Polymorphic VI Submitter: LAVA 1.0 Content Submitted: 03 Jul 2009 Category: VI Scripting LabVIEW Version: 7.1 Version: 1.2.0 License Type: BSD (Most common) Potentially make this available on the VI Package Network?: Yes Copyright © 2006, Chris Davis All rights reserved. Author: Chris Davis --see readme text for contact information Description:: This VI uses scripting to create a new polymorphic VI that contains the methods for creating any type of numeric control on a VI's diagram. This VI is designed to help a newbie learn some of the basics of LabView scripting. As well as serve as a tool to make scripting easier to code. Code was created and tested using LV 7.1.1 Code should work in higher LabView versions, but has not been tested there. Version History: 1.2.0: Added code to make polymorphic VI's icons match thier intended numeric type. Fixed a bug where an error 7 would occur because the polymorphic VI doesn't exist on the users machine to be deleted. 1.1.0: Re-release of code as LV 7.0 for more universal compatability. Changed code slightly to read empty polymorphic VI from disk, instead of using a constant on the diagram. 1.0.0: Initial release of the code. Click here to download this file