PeterB

Hi folks, Are there any examples showing how to write a LabVIEW executable which can act as an ActiveX Automation Server and support event callbacks from other languages ? e.g. within say a C# or .NET program, I want to do the reverse of what you see in the LabVIEW example here: C:\Program Files\National Instruments\LabVIEW 8.6\examples\comm\axevent.llb\ActiveX Event Callback for Excel.vi I would like an external client's callback code (accessing my LabVIEW ActiveX automation server) to be executed when I programmatically initiate the event from my LabVIEW code regards Peter

Hi Rolf, thanks for chiming in. When NI tells me I will get an "out of the box' experience, I may be prepared to accept that it must work within certain limitations on how much of their H/W I can change without having to resort to C-code edits. Clearly the out of the box sol'n didn't extend to permitting a 'simple' increase in the no. of rows in the LCD matrix. That may be OK in my case, but it wasn't in Shaun's. Perhaps if one needed more display flexibility it would be worth looking into the ADI blackfin out of the box option. I guess this is why they offer the demo version for about 5% of the cost of the non-time limited version, it gives you a chance to see what is possible. I have always been aware that programming anything except the ARM7 or Cortex-M3 will require C-code editing. I have and can code C if I need to but I'd also need to evaluate all the tradeoffs such as development time/dev system cost/ease of modifications etc etc. regards Peter Badcock Product Development ResMed Ltd

Shaun, Referring to this page, did the NI sales rep show you a Tier 1 or a Tier 2 evaluation board+device ? The Tier 1 devices apparently work "out of the box" - although that says nothing about UI configuration flexibility. BTW even if what you say is true re. the inflexibility of the UI vis, unfortunately I suspect there will be nothing on the NI site that explicitly says so. regards Peter Badcock Product Development ResMed Ltd

That's rather dissapointing Shaun. Was it an NI sales rep or some 3rd party rep ? Either way I hope they didn't know what they were on about. I naively assumed LabVIEW for ARM/Cortex would be more flexible than that. Anybody else used LabVIEW with ARM or Cortex care to shed light on their negative or positive experiences ? Was anybody satisfied with their "Out of the box" experience ? regards Peter Badcock Product Development ResMed Ltd

who wrot ehti NI evaluation kits with Hardware only have 'out of the box' solutions that work with an ARM7 or a Cortex-M3. I am interested in an NI "out of the box" solution supporting the ARM9 to minimise configuration time and increase my productivity. I recently emailed 'Jamie Brettle' (Product Manager for LV Embedded S/W) who wrote this article. and asked him if NI has any plans to release something for the ARM9 and here was his response: "Just to give some context in the choices of chips that we picked - given ARMs plans for the Cortex M line of processors, we anticipate that their performance will reach that of the ARM9 line while providing the benefits of the Cortex architecture (reduced power consumption, memory size). When this happens LabVIEW should be able to take advantage of this additional processing capabilities. I'm not sure of a timeline for that (both from NI's and ARM's perspective) but in the interim we will keep an eye on the requests from our customers to provide an out of box ARM9 experience. I will keep you up to date with any developments that happen." So if you have written LabVIEW code for an ARM9, how did you find the experience and would you have preferred an "out of the box" solution if it existed ? regards Peter Badcock Product Development ResMed Ltd

QUOTE (crelf @ Jun 4 2009, 02:30 AM) Chris, Greetings again from Magna Terra Australis (The Great South Land). I look forward to an archive of the presentation so I can continue my LV evangelism here at work with some authoritative backing. cheers Peter

QUOTE (mballa @ Jun 2 2009, 05:46 AM) Thanks for those examples Mark. Your sub-vi re-wire-er is a good example that you would clearly make use of. I'm sure it would come in handy in my toolbox too. If I was to write something like that perhaps it would take me at least 3-4 days and my initial thoughts are that I wouldn't recoup the time spent creating it with the time saved in using it. So while it is a 'nice to have' tool, I would only use it if somebody else (NI included) provided it for me. regards Peter QUOTE (crelf @ Jun 2 2009, 02:21 AM) I think it's because scripting is reall two things: the ability to create code on the fly (ok, not really many use cases for this, but they do exist) and exposure of previously private methods and properties on existing LabVIEW nodes, and it's the latter that I think will be more useful to most people. The create-stuff-programmatically part has be useful to me in the past (in fact, there's a few things I've done with it that I simply wouldn't have been able to do without it, and we certainly wouldn't have been able to complete a project or two), but you're absolutely right: it's not so much in my day-to-day architectures. The exposure of previous private methods and properties, on the other hand, is more common. Not that you need me to say it, but you're completely right: Its OK if you don't get too excited over scripting. Thanks for your ideas Chris. I look forward to discovering what private methods and properties NI might have exposed. cheers Peter QUOTE (Yair @ Jun 2 2009, 05:23 AM) Strictly speaking, that's not scripting. It's private functionality. I haven't looked at the license NI released yet, but it definitely won't include all private properties and methods NI has. Many of them will continue to stay private. I agree with Peter that most people don't actually need scripting (defined as "code able to read, edit and create other code") most of the time. Unless you're actively working on writing a tool which will handle LabVIEW code (like JKI's RCF), you will rarely need it. I think most people are excited for one of three reasons: 1. Most people are probably excited just because of the hype. It was hidden. Then it was locked. There were many discussions. Now it's easily accessible. As people will calm down, they will understand that they don't actually need it. 2. Some people actually need it for their own tools or will now be able to use stuff based on scripting that other people release. Thus, they're happy even if there is no HUGE direct gain. This covers most of the userbase and is a very good reason to be happy. I fall into that category. 3. Others might see this as an important point in the NI-community relationship. The community pushed, NI eventually listened. This becomes another step on the road NI has been taking. Thanks Yair, I think that is a good summary. regards Peter

I can't see the light .... I'm not as excited as everyone else seems about the possibilities of scripting yet and I've been an enthusiastic LabVIEW for 15 years now. How many text based programmers write code that writes its own code (let alone salivate over the thought of being able to do so) ? Perhaps they take the idea for granted and have never put their imagination to work. Certainly LabVIEW is now one step closer to being able to do what C++ can, but I'm not yet sold on the idea. What are folks really intending to do now with scripting that has such value ? You can talk about what you plan to do, but if you never allocate time to implement the idea then scripting isn't really all that valuable to you after all. Enough talk, how about you show me your really useful creations ! (I'll accept Auto wiring scripted tools only if they produce a similar wow factor to the BD cleanup feature !) I bet C++ could write a faster Hello World Program than LabVIEW could. Its OK if I don't get too excited over scripting. regards Peter QUOTE (hooovahh @ May 30 2009, 08:01 AM)

For completeness, I am listing the location of the new thread here , complete with CAR# and workaround. regards Peter QUOTE (PeterB @ Dec 17 2008, 03:01 PM)

CAR# 140034 QUOTE (PeterB @ Jan 12 2009, 10:55 AM)

QUOTE (GregG @ Jan 13 2009, 04:29 AM) I installed LV v8.6 PDS (under/with a VLA/VLM) and the first time I went to build my application I got the error. I don't have LVRT installed. My local NI app'n engineer told me there is already an associated CAR# but will get it to me later. Greg are you an NI employee ? What is your motivation for fixing the problem e.g. are you experiencing it too ? regards Peter

This post is to follow up from here where I reported that NIScanEngine\nilvce.dll couldn't be found during a build I was attempting. It was a non fatal error as the exe still built. NI gave me a solution by suppyling me with the missing directory and files (zipped up) which you install to here C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\NIScanEngine\ Unless NI have posted these files on their website, please contact ni.com/ask and ask for the application engineer to send you a copy of NIScanEngine.zip regards Peter

QUOTE (crelf @ Aug 9 2008, 12:59 PM) Blush. I stumbled across this thread when trying to solve another annoyance similar to the NIScanEngine problem outlined above. Long live the autotool !!! Every now and then I still try to convince another LV programmer at my work to use it... I'll might start another thread once I get a solution to my annoyance from NI. (short problem description: When building an app in LV 8.6, <vilib>:NIScanEngine\nilvce.dll is not found. The app still builds OK though) cheers Peter

QUOTE (jlokanis @ Jul 25 2008, 06:29 AM) Thanks John, I figured as much too. I think the concept of a shadow data structure that only propagates data to the FP on a less regular basis is a valuable idea which BTW has already been implemented in LabVIEW by disabling the Advanced>Synchronous Update option. Presumably that option is still too taxing for the speeds we/you are after otherwise you would be using it rather than the shadow structure. So perhaps if NI allowed us to adjust the priority of the asynchronous updates to a FP control/indicator so we could tune them for our particular application's speed needs. What do you think ? Then all the penalties associated with GUI refnums would be greatly diminished. regards Peter

Hi John, I have an observation and a question about your WORM. I'm assuming this has always been possible utilising the "First Call?" primitive inside a functional global variable to ensure that it could only get written to once. If that's the case, then yes you have proposed an elegant solution to reducing the programming overhead of a functional gobal to achieve the same thing. Does writing to a top level FP control/indicator using a WORM cause a switch to the UI thread in exactly the same manner as it would have if using the traditional approach ? (i.e. by wiring to the reference passed via a terminal on a sub-vi's FP). regards Peter

QUOTE(Michael_Aivaliotis @ Mar 9 2008, 06:51 PM) Is the following point the most important requirement they can muster to the top of their "Urgent problems in current programming languages" list ? If so then perhaps we should really feel sorry for them as they acknowledge their text based state of the art languages are still in the dark ages. 1. Programs should no longer be "written" It's time to finally overcome the antediluvian technology of software production using text editors. Programs should no longer be "written" but constructed/composed in Lego-like fashion from basic constructs, using structure editors rather than text editors. Particularly the executable portions of programs are the last bastions of textual programming that remain to be captured by "point-and-click" technology.

QUOTE(rolfk @ Jan 28 2008, 08:53 PM) Thanks for clarifying Rolf. One solution I thought of is to have another event structure on the BD that is entirely dedicated to User Events. Not as elegant, but that should solve any delay problems if one chose to use User Events rather than queues. Peter

QUOTE(rolfk @ Jan 28 2008, 07:48 PM) Does this mean that if a User Event is fired there could be times when it won't be serviced "as fast" as the enqueue/dequeue method ? If so, is that because the Event Structure may have previously switched to the UI thread before switching back to another (non UI) thread in order to service the User Event ? Peter

QUOTE(silmaril @ Jan 28 2008, 03:42 AM) Sorry to say , but Stephen Mercer seems to think otherwise ! Refer to http://forums.lavag.org/Event-Structure-as-State-Machine-t9502.html&st=15#' target="_blank">this post. regards Peter

QUOTE(TG @ Dec 12 2007, 01:41 PM) Ummm..... Nope. I really did get a 2nd set of Q3 Dev Suite disks and they were delivered about 1 week ago (the 1st set of Q3 disks came about 1.5 months ago). I'm not even sure why they delivered the Q3 disks a second time, . I think they meant to give me the Q4 disks instead, but fortunately they haven't yet. Peter

QUOTE(Michael_Aivaliotis @ Dec 12 2007, 05:51 AM) I have only just recieved a 2nd set of our 3rd quarter Dev Suite CDs. Thankfully NI was slower down-under for distributing the dev suite. Peter

QUOTE(i2dx2 @ Nov 13 2007, 11:59 AM) Done.

QUOTE(neB @ Nov 12 2007, 11:43 PM) The events "fires" in the UI thread. That does NOT mean the code for the event executes in the UI thread, only the "firing". Hi Ben, I now have an authoritative answer to my question from Stephen Mercer. Apparently the "Firing" of a User Event is not even done in the UI thread - as that would be considered a context switch which doesn't actually happen. There is however one exception - see below - copied from Info-LabVIEW. QUOTE -----Original Message----- From: Stephen Mercer Sent: Tuesday, 13 November 2007 4:25 AM To: Info-LabVIEW@labview.nhmfl.gov Subject: Re: Do user events run in the UI thread ? I forwarded your e-mail to the folks that own the Event Structure. I got this authoritative response: > User Events do not cause thread context switches. > The only exception is if you use the Register Event Callback > node to register them, which always runs in the UI thread. To be clear, that's the Register node itself that runs in the UI thread. The event cases that are triggered by those registered events are still non-UI. Pojundery, Stephen R. Mercer -= LabVIEW R&D =-

QUOTE(Michael_Aivaliotis @ Nov 11 2007, 06:41 AM) Michael or anyone else, can you tell me if user events force a context switch into a UI thread ?? regards Peter

QUOTE(EJW @ Nov 10 2007, 06:08 AM) My turn to chime in here. First up can somebody please tell me whether firing off a User Event forces a switch into the UI thread or not ? Last time I tried to look up an answer I don't remember finding one. Now on to a case study highlighting why not to attempt a large/scalable progam with the arhitecture proposed in this discussion. A colleague of mine at work tried this approach with his second major LabVIEW project. I advised him against it for the reasons mentioned thus far. Additionally, instead of using User Events, he would change the value (property value:signalling) of one of many LEDs on the FP. I advised him against doing that because it would force a context switch into the UI thread, he said he wanted visibility of where his state machine was up to (I said there were other ways). Anyway, to cut a long story short, just yesterday he came back to me for advice when he discovered that his program slowed to a crawl and data was lost when any window was moved ! The data loss problem was solved by re-locating some code from an event structure case into another loop and also using a queue to transfer data between that loop and back to the event structure loop (rather than the LV2 global he was initially using. Hence the data loss problem was an issue unrelated to the Event Structure per say) however he still must live with the fact that code in the event structure isn't serviced as fast when somebody moves a window. In addition to those problems, he now needs to remember to ensure that every event case takes less than a certain amount of time (say 100ms or whatever it was) in order to keep it running smoothly. regards Peter