PeterB

Think about it!

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

It was an NI rep and the toolkit was "The Embedded Module for ARM Microcontrollers"

This is what it says in the sales blarb:

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

I was interested in the ARM deveopment toolkit and asked the sales rep to come in, demo it and leave it with me for a couple of weeks. Long story short, I didn't bother with the demo kit and he left with it.

The toolkit I saw was basically a C generator. there were limited vis that enable you to do certain things, but you cannot modify them. If you look inside theres nothing in them. When I asked (for example) "this matrix display demo, how do I modify it ?" He said you generate the c code and modify the c code to whatever you want

It looked to me like a C template generator that you then go into and modify in the C environment of your choice. You might as well either write in in C in the first place or give it to a C coder since they are 10-a-penny. The sales guy couldn't really come up with a good reason for me to spend £3K on a toolkit when we've got ten C programmers on the payroll.

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

Contact your local NI representative and look at this evaluation kit.

NI has support for ARM7, ARM9 & CortexM3.

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:

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)

I figure there will be a lot of ideas that will come out of the discussion portion of the presentation, so I'll commit to putting together a recorded version after NI-Week to include the extra stuff outside of our structure discussed on the day, and post it here to this thread.

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)

I have a fairly useful time saving creation that uses scripting found Here.

I've also created a few Screen Cast videos here

and here showing how it works.

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)

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)

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)

<charming music>

Say you have a generic DAQ system which needs inputs and outputs.

There's a script for that.

And say you want to make your programming life easier by adding tools which automate wiring up controls and indicators.

There's a script for that.

And say you just want to impress your friends, by writing the fastest 'hello world' program in existance.

There's even a script for that.

There's a script for just about any thing.

Only on LabVIEW

</charming music>

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)

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

CAR# 140034

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

This post is to follow up from http://forums.lavag.org/-t11544.html&view=findpost&p=55706' target="_blank">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 (GregG @ Jan 13 2009, 04:29 AM)

What were you using that required that dll? Some scan engine related VI? Did you have real-time installed? I'm trying to figure out how you got into this situation so that perhaps I can fix it.

thanks,

greg

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)

Old dog here too (LabVIEW 3) - but I can't live without the autotool now. Originally, I hated it, but a talented colleague whom I respect very much suggested I learn some choice keyboard shortcuts and just persevere with the pain for two weeks, and, sure enough, now it's second nature.

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)

If you are writing to the FP control, I suppose this always causes a UI thread hit since it is 'updating' the UI. The thing that is particularly bad is to write to the value property of a FP control using VI Server.

I have a general rule of thumb: Only write to FP controls when you *really* need to. For example, I have some UIs that use a tree control to display data. The temptation is to write to the tree all the time and let it 'store' the data. Unfortunately this is very slow. So, instead I have created a set of VIs that implement a 'shadow' data structure that stores all writes to the tree (including state changes, like cell colors).

........John

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)

• An experimental object-oriented rapid application development (RAD) language with parameterized ("virtual") types, refactoring, and extensive static checks.
  

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.

QUOTE(rolfk @ Jan 28 2008, 08:53 PM)

It means that the event structure might be serving an UI event at the moment the user event arrives and hence not be able to react immediately. A Read Queue waiting for an event to arrive will return instantly or at least as fast as possible, considering the contstraints of available CPU power and load only. Rolf Kalbemratter

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)

But they execute in a structure that also handles all the normal UI events that WILL switch to the UI thread for sure....

Rolf Kalbermatter

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)

Maybe the problem is due to something else.

It seems to me that queues can be handled in any execution system, but events are always handled in the UI thred. Even for firing a user event, LV has to switch to the UI thread.

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)

This is a joke right?

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)

You may be affected by this issue if you installed NI-DAQmx from the following Fourth Quarter 2007 Developer Suite or Software Reference Library media:

• Device Driver Reference CDs

• LabVIEW 8.5 Professional Development System and Device Drivers DVD

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)

Hi Pete - can you please find a place for this juicy little tidbid in the LabVIEW wiki?

Done.

QUOTE(neB @ Nov 12 2007, 11:43 PM)

QUOTE(PeterB @ Nov 11 2007, 07:03 PM)

Michael or anyone else, can you tell me if user events force a context switch into a UI thread ??

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

QUOTE(Michael_Aivaliotis @ Nov 11 2007, 06:41 AM)

To comment on User Events. I too am a fond user of them when it comes to interprocess messaging. They have many benefits but I don't think they should be use everywhere (Justin!).

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)

Exactly. Eliminate the Case Structure altogether. Use the "Lock Front Panel Events..." checkbox for built in events to keep those from firing and user events only fire when called anyway.

Example: Timeout Event--Waits for a digital input (from a PLC) to start a test (50ms timeout or whatever)

User Event: Acquire-- Acquires Data, calls next user event-Process

User Event: Process-- Process the data (calculations), calls next user event-Status

User Event: Status-- Determine Pass/Fail conditions, calls next user event-Display

User Event: Display-- Display results on screen, calls next user event-Record Data

User Event: Record Data-- Records data to a file, calls next user event-Output

User Event: Output-- Sends Pass/Fail and Test Complete signals via two Digital outputs to a PLC. calls timeout event

User Event: Error-- Can be called from any event where an error occurs to terminate the regular cycle, or could possibly return you to the normal cycle where it left off.

Now, if someone changes a setting which triggers an event to record the new setting in the registry, that will be queued up or if you set the mouse busy at the beginning of the acquire, then no one can change anything on the front panel and they have to wait to change a setting.

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

QUOTE(Justin Goeres @ Sep 25 2007, 11:54 PM)

Here is the problem: Any significant use of the receiving computer (switching applications or even just clicking in the window's title bar causes the receiving computer to return a "VISA Error -1073807252 (0xBFFF006C): An overrun error occurred during transfer. A character was not read from the hardware before the next character arrived." I have replicated the problem with both my laptop (USB->RS232 adapter) on the receiving end and with a desktop machine (old-school RS232 on the motherboard). This happens even with the simplest of serial read/write code (e.g. NI's examples).

Hi Justin,

I think your problem is solved by reading http://keyspan.custhelp.com/cgi-bin/keyspan.cfg/php/enduser/std_adp.php?p_sid=-S7T5JMi&p_lva=&p_faqid=403&p_created=1116093562&p_sp=cF9ncmlkc29ydD0mcF9yb3dfY250PTEwNyZwX3NlYXJjaF90ZXh0PSZwX3NlYXJjaF90eXBlPTMmcF9wcm9kX2x2bDECZwX3NvcnRfYnk9ZGZsdCZwX3BhZ2U9Mg**&p_li=' target="_blank">this article from Keyspan.

In short you need their high speed adapter, your Qi ain't designed to do what you want.

regards

Peter

"Over the years, Keyspan has made several adapters in the USA-19 line. The USA-19 line is defined as sb erial [A]dapters with [1] DB[9] port (these characteristics make up the part number [uSA-19]). The following information outlines the difference between each variant of the USA-19 line:

Product Name: USB PDA Adapter

Model Numbers: USA-19, USA-19x, USA-19Q, USA-19Qi

- - - - - - - - - - - - - - - - - - - - - - - - - -

The models in the USB PDA Adapter line (models USA-19, USA-19x, USA-19Q, USA-19Qi) were designed for connecting Palm Pilots, Wacom tablets, and other PDAs to Mac and Windows computers. These adapters only had enough serial capabilities to communicate with PDAs and graphics tablets and therefore using these adapters with serial devices that aren't PDAs or graphics tablets IS NOT RECOMMENDED (the USA-19HS is the recommended adapter for any serial device).

"