Jump to content

LAVA 1.0 Content

Members
  • Posts

    2,739
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by LAVA 1.0 Content

  1. QUOTE (crelf @ Jul 20 2008, 11:36 PM)

    Doing so exposes a number of sweet UI properties that I didn't even know existed - so go ahead: check it out for yourself!

    PS: oh, and subscribe to Christina's blog too - then remind us all about the good stuff there so it doesn't take me a year and a half to find cool stuff like this :)

    PSS: ...and here's a bunch of other awesome blogs that you might want to check out too.

    Here's my LabVIEW OPML file.

    If you have Info-LabVIEW delivered into a special Info-LabVIEW label at gmail you can read those too.

    To setup Info-LabVIEW filtering I have the following filter:

    to:(info labview)

    deliverd to InfoLabVIEW.

    Ton

    OPML files are rejected by LAVA, here's the content as exported by Newsfox:

    <?xml version="1.0" encoding="UTF-8"?><opml version="1.0"><head>	<title>NewsFox OPML Export</title>	<dateModified>Mon Jul 21 2008 08:00:14 GMT+0200</dateModified></head><body><outline text="LabVIEW" type="NFgroup"><outline type="rss" text="LAVA" xmlUrl="http://forums.lavag.org/index.php?act=rssout&id=8" htmlUrl="http://forums.lavag.org/index.php?autocom=portal" NFuid="forums.lavag.org3" NFdeleteOld="true" NFdeleteUnread="false" NFautoCheck="true" NFstyle="0" NFstorage="false" NFlastUpdate="Mon Jul 21 2008 07:57:19 GMT+0200" NFautoRefreshInterval="15"/><outline type="rss" text="LabVIEW" xmlUrl="http://forums.ni.com/rss/board?board.id=170" htmlUrl="http://forums.ni.com/ni/board?board.id=170" NFuid="forums.ni.com7" NFdeleteOld="true" NFdeleteUnread="false" NFautoCheck="true" NFstyle="0" NFstorage="false" NFlastUpdate="Mon Jul 21 2008 07:57:34 GMT+0200" NFautoRefreshInterval="15"/><outline type="rss" text="OpenG" xmlUrl="http://forums.openg.org/index.php?act=rssout&id=1" htmlUrl="http://forums.openg.org/index.php" NFuid="forums.openg.org" NFdeleteOld="false" NFdeleteUnread="false" NFautoCheck="true" NFstyle="0" NFstorage="false" NFlastUpdate="Mon Jul 21 2008 07:57:40 GMT+0200" NFautoRefreshInterval="15"/><outline type="rss" text="BreakPoint" xmlUrl="http://forums.ni.com/rss/board?board.id=BreakPoint" htmlUrl="http://forums.ni.com/ni/board?board.id=BreakPoint" NFuid="forums.ni.com8" NFdeleteOld="true" NFdeleteUnread="false" NFautoCheck="true" NFstyle="0" NFstorage="false" NFlastUpdate="Mon Jul 21 2008 07:57:35 GMT+0200" NFautoRefreshInterval="15"/><outline type="rss" text="technically speaking" xmlUrl="http://lvtechspeak.blogspot.com/atom.xml" htmlUrl="http://lvtechspeak.blogspot.com/" NFuid="lvtechspeak.blogspot.com" NFdeleteOld="true" NFdeleteUnread="false" NFautoCheck="true" NFstyle="0" NFstorage="false" NFlastUpdate="Mon Jul 21 2008 07:57:28 GMT+0200" NFautoRefreshInterval="15"/><outline type="rss" text="InfoLabVIEW" xmlUrl="https://mail.google.com/mail/feed/atom/InfoLabVIEW" htmlUrl="http://mail.google.com/mail" NFuid="mail.google.com" NFdeleteOld="false" NFdeleteUnread="false" NFautoCheck="true" NFstyle="0" NFstorage="false" NFlastUpdate="Mon Jul 21 2008 07:57:19 GMT+0200" NFautoRefreshInterval="15"/><outline type="rss" text="Ideas in Wiring" xmlUrl="http://feeds.feedburner.com/IdeasInWiring" htmlUrl="http://ideasinwiring.blogspot.com/" NFuid="feeds.feedburner.com" NFdeleteOld="true" NFdeleteUnread="false" NFautoCheck="true" NFstyle="0" NFstorage="false" NFlastUpdate="Mon Jul 21 2008 07:57:16 GMT+0200" NFautoRefreshInterval="15"/><outline type="rss" text="Charles On Software" xmlUrl="http://www.charlesonsoftware.blogspot.com/atom.xml" htmlUrl="http://charlesonsoftware.blogspot.com/" NFuid="www.charlesonsoftware.blogspot.com" NFdeleteOld="true" NFdeleteUnread="false" NFautoCheck="true" NFstyle="0" NFstorage="false" NFlastUpdate="Mon Jul 21 2008 07:57:28 GMT+0200" NFautoRefreshInterval="15"/><outline type="rss" text="Open Measurements" xmlUrl="http://beta.blogger.com/feeds/4273799050747704870/posts/full?alt=rss" htmlUrl="http://openmeas.blogspot.com/" NFuid="beta.blogger.com" NFdeleteOld="true" NFdeleteUnread="false" NFautoCheck="true" NFstyle="0" NFstorage="false" NFlastUpdate="Mon Jul 21 2008 07:57:32 GMT+0200" NFautoRefreshInterval="15"/><outline type="rss" text="Eyes on VIs" xmlUrl="http://eyesonvis.blogspot.com/rss.xml" htmlUrl="http://eyesonvis.blogspot.com/" NFuid="eyesonvis.blogspot.com" NFdeleteOld="true" NFdeleteUnread="false" NFautoCheck="true" NFstyle="0" NFstorage="false" NFlastUpdate="Mon Jul 21 2008 07:57:33 GMT+0200" NFautoRefreshInterval="15"/><outline type="rss" text="VI Road Show" xmlUrl="http://feeds.feedburner.com/viroadshow" htmlUrl="http://viroadshow.blogspot.com/" NFuid="feeds.feedburner.com1" NFdeleteOld="true" NFdeleteUnread="false" NFautoCheck="true" NFstyle="0" NFstorage="false" NFlastUpdate="Mon Jul 21 2008 07:57:33 GMT+0200" NFautoRefreshInterval="15"/><outline type="rss" text="JKI Software Forums" xmlUrl="http://forums.jkisoft.com/index.php?act=rssout&id=2" htmlUrl="http://forums.jkisoft.com/index.php" NFuid="forums.jkisoft.com" NFdeleteOld="true" NFdeleteUnread="false" NFautoCheck="true" NFstyle="0" NFstorage="false" NFlastUpdate="Mon Jul 21 2008 07:57:21 GMT+0200" NFautoRefreshInterval="15"/><outline type="rss" text="Thinking in G" xmlUrl="http://thinkinging.com/feed/" htmlUrl="http://thinkinging.com" NFuid="thinkinging.com" NFdeleteOld="true" NFdeleteUnread="false" NFautoCheck="true" NFstyle="0" NFstorage="false" NFlastUpdate="Mon Jul 21 2008 07:57:16 GMT+0200" NFautoRefreshInterval="15"/><outline type="rss" text="ExpressionFlow" xmlUrl="http://feeds.feedburner.com/Expressionflow" htmlUrl="http://expressionflow.com" NFuid="feeds.feedburner.com2" NFdeleteOld="true" NFdeleteUnread="false" NFautoCheck="true" NFstyle="0" NFstorage="false" NFlastUpdate="Mon Jul 21 2008 07:57:21 GMT+0200" NFautoRefreshInterval="15"/><outline type="rss" text="LAVA wiki - recent" xmlUrl="http://wiki.lavag.org/index.php?title=Special:Recentchanges&feed=atom" htmlUrl="http://wiki.lavag.org/Special:Recentchanges" NFuid="wiki.lavag.org" NFdeleteOld="true" NFdeleteUnread="false" NFautoCheck="true" NFstyle="0" NFstorage="false" NFlastUpdate="Mon Jul 21 2008 07:57:43 GMT+0200" NFautoRefreshInterval="15"/><outline type="rss" text="OpenG wiki - recent" xmlUrl="http://wiki.openg.org/index.php?title=Special:Recentchanges&feed=atom" htmlUrl="http://wiki.openg.org/Special:Recentchanges" NFuid="wiki.openg.org" NFdeleteOld="true" NFdeleteUnread="false" NFautoCheck="true" NFstyle="0" NFstorage="false" NFlastUpdate="Mon Jul 21 2008 07:57:43 GMT+0200" NFautoRefreshInterval="15"/><outline type="rss" text="LAVA CR" xmlUrl="http://forums.lavag.org/downloads.html&rss=1" htmlUrl="http://forums.lavag.org/index.php?automodule=downloads&req=search&code=last_ten" NFuid="forums.lavag.org" NFdeleteOld="true" NFdeleteUnread="false" NFautoCheck="true" NFstyle="0" NFstorage="false" NFlastUpdate="Mon Jul 21 2008 07:57:43 GMT+0200" NFautoRefreshInterval="15"/><outline type="rss" text="LAVA Community Blog List" xmlUrl="http://forums.lavag.org/blog-rss-feed-b.html" htmlUrl="http://forums.lavag.org/index.php?automodule=blog" NFuid="forums.lavag.org2" NFdeleteOld="true" NFdeleteUnread="false" NFautoCheck="true" NFstyle="0" NFstorage="false" NFlastUpdate="Mon Jul 21 2008 07:57:45 GMT+0200" NFautoRefreshInterval="15"/></outline></body></opml>

  2. QUOTE (Omar Mussa @ Jul 19 2008, 11:48 AM)

    I have no idea how to check an OS scheduler to see which VI is running. I guess I only care about Windows apps in my case.

    Here is my goal... I have a state machine UI. I want to be able to run a supervisory VI that monitors the state machine and can log every VI that was actually run/called (as opposed to just being in memory) until the state machine completes. I was just about to give up on this but then I realized that the LabVIEW VI Profiler basically does what I need to do (and more). Unfortunately I am not sure how it does this... Any ideas? (Is it checking the OS scheduler? -- that would be surprising since it would mean there would be a different flavor of the VI Profiler for each LabVIEW OS version supported).

    THanks, so you really just need to know after the fat and not durring...

    [Pushing my knowledge = True]

    All of the debugging and profiler stuff seems to be built into the under-lying C code. Even poking around in prvicate methods only let you turn stuff on-and off.

    [Pushing my knowledge = False]

    The Trace Execution Toolkit is something I have only used in the RT environments but is supposed to run under Windows now. It works by putting hocks into all of the code before you run it and will produced detailed reports of everything that called when for how long and also gives you an idea if anything goes idle waitng for memory management. That toolkit may be helpful.

    Ben

  3. QUOTE (Maca @ Jul 19 2008, 07:02 AM)

    That link does not appear to be working!

    The server keeps timing out.

    ni.com was getting a lot of upgrades this weekend, so some of the systems were offline at times. The link is working now.

  4. QUOTE (Norm Kirchner @ Jul 18 2008, 05:34 PM)

    Damn.... this is harder than it seems at first.

    Sure is!

    If you are looking for gloabl solution that finds which of all of the VI's in memory are running, (note: there maybe more than one running) it seems you would have to interact with the OS's scheduler to do that since LV utilizing the OS to schedule VIs and for that matter the multiple possible threads within each VI.

    The only other thing that I feel is worth mentioning is the "skip if busy" option availabe for VI's marked as sub-routine. When a subroutine VI is dropped on a diagram, it exposes an option called "skip if busy". This option is the one and only exception to the data flow paradigm in that when that option is selected AND the VI is alredy executing, the sub-VI call will be skipped. If there any return values expected from the VI that was skipped, LV will use the "default" for the data type (Note the default as defined by the sub-VI will NOT be returned since LV would have to access that VI to know that and since its being skipped LV does not know that).

    So...

    If the VI in question is structed like an AE you could call it using a "check method" that returns a true boolean. If you try the "check" and it returns false, the VI was skipped because it was busy.

    Those are the only thoughts I can offer.

    Anyone else have thoughts on this matter?

    Ben

  5. QUOTE (Daklu @ Jul 17 2008, 09:21 PM)

    I have a test system with an NI-7340 motion control card and a 3-axis robot. I'd like to do dev work on my computer but need to execute code on the test computer. Since I am frequently executing code during development I was wondering if there's a way to expose the motion controller in the test computer as a network resource available to my dev computer? I couldn't find anything along those lines in NI-MAX. I looked at Remote Front Panels but that appears to be geared toward finished applications rather than developing them. Remote desktop is an option, but its too slow for working in a graphic intensive dev environment. Any ideas?

    If that device was supported by traditonal DAQ then RDA may help.

    Ben

  6. QUOTE (normandinf @ Jul 14 2008, 10:17 PM)

    I recently opened my LabVIEW.ini file and found these two keys:

    [LabVIEW]

    RecentFiles.projectPathList=

    RecentFiles.pathList=

    Are the private methods just calls of Configuration Files VIs? Or does it take the info from registry or some other place?

    I think they will read the INI file

    Ton

  7. QUOTE (Thang Nguyen @ Jul 17 2008, 06:11 PM)

    There is not this property.

    I tried to use the front panel data binding, but these shared variable control didn't generate the event when they are changed value through the modbus. I stuck T_T

    Yup! you are correct.

    Then query this shared variable history based on the shared variable value returned by the event. Can anyone think of a better approach?

    Ben

  8. QUOTE (Yair @ Jul 17 2008, 07:10 PM)

    I don't have LV in front of me at the moment, so I can't look at your code, but you could try using the Mouse Down? event for the array and if allowed use the filters to modify the click to happen in a point which is on the array border.

    I don't think you can register the event for the array element directly, but you should be able to do this with dynamic registeration. You might be able to use the filter event to move the event to the array control.

    Whoah, that was hard to find. But you disabled the string control...

    Enabling the string control makes the right-click working (it already worked on the picture control).

    To disable selecting of the text (which is most likely why disabled it) you should filter for mouse-down? events on the array.

    To disable the changing of the mouse you should look for mouse enter and leave events and alter the mouse as desired.

    Ton

  9. Shane's Nugget on on using VISA to access USB devices (found on the dark-side)has branched into a possible universal USB driver architecture that may harness LVOOP to allow for adding other devices in the future.

    If you are interested in LVOOP and have any advise you can offer, it would be greatly appreaciated (by me).

    Even if you can't offer any assistance, you may find that thread interesting (if for no other reason just to laugh at us trying).

    Ben

  10. QUOTE (Tim_S @ Jul 16 2008, 08:05 AM)

    My understanding is that reading a control or setting an indicator switches to the UI thread. ...

    Tim

    I used to think the same but reading and writting controls and indicator do NOT require a switch to the UI thread. I can't quickly cite proof but I beleive CRELF was involved in the thread were this was settled once and for all (well maybe not all).

    CRELF,

    Do you remember the thread?

    Ben

  11. QUOTE (Götz Becker @ Jul 16 2008, 03:20 AM)

    I guess I didn´t take enough time to write me question in the first place. First my in case I doesn´t use indicators inside structures, just a control.

    post-1037-1216192355.png?width=400

    post-1037-1216192366.png?width=400

    I am just not sure if and why LV would optimize the lower solution better. It´s not that important just something I wondered about :)

    The inplace structures are new enough that I can't speak specifically about them but as I undersand this code guide-line intent...

    When LV has decide how it has to pass data to a sub-VI it first tries to do it as effciently as possible. Since copying data (particular large arrays) is time consuming, it tries to avoid doing so. It can avoid copying the data if the data is not modified in the sub-VI. But how does it know if the sub-VI modifies the data? The sub-VI itself can let a caller know it is not going to mod the data. THis condition is possible if the controls indicator that are on the icon connector are located on the root of the block diagram.

    I look at it this way. The caller can look into the sub-VI only as far as the root of the diagram. If it can see the data will not be modified, it only passes a ref to the buffer holding the data in the calling VI.

    If you run your two VI examples through the same benchmark test I post in the thread on the NI forum, you MAY be able to see a slight differnce in the two methods.

    Ben

  12. QUOTE (mballa @ Jul 15 2008, 09:35 PM)

    I could set this up as the next coding challenge but I would need volunteers to help with the judging. If anyone is interested in judging and or participating please respond to this post. This sounds like a great NI WEEK topic over a few beers.

    Thanks Aristos you are still my Hero.

    This is a good idea. I don't have that many experience in LVOOP, but I could help judge.

    Ton

  13. QUOTE (Cat @ Jul 15 2008, 07:27 AM)

    I'm harsh. :-) I've already disabled labview.exe access since my development laptop only runs in the lab (or under the Deep Blue Sea). It seems the problem is that LV is still trying to get out, anyway, so I'm guessing you're right; there is some ini setting or something I need to turn off.

    I'm definitely activated. LV is one of the few software packages I'm anal-retentive about licensing and activating.

    This slow-down happens on both old mass compiled code and brand new vis. And whether I've got a couple vis up or my 1800+ vi monster project loaded.

    For the moment I'm just running with my network cable unplugged. But that's obviously not a long-term solution.

    Does this happen an plain vanilla VIs as well?

    I seem to remeber reading about LV trying to actively refresh VISA and DAQmx controls with valid selections, so it goes out and tries to find all networked and hardware widgets.

    I don't remeber if it was shutting down "automatically refresh" in MAX and/or an ini token.

    Well that's all I can offer.

    Ben

  14. QUOTE (Götz Becker @ Jul 15 2008, 08:20 AM)

    I just had a usecase in which I needed to update a nested element of a large structure. This involved 4 inplace (unbundle, array index, variant, unbundle) structures to get to the point where I needed the data from the control. The placement "felt right" in there... I just was curious about how "good" this would be.

    As I understand the thread cited by Antoine, that advice applies to sub-VIs and is of importance to help LV optimize the passing of data to and from the sub-VI call.

    If the VI is a GUI element and you need to get the control value while in the loop, then that is were it has to be. But if the control is static while the loop is running, then I BELIEVE its better to read the value once before the loop starts and just deal with the value as if its a constant inside the loop.

    Ben

  15. QUOTE (Aitor Solar @ Jul 15 2008, 08:17 AM)

    I know, but that doesn't explain why it works in the development environment and not in the executable. And I can't see why it shoudn't work, anyway: first I set the port I want to use (while the server is off) and then I activate the server through that port. In fact, seems to be more logical for me than the other way (first activate the server through a default port and then changing that port). What if there's already some application using the default port? It will launch an error before you can change that port to avoid conflicts.

    Saludos,

    Aitor

    I don't have a good reply but here are my first thoughts.

    IN the dev env the port may already be active for LV reasons.

    Set "ignore errors inside node" to let the property node complete before returning the error.

    Done thinking,

    Ben

  16. QUOTE (Michael_Aivaliotis @ Jul 15 2008, 02:03 AM)

    I'm impressed if I think that someone had to build this years ago...

    ...and I can't belive what risk they all take, you know there are those missing parts of concrete etc.

    You never know if there splits another part while you just walk :!:

  17. QUOTE (GraemeJ @ Jul 15 2008, 04:16 AM)

    In my original post, one of the things slowing down the code was that debugging had been left on in Simple Error Handler.vi. When the main.vi was checked with VI Analyser, this was not detected (LV 8.5).

    Regards, GraemeJ

    I assume you can instruct VI analyzer to ignore VIs inside vi.lib or user.lib.

    Maybe you need to add those directories as well.

    Ton

×
×
  • Create New...

Important Information

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