Jim Kring
-
Posts
3,905 -
Joined
-
Last visited
-
Days Won
34
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Jim Kring
-
-
Thanks Jim
I get the crash as well for my 10.0f2 version,
It’sstrange that basic functions like this get changed from one version to another.
I hope they add this VI to their test suite before every released from now on.
Cheers,
Mikael
Mikael: LabVIEW 2010 introduced a variety of new compiler optimizations to take advantage of the new compiler architecture and DFIR. So, it doesn't surprise me too much that there are some issues in corner cases.
-
Update: This was assigned CAR#: 252210 by NI
-
[CAR#: 252210]
[Update: I just tested this in LabVIEW 2010 SP1 and it seems to be fixed
The CAR Number (252210) is also in the list of LabVIEW 2010 Service Pack 1 Bug Fixes. Thanks NI!]I found an odd LabVIEW 2010 bug that will cause a hard crash. The bug appears to be related to how LabVIEW operates on data in-place and some interaction between clusters, arrays, and the Aum Array Elements node. It's hard to describe verbally, so I'll just draw you a picture
-
Got VIPM on the brain much?
VMware ThinApp
Ya, just a little bit. I think my fingers were on autopilot
-
I got excited when I found VIPM VMWare ThinApp as a possible solution (it allows you to "record" an app installation and then package it up as a single file EXE), but then I looked at the price tag (~$6K).
[update: VIPM ThinApp -- haha!
] -
I've got a customer who can't install the run-time engine, due to this known issue and their IT dept is unable to resolve the problem. So, we have to find a solution that lets us run our application without having the run-time engine installed (for example, by including the run-time engine DLLs along with the built EXE).
I recall that several years back there was an NIWeek presentation by Kennon Cotton that documented how one could distribute a LabVIEW app on a CDROM and include the run-time engine DLLs on the CDROM (in a subdirectory beneath the EXE). Does anyone know if this is still feasible in LabVIEW 2009 or 2010? Does anyone happen to have a link to (or copy of) the documentation or presentation about this?
I'm going to keep digging for more info and will post whatever I find. I figured it would be useful to post here to see if anyone knows, off hand.
Thanks!
[update 2010-09-28: I just found the "Runtimeless Installer and LabVIEW applications" thread started by Jack Hamilton where he posted his presentation and example files, including Kennon's NIWeek presentation.]
[update 2010-10-01: We were able to successfully install the LabVIEW 2010 Run-Time Engine (it's not affected by the known issue) and decided to just build our application in LabVIEW 2010.]
-
NI created their repository using VIPM 2010 Beta, which expired after the beta period ended. We noticed the issue and fixed it right away -- it's all good, now.
I'm glad to see you're hard at work using VIPM on the weekends, Jon
-
I finally took the CLD exam at NI Week 2010... and passed. Yeepee!
A big thanks to all LAVAs for keeping me up to date in my programming style and best practices.
Congratulations! Next step: CLA
-
So, I've been working at home today, and LabVIEW has been an absolute slug of a beast when connected to my VPN. I think I tracked it down that it's because NI insists on keeping the LabVIEW Data location in the document root. If I disconnect from my VPN, LabVIEW runs like a champ, but as soon as I'm connected (meaning I'm no longer working off a local cached version of my documents, but a live remote version), LabVIEW freezes up for a split second every five seconds or so. If something large is being serialized, the IDE can freeze for up to the better half of a minute at a time. It's absolutely infuriating.
This results in a painful development process. I must disconnect my VPN all the time so I can use the IDE. But then I must reconnect so I can commit changes, etc, then disconnect, reconnect, disconnect, ad nauseum.
I mean really? Who stores information like that in the document root anyways? Why can't I put LabVIEW Data somewhere off my user root, like I don't know, in the LOCAL applications settings, which is where it should be anyways?
You should be able to adjust this in the options, as shown in the screenshot, below:
Cheers,
-
1
-
-
My guess would be to create a boot-strapper app that is written in something other than LabVIEW - that could check for the presence of LabVIEW RTE / any other dependencies, and then, call your main EXE once it's checks are complete. This could probably be neater still if the main application was compiled to a DLL target instead of an EXE - then your users would just see a single EXE / point of entry to the app.
(PS. I really hope there is a better way to actually get at the LV built exe's dialog directly, but I doubt that would actually be possible)
I don't know about changing the message, but in the past I have investigated checking the registry first (I was using a batch file to do it).
Thanks for the initial round of ideas, guys. I want to keep it as a single file, so I don't really like the idea of an extra DLL or a batch file.
-
Hey LAVA'ers,
Does anyone know of any tools or techniques to modify the error message that shows up when trying to run a built LabVIEW app, when the Run-Time Engine is not installed?
Thanks!
-
Jim,
It can never be said you are one to undersell :-)
Anything worth selling should not be sold short.
We've got several tricks up our sleeve, so stay tuned for NIWeek 2010...
-
How do I uninstall VIPM and the JKI TSVN toolkit?
Hey Val,
Wow, we never thought anyone would ever want to do that
But seriously, you can use VIPM to uninstall the JKI TSVN Tool (just find it in VIPM's package list and choose uninstall). You should actually do a Select All and uninstall all packages. And, you'll want to do this in every LabVIEW version that VIPM is managing.
Then, go into the VIPM options dialog and (on the LabVIEW page) uncheck every LabVIEW version in the list.
Then, close VIPM and choose (Windows) Start >> Programs >> JKI >> VI Package Manager >> VI Package Manager Uninstall.
BTW, you might not want to uninstall VIPM, yet. VIPM 2010 is going to be released soon and I have a feeling that you won't be able to live without it (because it's super awesome and will revolutionize the way we all share LabVIEW tools and add-ons)
-Jim
-
Can someone post the labview.lib file from the cintools directory from a LabVIEW 2009, 64 Bit for Windows installation? I need that to make some compile test for a 64 Bit version of the ZLIB Tools DLL, but haven't a 64 Bit machine handy where I could install the 64 Bit version of LabVIEW.
Here you go.
-
I'm porting some code to 64-bit LabVIEW 2009, and one thing that is not working is the OpenG Zip tools. It looks like the problem is that the .dll that the toolkit calls into is not executable in a 64-bit environment. This makes perfect sense, but I wonder if it would be possible to recompile lvzlib.dll to overcome this problem. Is the source code for this .dll available, or has this port already been done?
Best Wishes,
Matthew Harrison
Systems Engineer
Moore Good Ideas, Inc.
I'll ping Rolf K (main developer of the OpenG Zip Library) to see how much work this would take and if he has time.
-
Got my CLA exam results yesterday.
I PASSED!!!
Congrat's, Sergey!
-
Do you have your every-day configuration for controls and indicators set for Icon display?
No, it's a new LabVIEW installation and I've just been too lazy to go into the options dialog to change the settings.
-
Here is a link to the idea:
Thanks for checking this out.
-
At the risk of being struck down by lightning, I don't think I agree with this. If the reference is never used anywhere else, where should it be cached?
I would argue that it shouldn't be cached, by default.
As long as the vi is a preallocated clone (WaR is) there shouldn't be an issue.
Almost. Only as long as there are no dynamic calls in the call chain -- there is the possibility that dynamic calls using VI Server CBR nodes could cause the same WaR bug to appear.
Putting WaR inside a shared reentrant vi is (I think) essentially making that instance a shared clone, which is violating the (undocumented) terms under which WaR is expecting to run.
The difference between a bug and a feature can be debate without end. I don't want this performance "feature", because it causes a "bug" in my code. Since this constraint is not published, I feel it's a bug.
What happens if you make your shared clone dynamic dispatch vi a preallocated clone?
Dynamic dispatch VIs cannot be set to preallocated reentrancy -- it will cause them to be broken.
I'm not saying these aren't bugs. Undoubtedly WaR is leaking implementation details which is never a good thing (though often unavoidable.) I don't know that there's a suitable fix NI can implement.
Given that WaR is a preallocated clone, it seems to me the purpose of the shift register is to avoid excessive overhead in loops. I ran some timing tests of the current implementation against your proposed fix where WaR creates and destroys the internal notifier queue with every call. The current implementation averaged ~10us per iteration; without the SR it averaged ~32us per iteration. Not a big deal in most desktop apps. Could be a problem in RT apps.
I would argue that if there's a use case for a performance improvement whose implementation has constraints on modes of use, that this be made an optional, Boolean argument (named something like: reuse messaging queues for minor performance boost).
Cheers,
-
1
-
-
Actually, I'm pretty sure it was only in 8.6, so that excuse can't be used.
Could be... my memory queue is used in a lossy mode, occasionally
-
It's a Wait at Rendezvous bug, not a SEQ bug. Wait at Rendezvous, a vi shipped with Labview, does not always run normally in cases where no error occurred before the vi runs. Internally a rendezvous works using notifiers on a queue. Every time WaR executes, it obtains a new notifier and immediately waits on that notifier. When the number of notifiers meets or exceeds the rendezvous size, dummy data is enqueued on all the notifiers, releasing them to continue execution. If one of those internal notifiers happens to be closed, Release Waiting Procs throws an error which in turn prevents the notifiers from being put back on the queue, which then prevents all of the other rendezvous vis from being able to dequeue the notifiers.
I haven't yet figured out how Jim was able to invalidate one of the internal notifiers...
Here are my thoughts on why the internal notifier queues are going invalid.
1) The internal notifier queues are created inside WaR
1.1) WaR is reentrant.
2) WaR is called inside a reentrant Dynamic Dispatch Method VI
2.1) Reentrant Dynamic Dispatch VIs must use the Share clones between instances setting.
3) the reentrant Dynamic Dispatch Method VI is called inside several asynchronously running top-level VIs.
The problem is basically that specific instances of WaR are being called inside the call chains of several different top-level VIs. So, there's no way to gaurantee which call chain the cached internal notifier queue was created within (thus binding the queue's lifetime to the lifetime of the top-level VI).
Bottom line: never, ever cache a reference inside the shift register of a reentrant VI which is the creator of the reference.
There is no way to gaurantee that such a VI won't be called by a reentrant Dynamic Dispatch Method VI from multiple asynchronously running top-level VIs.
Now, in defense of whoever designed the refactored (with queues) Rendezvous, Dynamic Dispatch Method VIs didn't exist back in the 8.0 days (which is about the time when the Rendezvous, Semaphores, etc. were refactored with Queues, if memory serves me right).
-
I've posted a list of various bugs in the Rendezvous VIs (the root bug caused a couple other bugs to show up) on the NI forums, here:
I got some CAR numbers from NI:
CAR 222274, 222275 and 222276 respectively
-
I've posted a list of various bugs in the Rendezvous VIs (the root bug caused a couple other bugs to show up) on the NI forums, here:
http://forums.ni.com/ni/board/message?board.id=170&message.id=492924
-
I joined the crowd rushing after this strange element Hq. Seems like easy to learn/use.
When I was reading some introductions, I found that they warn to use it for large sets of binary data. Anyone yet experienced to say how it will work on real LV projects?
The other issue that still keeps me away from using it, is the merging process. As far as I understand Hq yet, merging is the very elemental interaction you would do. I'm stuck with a FDS, so no merging for me (except I write my own LV merge...). Will this be a show-stopper? Should I stay with SVN?
As a side-note, reading the manuals I discovered that it was my uncle who programmed the second SCC (and the first free one) called Revision Control System (RCS). I'm not sure if he is still into that...
Felix
CVS is built on top of RCS, BTW.
MGI General VIs
in LabVIEW General
Posted
He there! Sorry for the trouble, but I have good news
This bug (9665: VIPM shows errors when installing a package with read-only files inside) has been fixed in VIPM 2010.0.1. You can find out more info here: http://jki.net/vipm/release-notes
Regards,
-Jim