LAVA 1.0 Content
-
Posts
2,739 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by LAVA 1.0 Content
-
-
-
QUOTE(PeterB @ Nov 12 2007, 05:29 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.
</FONT>
I stand corrected!
Ben
-
QUOTE(Michael_Aivaliotis @ Nov 12 2007, 01:19 PM)
That link requires a login but your title gives me enough to go on. My son has been insisting for years that TV is dead and he goes on to say that "his generation" (25 years or less) looks at my generation and simply does not understand why we want to watch a movie or read a book since it always ends the same way. For him he sees the video game adventures were he influinces the out-come as much more interesting. So dad has been saying under his breath (yeah but the video games alway work out the same way too). Well that was I was saying before about two weeks ago. So when I was a wee-babe my parrents used to invite friends over and do the "slide shows" with 35mm slides. The reason i bring up the slides shows was the week before last my son showed me some of the saved images from Halo3 were he and his girl-friend/common-law wife had been working as team. Before long I thought I was back in my parents living room watching yet another slide show. Sure, instead the "kids next door" there were "brutes". So my son would agree with the topic of this thread. Hmmm..... I think I'll read The Tolkien series again from the begining (fro the fifteenth time), maybe this time it will end differently.
Ben
-
QUOTE(Neville D @ Nov 9 2007, 01:24 PM)
Aside from checking the http://digital.ni.com/public.nsf/allkb/7EFCA5D83B59DFDC86256D60007F5839' target="_blank">Nagle setting I would suggest you test performance using different block sizes.
Ben
-
-
I've got to admit it, I still miss the LAVA Lamp
An obvious kudos to Michael - as Yen said, it's been his baby form the start, and he had a vision that's going from strength. Mike started it off, but it's all the members that have really made it mature and grow into a daily staple for so many engineers and programmers across the world: great job everyone! :thumbup:
We've had an incredible growth in the LAVA family in the last couple of years with the addition of the LAVAcr, LabVIEWwiki and now LabVIEWSearch - now it's time to slow down a bit and take stock of what's really important: maturing those components so they also become integral parts of the LAVA family staple. Get your arses into gear and submit that code snippet or tool that you've been sitting on to the LAVAcr! If you've got a spare ten minutes waiting for a compile, hit the LabVIEWwiki and pick a page that's been marked as requiring updating or pages that don't exist yet. Don't be concerned if your LAVAcr submission or LabVIEWwiki editing isn't perfect - that's not what LAVA's about: it's about us learning from each other!
I'm not suggesting hours of commitment - every time your post, submit or edit, you're helping out the greatest independant LabVIEW community in the world!
-
It just gets better and better - the bar is lifted once again! Thanks so much to Michael and the team for even more unselfish support to the LabVIEW community, both independant and NI-based :thumbup:
-
QUOTE(Anders Björk @ Nov 11 2007, 10:14 AM)
It sounds like you could use an http://forums.ni.com/ni/board/message?board.id=170&view=by_date_descending&message.id=240328#M240328' target="_blank">Action Engine to do the syncronization. The AE could have a SR to hold the most recent set of readings across the board. AS each of the sub-systems receive their measurements, they use an appropriate action to update the fields held in the SR. When the consumers of this data need to know the current values they read from the AE.
Ben
-
-
-
QUOTE(neB @ Nov 11 2007, 12:20 AM)
Since I have a customer is paying for this work as part of a big project and they have not received the results yet, it would be wrong to post the code now.Why? I'm not asking you to upload your customer's code - just a snippet (something simple created from scratch would work) that demonstrates the issue.
-
-
QUOTE(i2dx @ Nov 10 2007, 11:16 PM)
QUOTE(Yen @ Nov 11 2007, 02:38 AM)
P.S. You can only trade your user name once every 60 days. You don't suppose Mike will make an exception for you, will he?
Ahhhh crap - you're right! Oh well, I can be German for a couple of months
"Springtime for crelf and Germany..." -
-
QUOTE(PeterB @ Nov 9 2007, 10:00 PM)
Property nodes do executes in the UI thread.
Back to the subject of of the thread.
Events are great for responding to things that can happen at any time.
State Diagrams are wonderful for structuring complex processes.
Quoting from Ode to a State Diagram;
"
SD's and event structures do work together but "These things must be done delicately" (Wicked Witch, Wizard of Oz).
"
I avoid embeding one n the other. Everything I can do fast (<1 sec) I try to do in the event structure. If I have some process that will require more than a second, I'll use a second process to take care of the on-going actions so I can keep the UI snappy.
THe second process are generlly implemented as state machines. They watch for commands that control their state. All background process of this type should avoid tight loops that do not have a check for an abort or exit. More often than not the commands from the UI are transfer using queues, stuffed by the UI and read by the the background process.
If there are settings or parameters that have to change on the fly, Action Engines are an efficient vehicle.
Using the State Diagram Editor to develop the background process has a lot of plus.
Most of what I wrote in Ode to a State Diagram is still true today (well in my book
). I am excited about what the State Chart tool can let me do. I tested it a little but have not had a chance to aplly it in an application yet. The big thing holding me up on the SC is it an implementation of UML. I don't know UML so I get lost in the help. :headbang:
I have started to read an introduction to UML but that takes time.
So for the time being, the SDE is still a big tool for complicated algorithms.
Ben
-
QUOTE(i2dx2 @ Nov 9 2007, 11:31 AM)
...Ben: can you please upload the VIs you used to do the benchmarking ro keep all of the thread items together?Since I have a customer is paying for this work as part of a big project and they have not received the results yet, it would be wrong to post the code now.
I am concidering writting a Nugget to document my adventures in performance-land after the data and systems have been delivered.
Ben
-
-
In the future maybe I should keep these tidbit secret.
To be able to measure the difference between calling a sub-VI with spare terminals and a sub-VI with no spares, was no easy task and has a strong resemblance to creating a topographical map of your naval.
To conduct this experiment we used a PXI-1042 chasis with the following modules.
PXI-8106 Dual core
PXI-6653 Timing control
PXI-6608 Counter
We used the oscillator of the of the 6653 to drive the DDS and prouduce a 80MHz reference clock. The 80 MHz clock was then routed to Clk Out and then cabled back in to the Clk In of the 6653. The Clk In was then routed to the PXI balckplanes star lines.
The 6608 was then set up to count based on the clock from the PXI backplane.
In other testing (not shown here) we measured how often we can read from the counter and those measurements showed that the CPU could read from the counter every 4.4 microseconds.
We then constructed the diagrams shown below (Exact = only as many connections on icon connector as required. Spare = extra un-used terminals)
A timed loop was used to "hold the test code" and to allow us to specify in which of the two CPU's the code runs. (Note: this was done because overhead routines apparently run on CPU "0" and will interfere with the mesurements. This "inference" manifests itself as a high standard deviation in the loop times "jitter").
The test code begins by allocating two buffers who's size is the same as the "loop Iterations" Control which was set to "1" for these tests. (Note: "Show buffer allocations indicated that the buffers were NOT being copied and the sub-VI were working in the buffers created by the "init arrays".)
After the allocation of the buffers, the timing scheme described earlier was configured and started.
The code the repeatedly calls the sub-VI's which are simple No-OP for loops that iterate the number of times indicated by "Loop iterations", again "1" and return.
After calling the sub-VI the specified number of times the couter was again read.
The difference between the counter values (scaled as ms as indicated by the clock rate) was then used to determine how long it took to cal the sub-VI the specified number of times.
Repeated testing showed that the sub-VI calls to a sub-VI with only as many connectors as we needed were consistantly faster.
The difference was approximaly 8 nanoseconds.
If you see anything I may have missed please chime in!
Q:
How can I explain the differnce in behaviour between the two methods if its NOT due to the extra terminals?
Ben
"Naval surveyor"
PS: We still have NOT noticed a difference in calling a sub-VI who's inputs are marked as "requied".
-
-
-
QUOTE(neB @ Nov 6 2007, 04:57 PM)
ONLY if you are in edit mode and only if I want it do that.I'm yelling because I was do one of my stand-up coding routines on Friday under LV 8.5.
I had a BIG indicator that displayed the measured resistance.
When I cut and pasted the value from the big indicator into a standard sized control and the font size and style came with it. This of course meant I could not read the value I had pasted without re-sizing the control.
Back to my feature request, maybe I was not clear in how I wish it to be, so let me be clearer.
What I would like is :
ctrl + c/v : copy data only
ctrl + shit + c/V : copy format only
or/and 2 right click menu options
If this exist in LabVIEW 8.5 then it's great.
-
QUOTE(crelf @ Nov 7 2007, 03:17 PM)
Got a quick example with benchmark data?I'll try to remember to get back with some numbers.
We only found this out because "I asked the developer to change one thing, create new test".
In one case we were passing a single array.
In another we were passing two.
The "two array" version ran faster than the "one arrays" (We were using the icon on the root technique so our buffers were being reused so we were just passing pointers to the arrays).
After some head scratching, we tried the same test but with icon connectors that use the the min required in each test.
The "time" is very small but it is measurable (I'm using an 80 MHz clock driving a counter timer board. It looks like it take about 4.4 us to read from a counter. That part I wrote down).
I'll post what I can!
My motivation in posting this info was to share the fact that if you are trying to squeeze more performance out of sub-VI calls, forget about the "Required" and use a smaller icon pattern.
Ben
-
Re: Required terminals are more efficient?
I've got this crazy project happening that requires I bench-mark every little piece of code.
I'm using a PXI Xhassis running LabVIEW Real Time 8.5 that is full of top of the line clocks timers and counters.
I confirmed that the difference in Required vs Optional makes such a small differences, we could not measure any difference in performance.
What was suprising was.....
(drum roll)
The icon connector used!
A VI with spare terminals (like we have all learned that we should always have) takes longer to call than an identicle VI who's icon connector only has enough terminals for the data being passed!
I came to accept this after thinking that the function prototype (as defined by the icon conector) indicates how many items get pushed onto the stack when the sub-VI is called.
Take care!
Ben
-
QUOTE(crelf @ Nov 7 2007, 02:11 PM)
Now that I've got your attention: no, this isn't an OO question. Consider a VI that has a required input. If I then drop that VI (child) into another VI (parent), create a control that wires into the required input of the subVI and then put that control on the parent's connector pane, should the parent's connector pane node become required?A is required, should B be automatically required too?
http://lavag.org/old_files/monthly_11_2007/post-181-1194462684.gif' target="_blank">
Only if the child VI is moves on to meet the Supreme Wire-worker.
Seriously,
The use of controls to provide a default value when un-wired is such a nice behaviour that I would not want to have to take extra steps to use it.
Ben
Icon style conventions
in Application Design & Architecture
Posted
QUOTE(Yuri33 @ Nov 13 2007, 07:01 AM)
That's the problem.