Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by TimVargo

  1. Shoneill, I have been looking at it, just no answers yet. I can see why the project file might be expecting different filenames -- I have the Package Builder automatically renaming all files to append "__LAVA_lib_LVTM" for namespacing purposes. I thought that this would have "updated" the lvproj file with the new filenames as well, but I guess not. But even still, I have yet to figure out why this should cause problems with simply running the tool (which has no need for the lvproj file). Any chance that this problem is local to just your own installation? Because no one else has reported
  2. I can no longer recall WHY I ended up building this package using the 2014 release -- I do remember making the decision to stick with VIPM v2013 unless I really had to upgrade for some reason, and yet it ended up in v2014 anyway. I think perhaps I installed v2014 because it fixed a particular IDNet bug that had been biting me, totally unrelated to this project. Perhaps during my next build of LVTM I will use virtualization to maintain a separate installation of VIPM 2013, just for this purpose. This package uses NEITHER pre nor post-install Custom Action VIs, which should make manua
  3. AQ: I've now read the release notes for LV2014 in full, but I see no mention of debugging-related improvements -- but then these are the extremely low-level type of changes that don't usually get a lot of publicity. Can you please share any insights into if any improvements in the debugging domain actually took place? I would love to leverage any, if they exist, into this tool.
  4. Hey Mark! I know this is a somewhat old thread, but it still contains valuable information. In fact, your utility that you describe to pass messages out of reentrant VIs for display in a message monitor daemon, sounds very useful even now. Do you still do it this way? Recently I've been working on adding enhancements to the LabVIEW Task Manager project, and I have been considering including this very functionality within that tool. It doesn't sound too hard to write from scratch; but if by chance you've been improving and tweaking it over the years, then why reinvent the wheel? Would
  5. When Rolf released 2.0.0beta-7 on 8-May-2014, this was the single line comprising the release notes: "extended the time the library will be allowed to run as beta to end of August 2014" Offline, Rolf told me that much internal testing was scheduled. I hope we will see a FINAL release before end of August; or at lease a beta-8, because it is a MAJOR headache for me if this breaks.
  6. hooovahh is correct, this package was built using VIPM 2014, and thus requires VIPM 2014 to install it. viSci: That VIPM error message is VERY POORLY worded and misleading! Also, when I upgraded to VIPM 2014 I did not have to manually uninstall 2013 first, it all went smoothly.
  7. I have made some additional modifications and then built this excellent tool (thank you very much to all code contributors) into a VIPM package. This tool is now at version, which is the immediate successor to R6. The VIPM package is available now in the LAVAcr at <http://lavag.org/files/file/245-labview-task-manager>. It should run on LV2010 and up. ENJOY! Here is the change list for v1.7.0: Inserted "Generate Clone Name", as supplied by Aristos Queue, to fix incompatibility w/ LV2013 clone enumeration. See <https://decibel.ni.com/content/message/58984#58984> A
  8. Version v1.10.0 (for LV2013+)


    LabVIEW Task Manager v1.10.0 (for LV2013+) This code is Open-Source, and free of charge Authors: Ravi Beniwal, Tim Vargo LAVA Names: Ravi Beniwal, TimVargo Contact Info: Contact via PM at the LAVA site (http://lavag.org) LabVIEW Versions Supported: LV2013 and up LabVIEW Versions Tested on: LV2017 LV2016 LV2013 Dependencies: GPower Error & Warning = lava_lib_tree_control_api >= 1.0.1-1 NI SmartBalloon = OpenG Application Control Library >= OpenG Comparison Library >= 4.0
  9. View File LabVIEW Task Manager (LVTM) LabVIEW Task Manager v1.10.0 (for LV2013+) This code is Open-Source, and free of charge Authors: Ravi Beniwal, Tim Vargo LAVA Names: Ravi Beniwal, TimVargo Contact Info: Contact via PM at the LAVA site (http://lavag.org) LabVIEW Versions Supported: LV2013 and up LabVIEW Versions Tested on: LV2017 LV2016 LV2013 Dependencies:
  10. Neil, I agree that several optimizations probably can and should be achieved here. I've looked at your code and I will just trust that you have already verified the logic and determined that the case conversions are unneeded. Even without running any iteration testing, I concur that removing the case conversions should be just fine. I've not used Variant Attributes in this way before, so I'm not really qualified to comment on your caching algorithm; but I do notice that you have not included the logic on how to determine if the dependency's name was found in the cache or not. I invite
  11. OK, so that clarifies the proper usage in my mind; but the wording quoted above makes it SOUND backward. I recommend clarifying that wording.
  12. Michael, >> Has this been submitted to the code repository? << The LAVAcr seems great for publishing complete solutions, but not so much for projects that are a work-in-progress; especially if several members are all making contributions in a short period of time (see early in this thread when Ravi had to ask others to allow him to "get a lock" on his very own project, so that he could merge in some new functionality. Brian, >> Any thoughts on creating a Bitbucket repository for this project? << Yes, my thoughts are that this would be a fantastic approach. I di
  13. GREAT IDEA! However, I'm confused. The rules listed at <https://bitbucket.org/lavag/about/wiki/Home> include these two: Preferably the code should be downloadable via the LAVA Code Repository Upload the build result (.VIP, .LLB or a zip) to the Files section of the repository on Bitbucket This sounds backwards to me. Shouldn't the source code reside on Bitbucket, so that Git and/or Mercurial SCC can be leveraged; and the build result placed on the LAVAcr?
  14. Eric, I have been (very slowly) working on adding some additional functionality to LVTM, and building it into a VIPM package. If you post your changes here, I will consider merging them into the package. No need for you to backport to LV2010 first, because I will be backporting the entire project from LV2013 to 2010 anyway before I build the package.
  15. I have edited the R6 version of LabVIEW Task Manager to fix the missing clones problem with LV2013, by calling the "Generate Clone Names.vi" provided by AQ (linked in the previous post). Before I publish the fixed project, please take a look at these screenshots, and tell me if this looks like the correct place to insert the new subVI. It does seem to work properly under LV2013, but I have not yet tested it extensively, nor yet tested with LV versions less than 2013. I at first expected the new subVI to be a drop-in replacement for an existing subVI, but no. Tim
  16. Ten MORE months later... A question for AQ: In this very thread, at this post here, you mentioned getting some specific support added into LV 2012 (unlikely) or later, that would greatly enhance the capabilities of this LabVIEW Task Manager tool, regarding aborting of subVIs (the second of your two "sucky news" issues). Well, now that LV 2013 released last week -- did any core changes get implemented to help solve this problem? I'm liking this tool very much! There are many ways to write good code that make it easier to keep track of many tasks, but where this tool really shines is
  17. I'll be there -- I just purchased my ticket!
  18. Thanks Rolf, I think that I can roll this in to my next iteration. Tim
  19. The document LuaVIEW Pre-processor keywords list several keywords which intrigue me, especially the ones such as --#version and --#description, which may be very useful for documenting scripts. However, I can find no mention of how to ACCESS these once they are assigned, or if that is even possible. I do understand that these are evaluated by the pre-processor with a main purpose of configuring LuaVIEW tasks, but --#version and --#description would certainly not be very useful for task configuration; so I am hoping that there is a way that I can grab their values and send them to a log file.
  20. I spent several hours last Friday on this, and was unable to get either of loadlib or require to find the DLL in the runtime (deployed) environment. However, while re-reading the LuaVIEW manual, I (re)discovered the statically linked "lv" library, which includes bitwise functions! This solved my original problem. Although it still bugs me that I should have been able to get a dynamically linked library to work, I will hopefully not need to do so again until I am up and running with LuaVIEW v2.0, which will probably make it much easier (due to the Lua 5.1 module system). Thanks for the help
  21. >> ... it didn't work properly without the compat-5.1 fix ... Ah HA! Those few words are probably the answer. I have never applied this fix. I will try this next week and let you know the outcome. THANKS! TimV
  22. Using LuaVIEW v1.2, I require the use of an external function library (BitOp <http://bitop.luajit.org/api.html>). I have already compiled it from C into a DLL, and my intent is to call a couple of its bit-wise functions from a Lua script, which is invoked from LuaVIEW, which is of course invoked from LabVIEW. The function call is working just fine on my development machine, which has a full LabVIEW development environment (v8.5.1), the full LuaVIEW package (v1.2), and a complete installation of the Lua interpreter (v5.0). The problem is that in the deployed environment (Win XP), the v
  23. Any news on how the LuaVIEW refresh is going? Still very quite at its own website.
  24. My second time to NIWeek, my second time to LAVA BBQ! Gonna be blast!
  • Create New...

Important Information

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