Aristos Queue

If LV were to fork (or CreateProcess or CreateThread or however you'd actually implement it) and then call the routine, wouldn't that be a pretty effective way to sandbox the call and make it abortable?

If LV ran the call in a separate process, would it be able to share memory? I don't think it can... even if LV allocations could be shared with the process, allocations from that process could not be shared with LV because those allocations would evaporate when the process exited. That would be a pretty hefty penalty for calling libraries if all strings and arrays triggered data copy.

The only real solution would be for all of LV's VIs to run in a separate process from the editor, something that other IDEs do but LV does not because historically it has introduced too many usability issues for which we did not have good solutions. Over the years, various solutions have been found, but at this point, the unity of the execution environment and the dev environment is pretty deeply built in and it would take a rewrite of a substantial part of LV to separate those.

Actually since about LabVIEW 8.2 they sort of are through the badly named Callback functions.

LabVIEW 7 didn't have that but CINS had a CINAbort function that could do that, if properly implemented.

I didn't count "signal-able" as the same as abortable.

Remove Frame is not implemented at all, not even internally. Pretty much all of our scripting operations are constructive, not destructive, so it doesn't surprise me that this got missed for so long.

The brand new Discovery Telescope uses a heavy amount of LabVIEW. LAVA user Paul_at_lowell is key to that project. For those who were at the USA 2012 CLA Summit, this is the telescope that was the motivation for the third user presentation in the morning. Looks like congratulations are in order based on today's slashdot article:

http://science.slashdot.org/story/12/07/23/2135258/discovery-channel-telescope-snaps-inaugural-pictures

"Two decades ago ... Discovery Channel teamed up with Lowell Observatory and embarked upon a $53 million adventure: the fifth largest telescope in the United States funded entirely without state or federal money. The very first photos snapped with its 16 million pixel camera are in and they look beautiful. Yet to be seen are the simultaneous spectroscopic and imaging observations that should be provided to researchers by the DCT's Ritchey-Chretien instrument cube. Located near a dark-sky site (Coconino National Forest), scientists hope to use this new telescope to answer many research questions including how our solar system formed and how dwarf galaxies evolve. For more telescope porn, check out the DCT's photo tours. Luckily 'the process of planning and building the telescope is due to be featured in a one-hour Discovery Channel documentary set to air in September 2012.' Perhaps there is hope for Discovery Channel to return to its former glory?"

Well done! Well done indeed.

The following post is an area I am *not* an expert in. Please contradict me if you know better...

asbo: I'm not sure if this is the case with this error, but my understanding is that many of the errors reported by DAQ are designed with real-time in mind where even in the error case they avoid allocating memory -- i.e., no strings in the error code clusters. This means that all you get is the static text that can be obtained from the error code number itself. Much of the DAQ code was written before there was a conditional disable structure, so special casing the behavior on desktop wasn't an option. I have seen some recently written VIs that behave differently and give more helpful errors in the non-RT case.

Bought my shirt. And tickets.

It seems I messed something up... this bug is not resolved in 2012. I thought I had it fixed. And it was a double mistake: I even managed to mess up the test suite function that would have told me that it wasn't yet fixed. I am sorry.

Relf: I expect you'll be skipping the NI Week keynotes, then?

Lordexod's solution isn't going to help you.

If the VI that you're wanting to run is the exact same as the one that you have in the static VI reference, then just get rid of the Open VI Reference node entirely and wire the static VI reference directly into the subpanel invoke node and the Call By Reference node. Update your Build Specification to tell that VI it to keep its front panel.

If the VI that you want to load is not the exact same as the VI that you're using in the static VI reference, and the VI is going to be outside the EXE, that's the only time that you have to use the path. Use this code for opening the VI reference:

The Application Directory function will be relative to your project file in the dev environment and relative to the EXE when you build.

No, CLNs were never abortable. Once you're out of LV's execution system, there's nothing LV can do but wait for the code to return control to us.

I figured by now you'd have fixed those FP terminals. Who can tell what they are without the icons? ;-)

You could use an XControl and monitor the 'Execution State Changed' event.

Hm... I was thinking in terms of monitoring any arbitrary VI, but this is an interesting approach. An XControl gets an event when the owning VI changes state, so if you put an XControl on the front panel of the VI you're interested in, that XControl could fire an event when the owning VI changes state. That avoids the overhead of polling.

The downside is that the XControl is going to force the front panel of the VI to always be in memory, which creates a performance hit when calling the VI since time is spent updating the front panel.

If the VI you're interested in is one that has its front panel visible, this is a good idea. You would create a user event in your monitor VI, pass that user event to the VI-of-interest, which would put that user event refnum into the XControl (probably through the FPTerminal). Then when the XControl gets the "owner went idle", it fires that user event.

You could build a polling loop that checks whether a VI is still running and then generates an event.

I'll be giving away one of these:

You say you don't detect the zero until after point 3... does that mean that you probed the cluster coming out of step 2 and in that probe you see data but you probe the values coming out of the Unbundle node and you see zeros?

My opinion is that version numbers should be able to be set to whatever we want, however.

That's nice. Would cause problems for data serialization.

I concur with Paul.

CRelf: It's not easy, but it is straightforward:

https://decibel.ni.com/content/docs/DOC-19176

I think it addresses exactly what you're trying to do. At the very least, there's info therein not covered by the other posts in this thread as far as I can tell.

Honestly, though, my question would be: Why are you using the "append prefix" feature? If you just stop doing that, everything works in your project. If you need a namespace to prevent collisions with some other version of your files that may be used simultaneously, put a library into your *source* and add all the files to that.

Seemed like a simple solution in the beginning though...

I know. Lots of things in the "load progress bar" project seemed like a simple, obvious solution. After six months of brainstorming and prototypes from members of the LV team, I'm now in the "there is no good solution so stop trying to force one" camp. :-)

I told someone to come to this page. "Just search for barbecue on LAVA," said I. They typed in "BBQ". Turns out that no where on the entire site do we use the keyword "BBQ" the search engine doesn't return any results for that term. I was amazed... I would've thought that would have worked. So, I am now posting this comment so that, at least for 2012, "BBQ" will get a hit when you search. :-) If you found this comment by searching, the post you're actually looking for to buy tickets is this one: http://lavag.org/top...niweek-bar-b-q/

[EDIT] Um... hold that thought.

A) I just searched for "BBQ" and this comment did not get found.

B) I just noticed that Justin's original post uses "BBQ" in the body text.

Something is not right with the searching.

I meant that I didn't think that any of those features were even compiled into the core LV and were installed by the modules, but I may be wrong.

That's what mje was talking about with the "lookup table".

Oops. I hadn't read the rest of the thread... I was posting from my phone so I didn't forget to tell Staab that idea.

I think the WebSockets is going to be the thing to use in a couple years. As for Web UI Builder using SilverLight, you gotta remember, when we started creating that, HTML5 not only wasn't a standard, it looked like it would never *be* a standard. SilverLight was the only game in town for cross-browser multimedia of any scale (Flash just didn't scale up enough when we tested it). We got caught on the cusp of a change of tech... and will now have to spend some effort retooling.

EnableFeaturesNotAvailableToAnybodyOtherThanL33tL4bV13WHax0rs=TRUE

I don't think that does anything unless you have the RT or FPGA modules installed.

I heard that dynamic dispatched vis has problem with separating compiled code so I wrote a script to exclude them.

Where did you hear that? It's not true.