Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 09/21/2011 in all areas

  1. I recently took the CLA (on the 2nd of this month). My proctor did tell me they changed the format for the CLD in giving the front panel. That could have saved me a good 10-15 minutes back when I took it. For the CLA, I was given the sheet of requirements and a blank USB drive for submission. I thought the CLA was one of the hardest tests I've ever taken, mostly due to the 4 hour requirement. And for what it's worth, I got my results yesterday and I passed!
    2 points
  2. I would try out SketchBook Express and if you really like it the pro version is not so expensive.
    1 point
  3. This topic is incredibly timely for me, as I've been building my own tool to do this recently. On this topic, I have some bad news. But before that... Ravi, I liked your UI, so I integrated a few features I had in my app into yours. I hope you don't mind. Added: Tracking of execution highlight and ability toggle it on all selected VIs Tracking of paused VIs and ability to toggle pause on all selected VIs Selection of project/target Filtering of vi.lib Filtering of global VIs Filtering of control templates (.ctt) Sorting by library name Compressed the column text for some entries so more columns fit on the screen Here's the modified VI: LabVIEW Task Manager AQ Revision.zip Just a bit of tweaking and it can be added directly to the Project directory and launched from the Tools menu. Sorry... it's 2am and I'm not doing that extra bit of tweaking right now. Now, on to the bad news... I've spent the last week working on exactly this sort of tool, and I've had a series of problems that I could not solve. I looked at the Task Manager uploaded by Ravi Beniwal, thinking he might have overcome the issues somehow. His tool has the same bugs, though he may not realize it. After consultation with other LV R&D folks today, I can now say that these bugs cannot be fixed in LV 2011 or earlier. And I'm doubtful we can do anything about them in the time remaining for LV 2012 features. Two insurmountable problems I found... ----------------------------- First: Affects reentrant VIs. There is no effective way to get a list of the clone VIs... you know, the ones that are named "XYZ.vi:1" or higher numbers. These are the VIs that you often most need to abort, since one of the more common patterns in LV is to kick off reentrant clones running independently and then, when something goes wrong, you need to kill them. But you cannot get a list of all the reentrant clones that a VI has. You can open a VI ref to the clones by using Open VI Reference and passing a name in like "XYZ.vi:1". I tried checking each value sequentially until I got an error, only to discover that the numbers are not sequential. They can be any number up to MAX_Int32 (roughly 2 billion), so the "guess and check" method is out. ----------------------------- Second: Affects both remote VI Server calls and local Asynch Call By Ref calls. You can't abort subVIs. The Abort VI method will return error 1000 unless the VI is the top-level VI. So what's the problem? When you launch a VI using the Asynch Call By Reference using "Fire & Forget" mode, it launches as a subVI, even though it will keep running if its caller quits. That means that even if the VI is not reentrant, so you can get a reference to it, you still can't tell it to abort. And there is no way to get the caller VI because the caller VI is a fake proxy (you can see it in the VI Hierarchy window). When you launch a VI remotely using the Run VI method or ACBR, you also have a proxy caller that isn't abortable. ----------------------------- I've talked to multiple R&D staff with really deep knowledge of this issue, and there is no solution, and when I raised the topic was basically the first time that those involved collectively realized just how problematic this is to solve. I'd like to say something will be better in 2012, but that seems unlikely at this late date (yes, a month after 2011 released is late in our dev cycle; we do have to finish development pretty far in advance to get the testing solid). The best workaround solution is to build a mechanism into your reentrant and dynamically launched VIs that allows them to be messaged by some tool to stop them -- like if they use a queue, register that queue with a central data store somewhere that you could run to kill all those queues, which would make those VIs exit on their own. Unfortunately, that lead me to discover the third issue. There's no solution in LV to have code that is conditionally compiled in only when debugging is enabled on the VI. Code that registers the VI with the central system is useful while debugging, but probably shouldn't be there when you release -- it's only going to create performance overhead and take up memory. But you'll have to remove it manually before you build your application OR create a custom conditional disable symbol in every project you write. I find this solution distasteful at best. Anyway, that's my sucky news on the LV Task Manager front. I hope the edits I did add are useful.
    1 point
  4. With a reference to QD you have won my vote No, I think they are all valid points you have made to update the name 'if' it only accepts string input. Also a valid case for .lvlib namespacing.
    1 point
  5. FWIW this is a work around I use at the moment when I want a human readable file. Adding a non-type def cluster to group the items I want to flatten to disk Here is (part of) a Class API The Read From Disk method delegates read/writing to another object (so I can change file format etc...) In this example the Base File Class writes a config file (OpenG style) I have a reuseable VI from my own library: That is a wrapper for the OpenG VIs to guarantee certain functionality I can handle file versioning to (not shown here). In this example this creates a nice config type (settings) file. The cool thing about OpenG is that this supports inheritance - as long as the variable names are unique up the chain - I can write to the same section. I have found that MGI VIs do not allow this as they write the section as a string as opposed to key-value pairs (config API). I have to say using the native XML is much easier tho. ---- Jim have you done any prototyping of your idea?
    1 point
  6. Don't say I didn't tell you a way to make it faster. Personally I would not use subroutine priority in either case, I typically am satisfied with disabling debugging. I do however benchmark code using that setting, I found it to be the fairest and most consistent comparison. In completed code, I almost always find myself wanting to run subVIs standalone at some point.
    1 point
×
×
  • Create New...

Important Information

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