Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. I couldn't find this topic in the docs, not to say I didn't miss it, so if someone can point me to a doc or thread in the support form that would be great. I have a client with a computer that will never be connected to the internet, making it difficult to download and install the packages for VIPM. What is the easiest method to get the individual VIPM packages I need for this offline computer? I see I can go here: http://en.sourceforge.jp/projects/sfnet_opengtoolkit/releases/, and download what I need, one at a time. This method of downloading each OpenG package via sourceforge isn't the easiest, and I was wondering if there was something simpler. Since I already have all of the packages locally, because I have them installed, I went looking for the VIPMs on my hard drive, but it appears they are gone once they get installed. Any advice on how others have tackled this problem would be great. Thanks! -ben
  2. Thanks Jim, just wanted to make sure it made a bug list somewhere.
  3. I have VIPM all setup and working using LabVIEW 2009 x64, however I have a couple of VIs I need to open in LabVIEW 2009 x86. I figured this wouldn't be an issue, but when I open up my project in x86 LabVIEW all of the paths to the OpenG packages are broken/missing. Since VIPM is set to work with the x64 version of LabVIEW all of the OpenG toolkits were installed under c:\program files. However, when using the x86 version of LabVIEW all of the packages should be placed under c:\Program Files (x86), this isn't the case since VIPM doesn't know about this LabVIEW.exe. I figured this would be as simple as telling VIPM to also manage this LabVIEW.exe, however with the x64 version of LabVIEW registered I cannot add another LabVIEW 2009 exe to be managed. I receive the following error: "VIPM could not register the LabVIEW version because it is already registered." If VIPM would recognize that the two versions of LabVIEW are different I believe this issue goes away. Thoughts on how I could get around this? Thanks! -ben
  4. Hey Everyone, I have been creating a very simple package with one VI in it that contains our copyright notice. The copyright notice is just a free text label that is placed on the block diagram and the front panel. To build this package I am marking the VI as 'Place VI Contents' check box, however, after I install the package everytime I place the VI on the block diagram I get the VI icon and not the contents. I can go into 'Edit Pallet Set...' in LabVIEW and manual mark the VI as 'Place VI Contents' and I get the expected behavior, the contents of my VI, a text box on the block diagram and the front panel, is placed in the VI I'm working on. My setup: - Windows 7 x64 - LabVIEW 2009 x64 - VI Package Manager Community Edition 3.0 build 1280 Any thoughts? Thanks! -ben
  5. Error's tab eh? Doh. The 'Failures' tab didn't hit me in the face as something to go look at for failures. Switching from the main screen to a new tab to view the errors didn't fit into my work flow. I'll be modifying my work flow for VI Tester The 'Failures' tab is going to work fine, is there any way to format the text into something a little nicer/easier to read? Right now the error text goes off screen, the only way to read the whole error is to mouse over the text.
  6. Sometimes I only want specific output from the report window of VI Tester, i.e. I have 30 tests and I only need the failing message to be copied from one of those tests. I would normally take that error message and copy and paste it into a ticket and assign it to a developer. Currently I need to save the report file, open that file, find the error, and then I can copy and paste the error message. I would like to be able to highlight the text I would like out of the report window with a mouse/keyboard and either right click/use keyboard commands to copy the text to use elsewhere. -ben
  7. When a test fails where it should have passed, (i.e. I actually have an error)I would like to have the error code and source displayed in the text output at the bottom of VI Tester. If these elements were available here I could easily take the error output for the tests and share them with my development team instead of opening up each failing test and viewing the 'error out'.
  8. I have an instance where I have a test that I don't want to be run when I run the whole automated test suite. i.e. I have a test that is testing sending an email out to a user. To validate the test is running I actually have to go an look in my inbox to see that the email has arrived. This test isn't going to be run all that often, only when I am changing the code to perform the emailing. Since this test requires developer interaction to verify it has run properly, and since I don't want a ton of emails every time the test suite is executed I'll be setting the default behavoir for this test to 'skip'. What I'm looking for out of VI Tester is the ability to provide the 'skip.vi' a text description of why the test is being skipped that will show up in the output window of VI Tester. This way, when I come back to the test in six months, I attempt to run all the test, and I see a bunch of them being skipped I can just look at the output window of VI tester and remember, 'Yes, we skipped all of these test b.c. they require manual intervention.' -ben
  9. [cross posted: http://forums.lavag.org/Best-Practices-Inh...age-t13410.html] Goal: Create a set of packages that I can distribute to my team that we will use to start off every new project. Scenarios: I have a set of base classes that we are going to inherit from to generate new code for each new project. As an example, I have a database class. This class has all of the features to allow one to create, read, update, and delete (typical CRUD) and item to move into our out of the database. This base class describes the functionality and provides the API for the rest of the application to call, and based on the object supplied it will perform the proper operation on the database. This separation also allows for unit testing of the database interactions...I can mock out the database calls during the testing phase of the project if there is a common API for all CRUD for every object going in and out of the database. Motivation: In my world, the developer has a framework of where to put their CRUD and what VIs they need to overwrite to get their item into our out of the database. Now we have a framework where any developer on the project comes in, opens up someone else's code and goes 'where is the update call for foo1', they goto the class for 'foo1' and lookup the update.vi that has been overriden from the parent class. Each item that goes into our out of the database has their own CRUD VIs, since each item is different and needs to be inserted and queried from the database in different ways. Question: What is the best practice to inherit in a project a class that lives in a package? I have found through playing around I cannot inherit from a class in a package, that I actually need to create a VI (I've been calling it 'includes.vi') lay down a reference to the class in the package, and then I can inherit from it in the project. Is there a better way? Is this a common use of the Package methodology? Would I be better off sending out Project Libraries to my developers? -ben
  10. I actually went in under 'My Computer/Environment Variables' I changed the temp director to c:\temp...this sadly didn't fix my issue. I actually had a project structured like this: Project Library Class 1 Class 2 I was attempting to create a package with both Class 1 and Class 2 in the package. To do this I pointed at the directory in VIPM builder where I had the Library file and the two class files in separate directories below the current directory. This seemed to give VIPM real fits. Once I removed the Library reference in the project (I really didn't need it), everything built just fine. I'm a tad new to creating packages, what is the best practices for doing something like above? Should we not be using Libraries? I don't actually see a need for them in the project since I am making packages anyway.
  11. Jed, I'm running on Vista x64 right now with no issues...however one of the first things I did was turn off UAC. -ben
  12. I think I'm hitting the same issue... From the error .txt file: Source: D:\Reuse\Configuration\Classes\Configuration Template\Configuration Template.lvclass Target: C:\Users\benh.viewpoint\AppData\Local\Temp\VIPB Temp\Source Distribution\Configuration Template\_viewpoint_systems_lib_configuration_template.llb\Configuration Template__viewpoint_systems_lib_configuration_template.lvclass Admittedly my package name is huge, and I'll be trimming it in the short term to get around this issue. However is there a setting in VIPM where I can decide where the packages are going to be built? I.e. change the temp directory used by VIPM so I would have a much shorter path name?
  13. Omar, That's great it is on your radar, thanks for the quick reply. -ben
  14. Hey everyone, I'm not sure if this a bug or not, but the method that is shown in the video for test creation (open the example test, use 'Save As' to save a copy and add it to the class) works, as long as the VI Tester window is not open. For some reason if VI Tester window is open 'Save As' is grayed out on all of the test VIs. I'm on LabVIEW 8.6 Any thoughts to what might be happening, or is there any information I can provide that might help? -ben
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.