Jump to content

Justin Goeres

  • Content Count

  • Joined

  • Last visited

  • Days Won


Justin Goeres last won the day on November 28 2011

Justin Goeres had the most liked content!

Community Reputation

1 Neutral

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Cary, NC

Recent Profile Visitors

6,885 profile views
  1. Hi Eldon, Nice to hear from you! I hope things are going well in your neck of North Carolina , but I'm sorry that VIPM is causing you grief . You've discovered a bug in VIPM 2011.0.1's dependency resolution. It probably only affects a small number of packages, but unfortunately "FPGA IP Digital Buses" is one of them. We have reproduced the bug and are working on a fix, but I don't have a timetable for when it will be ready. In the meantime, the only workaround I can give you is to downgrade back to VIPM 2011.0.0. Click here to download the old installer. I apologize again for the trouble, and I hope downgrading (for now) isn't a huge hassle for you. If you need anything else please post back and we'll be glad to help. Justin
  2. Just a quick follow-up to this discussion. The TSVN Tool for LabVIEW has been updated to v2.2.0, fixing the issue discussed in this thread. Please see the update announcement on our blog here. If you are a registered user of the TSVN Tool for LabVIEW, you will also receive instructions via email about how to upgrade your "paid" version. If you don't get them, please contact me and I'll be happy to help you out!
  3. The TortoiseSVN Tool for LabVIEW has been updated to v2.2.0. Read the release notes here. To learn more about the TSVN Tool for LabVIEW, visit JKI's TSVN Tool pages.
  4. I apologize for the delay on getting support for TSVN 1.7 out the door. I understand your frustration, and I especially get that you can't really go to the trouble of downgrading if the fix is always "just around the corner." That having been said, an updated version of the TSVN Tool is just around the corner . It brings compatibility with TSVN 1.7 and will hopefully fix all your problems. It's currently in final testing and barring any more unforeseen circumstances it will be out in the next week or so. Thanks for your patience, and hopefully we'll have some good news for you soon. Regarding the forum notification problem, I'll poke around and see if I can get you some help on that, too.
  5. Hi Amiri, The reason for Error 1 in a situation like this is almost always that your Event Refnums are getting destroyed somewhere. Here's how things generally work. I'll try to explain it clearly, but feel free to ask for clarification if I screw something up: Your code calls Get Public Events.vi somewhere (probably when a loop registers for the events). Because this is the first call to Get Public Events.vi the event refnums are created and stored in a shift register (functional global-style). On every subsequent call, Get Public Events.vi just returns these already-created refnums. When your code generates a Public Event, it uses a VI called Generate Status Changed.vi (or similar -- it's specific to your app and your event). This VI calls Get Public Events.vi, which is how it gets the refnum for the event that it wants to generate. Later, when your application exits, it calls Destroy Public Events.vi (or similar, I forget exactly how the template is set up just now), which destroys the events. Note that after Destroy Public Events.vi is called, Get Public Events.vi will still return the same old cached event refnums, but those refnums will now be invalid and will result in Error 1 if you try to use them. Calling Destroy Public Events.vi out of sequence is almost always the reason for errors like this. It can sometimes happen due to slightly wonky error handling, where (for instance) an error in the module causes the "Macro: Exit" sequence to execute, which destroys the Public Event refnums, but then another error occurs during the Exit sequence which causes other dependent actions to happen. My top-line advice is to trace the execution of the module where you see this happening. Consider setting a breakpoint in Destroy Public Events.vi and some probes/etc. in your state flow so you can see exactly what's causing things to happen in the order they're happening. Your comment has gotten me thinking, though, that Get Public Events.vi should maybe do a better job of reporting errors. We know why Error 1 occurs -- somebody killed our refnums . It would be totally reasonable for Get Public Events.vi to throw an error when its refnums go bad, rather than just blindly passing them out and waiting for another part of the code to bonk. It's true that once you get one error, you'll get a lot of them -- the reason, of course, is that once those refnums are destroyed they're gone forever. On the bright side, though, this is definitely not a situation where you need to just delete and recreate code -- it's definitely a legit behavior that you can track down and fix, although actually tracking it down can be tricky. I apologize for dropping the ball on these. I saw your comment on the JKI blog a few weeks ago but it just slid off my radar -- I'll take another look at it. The comment on Jim's blog is one I just wasn't aware of. We need to do a better job of keeping an eye on these things, and I really, really appreciate you taking the time to run me down on this rather than just giving up! I hope that helps, and please get in touch if you have more questions. These forums are a good place, or the JKI blog post is fine, too. Thanks, and I apologize again for being hard to reach. Justin
  6. Hi Bob, When Jim posted back in March and said "don't go and buy 2.0 yet" he was referring (obliquely ) to a 35%-off upgrade coupon for registered users of EasyXML 1.0 that we were working on. You should've received your coupon code by email a few days later (the emails went out 2010-03-31). If you didn't get one, please email customer-service@jameskring.com and I'll make sure everything is taken care of. Thanks! Justin
  7. Hi dialooc, When you say "com port control," I'm assuming you're talking about the VISA Session datatype. EasyXML doesn't support the VISA session datatype directly. However, you can convert VISA sessions to and from strings. If you convert your VISA session to a string and use the string as an element in the cluster you're passing to EasyXML, it will work. If you have any trouble or if I'm misunderstanding, please reply and we'll help you out. Thanks! Justin
  8. What's New in VI Tester 1.1 VI Tester 1.1 is a minor release that builds upon VI Tester 1.0 and adds a programmatic API and LabVIEW project environment integration. All VI Tester 1.0 users should upgrade. New and Changed Features Programmatic API - The VI Tester Programmatic API is a set of VIs that allow you to run tests programmatically in LabVIEW and obtain test results. This is useful for running tests programmatically during an automated build process. Project Environment Integration - VI Tester now installs toolbar buttons in the LabVIEW Project Explorer window for opening VI Tester, running all tests in the active project, and adding new Test Cases and Test Suites to the active LabVIEW project. Resolved Issues 6869: VI Tester GUI does not correctly parse test class names that contain parentheses. VI Tester now parses test class names correctly when they contain parentheses. 6962: VI Tester Mass Compile Dialog does not always close when finished. VI Tester Mass Compile Dialog should now always close itself. 6919: JKI Labs splash screen sometimes stays open after VI Tester opens. JKI Labs splash screen should now always close itself. 6810: Order of Test Cases in VI Tester window is reversed from their order in the LabVIEW project. Improved ordering of Test Cases in VI Tester window. Known Issues 6811: Selecting 'New Test Case' from tools menu results in test case that is not front-most when launched from Getting Started Window Workaround: Open a 'Blank VI' before creating a Test Case so that the Getting Started Window closes. 6953: VI Tester palettes don't always update after installation for installations on LabVIEW >= 8.5 Status: Covered by NI CAR #148158. Workaround: Open VI Tester and allow it to mass compile itself. Then quit & restart LabVIEW and the palettes will refresh correctly. Release Date: March 2nd, 2009 VI Tester 1.1.2 is a bugfix release that addresses the known issues identified in VI Tester 1.1. All VI Tester users should upgrade to 1.1.2. Resolved Issues in VI Tester 1.1.2 6811: Selecting 'New Test Case' from tools menu results in test case that is not front-most when launched from Getting Started Window. Case 6953: VI Tester palettes don't always update after installation for installations on LabVIEW >= 8.5 Case 7056: Mass compile window resizes incorrectly Case 7057: Mass compile path window should be larger for Vista Case 7883: VI Tester cannot run UI if testCase includes test*.vit files. Template (*.vit) files are now ignored when creating VI Tester Tree. Case 8072: VI Tester UI does not support having multiple instances of a TestCase within a TestSuite (results will not be updated correctly on Tree). Multiple instances of a TestCase or TestSuite within a TestSuite is now supported. Case 9425: PassIfEqual.vi and FailIfEqual.vi error if numeric data type is used and 'Delta' input is unwired Release Date: December 1st, 2010 To download and install VI Tester 1.1.2, visit JKI Labs.
  9. VI Tester Release Notes Current Release VI Tester 1.1 Release Notes Past Releases VI Tester 1.0 Release Notes
  10. I'm sorry to hear that, but I'm happy that VIPM is useful enough to you that you're running into use cases like this! We've run into this situation inside JKI, too, and we've got some ideas about how to deal with it. We're working on integrating VIPM more closely with the LabVIEW project environment, just like we're doing with VI Tester (see blog post). That will probably include ways for VIPM to, for instance, remind you when you need to do things like scan your project for dependencies.
  11. Matt, I'm glad you're interested in VIPM for Linux! You found the correct answer on your own -- currently the only version of VIPM that supports Linux is v1.0. Incidentally, VIPM 1.0 only supports LabVIEW 8.2 and earlier. However, keep in mind that we recently announced that VIPM v2.0.3 is coming soon, and will include support for Linux & Mac. We hope you'll give it a try when it arrives. Thanks! Justin
  12. I have received confirmation from NI that we're good to go for the state machine talk at the Apex User Group meeting next Tuesday, 12/9. Official announcements will be forthcoming, but I wanted to let you know here.
  • Create New...

Important Information

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