Chris Davis
-
Posts
423 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Chris Davis
-
-
I've used a && between arguments as a delimiter.
-
Did anyone attend Simon Hoggs - Data Acquisition Template session today and happen to jot down the bit.ly address where he's stashed the templates he created? I can't find them anywhere on ni.com.
-Ian
It's not the bit.ly address but it iswhere it leads.
Enjoy.
-
I have for some time been running without a source code control tool. I do realise the benefits having used one at my previous company and so I’m keen to get back to using a tool. Having read around on the forums I’ve decided that Subversion is the way to go with LV. I’m unsure of how to go about setting it up and would like to gain a bit more knowledge before I start. These are the steps I intend to take:
1) I intend to download and install TortoiseSVN on my PC from http://tortoisesvn.tigris.org/
It’s described as “A SubVersion client, implemented as a windows shell extension.”
2) I presume that TortoiseSVN requires a SubVersion server set up. So, I nintend to doswnload the SubVersion server from http://subversion.apache.org/ Having taken a quick look at the FAQ it says “If you want to host a networked repository, then you need to set up either Apache2 or an "svnserve" server.”. So I intend to do that on a server PC that our development group can all access. Has anybody done this?
3) For the time being I intend not to use a plugin so that the repository can be accessed via LV project. Perhaps I may try out the demo of the JKI plugin as it seems to have much better reports than the PushOK one.
4) I realise there is a lot to set up after this and a lot to learn in the way that the tool is used but for the moment I’d like to get to point where it can be tried out.
Does that look like a sensible start?
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
-
Sure it can. It has nothing to do with priorities. As I understand it, when a VI is set to subroutine it means it gets executed sequentiality within the VI so there is no chance that a task/thread switch can occur at the call boundary. As for in-line - in theory the code boundary shouldn't exist, but you can select both subroutine and in-line, so I'm not quite sure exactly what happens. Like I said. I haven't really played with in-line but the VI has to be re-entrant whereas for subroutine it doesn't have to be.
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.
-
Even with required inputs and subroutine priority, the subvi implementation is ~3000x slower than the formula node on its own. I understand that there's overhead associated with calling subVI's, and when the contents of the subVI are very fast, that overhead will become the dominant factor. Also, in this case, the factor of 3000 is the difference between "really fast (7us/iteration)" and "really really really fast (2.5ns/iteration)". That said, does anyone have any suggestions? Am I just stuck with that large (although possibly insignificant) slowdown as the price of having prettier code?
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>
-
It's in the Notes section of my PowerPoint presentation. NI as a whole talked about this in the Keynote presentation.
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.
-
"The new features for LabVIEW 2011 will be a handful of very cool features (including a few from the LabVIEW Idea Exchange) and a huge number of bug fixes, editor performance upgrades and compiler optimizations. This decision comes in response to your user feedback."
Kudos to NI for making this call.
Where did you see this statement?
-
Chris,
Thanks for the ideas. Sounds like you've got an interesting system working. From what I gather, you zip the distribution to save space, then unzip it dynamically to use it?
Even zipped, the Report Generation Toolkit seems bigger than I would like to distribute. Maybe someone has a third party LV tool for making PDFs?
DaveT
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.
-
I was wondering if anyone had come across any alternatives for creating html reports that don't use the NI Report Generation Toolkit. We're starting to play with the Report toolkit, but my previous experience is that when you create a distribution, it bundles in a huge amount of LVOOP libraries, directories, etc. We're making a built executable with plug-in modules. The report will be generated by a plug-in, and so we need to deploy all the necessary sub-vis as a source distribution. I'm reluctant to have it blow up into 10s or 100s of MB's just for a fairly simple piece of functionality.
I wouldn't be surprised if people had made their own html report generation code, but so far I haven't been able to find any.
Thanks,
DaveT
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.
-
Tomorrow we will try one that is rated for USB 2.0 speed and is externally powered.
Icron USB Ranger 2101
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.
-
Why does LabVIEW 2009 have to convert toolkits on startup and why does it take forever. You'd think that after the first time, the toolkits don't need to be converted again.
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.
-
Ya, one problem with writing unit tests is that you basically write a lot of tests. I'm pretty sure that whether you use VI Tester or NI's UTF - if you want to test that 30 VI's have error propagation, you'll need to write 30 tests.
Thanks, that is what I thought I was gathering from my unit tests, and my online reading.
It comes down to how many test paths you want to test to ensure the quality level you need. As an example, JKI's EasyXML product consists of just 4 public API VIs. We have > 60 unit tests for these VIs. One great thing about writing unit tests as it relates to TDD is that you can write unit tests for bugs the have been identified before the fix is in place. We do this for every bug reported to JKISoft forums for our products. Some unit tests currently fail because we haven't implemented a solution for those issues yet. But the great thing about a unit test is that once it passes, you know from that point forward that if the test fails, something is probably wrong with your code. This means that your unit tests add value and stability to your code over time.
Thanks for the real world example, I was hoping you would provide one from JKI's products.
Ultimately, you have to decide what things add value by testing them, and test the hell out of those things. Although, with scripting, it may be possible for us to create more unit tests quickly and not have to make the value decision as often.
I think its time for me to make those decisions on the project I'm working on.
Thanks,
Chris
-
This is one way to do the error propagation test. It works, there is absolutely nothing wrong with doing it this way.
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.
-
-
I think you are seeing the fallout from this discussion...
-
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.
-
Name: Example - Connect a Control to an Indicator
Submitter: LAVA 1.0 Content
Submitted: 03 Jul 2009
File Updated: 03 Jul 2009
Category: VI Scripting
LabVIEW Version: 7.0
Version: 1.0.0
License Type: BSD (Most common)
Potentially make this available on the VI Package Network?: Undecided
Copyright © 2006, Chris Davis
All rights reserved.
Author:
Chris Davis
--see readme text for contact information.
Description::
A simple example of how to create a new VI using scripting. The VI has a path control and a path indicator, which are connected using scripting. The path control is connected to the upper left connector on the 4x2x2x4 connector pane, and the path indicator is connected to the upper right connector.
This VI is designed to help a newbie learn some of the basics of LabView scripting.
Code was created and tested using LV 7.0. Code should work in other LabView versions, but has not been tested there.
Version History:
1.0.0:
Initial release of the code.
-
Name: Example - Connect a SubVI and its Inputs
Submitter: LAVA 1.0 Content
Submitted: 03 Jul 2009
Category: VI Scripting
LabVIEW Version: 7.0
Version: 1.0.0
License Type: BSD (Most common)
Potentially make this available on the VI Package Network?: Undecided
Copyright © 2006, Chris Davis
All rights reserved.
Author:
Chris Davis
--see readme file for contact information
Description::
This simple VI uses scripting to create a new VI that has two numeric controls and a numeric indicator. The two controls are multiplied together and wired to the indicatorThis VI is designed to help a newbie learn some of the basics of LabView scripting.Code was created and tested using LV 7.0. Code should work in higher LabView versions, but has not been tested there.
Version History:
1.0.0:
Initial release of the code.
Question about the JKI state machine
in Application Design & Architecture
Posted
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.
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!