LAVA 1.0 Content

QUOTE(Michael_Aivaliotis @ Nov 12 2007, 11:29 PM) I'll try and wait for correction*. A State Machine is a programing construct that implements a state diagram. A State Diagram is a drawing that illustrates the various states a process can be in and the conditions under which it will transition from one state to another. I have also heard them called "State Transition Diagrams. This is illustrated in the State Diagram Editor. With the SDE you edit the SD and LV re-codes the state machine. Ben * Don't give up easy.

QUOTE(Aitor Solar @ Nov 12 2007, 10:49 AM) Saludo The tool looks verry vell! Unfortunately I can't create a single property, since I'm using LabVIEW German, and all the Properties have different names... I tried to edit the txt file and entered the german names but i still get the error 1113... http://lavag.org/old_files/monthly_11_2007/post-1396-1194946722.jpg' target="_blank"> Have you any Idea? Martin

QUOTE(bono02 @ Nov 12 2007, 03:57 AM) Hello I'm using the PXI 7358- 8 Axis Motion Controller for Servo Motors, and Hydralic Cylinders... What do you like to hear about the Motion Controllers? Martin

QUOTE(ragglefrock @ Nov 13 2007, 04:42 PM) Another snippet that'd be excellent in the http://wiki.lavag.org/' target="_blank">LabVIEWwiki

QUOTE(PeterB @ Nov 13 2007, 03:42 PM) :thumbup: Thanks!

QUOTE(PeterB @ Nov 13 2007, 08:29 AM) Hi Pete - can you please find a place for this juicy little tidbid in the http://wiki.lavag.org/' target="_blank">LabVIEW wiki?

QUOTE(Yuri33 @ Nov 13 2007, 07:01 AM) That's the problem.

QUOTE(Norm Kirchner @ Nov 13 2007, 02:07 AM) LQTM

QUOTE(PeterB @ Nov 12 2007, 05:29 PM) 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

QUOTE(PeterB @ Nov 11 2007, 04:03 AM) The events "fires" in the UI thread. That does NOT mean the code for the event executes in the UI thread, only the "firing". 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(tcplomp @ Nov 11 2007, 05:40 AM) Maybe LAVA's becomming self-aware...

QUOTE(jdunham @ Nov 11 2007, 04:46 AM) I'd vote for that feature.

QUOTE(neB @ Nov 11 2007, 12:20 AM) 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(Justin Goeres @ Nov 11 2007, 02:50 AM) I think they merge if there's only been a short amount of time between you replies - if you leave it for a while (not sure the cutoff) then they don't (?)

QUOTE(i2dx @ Nov 10 2007, 11:16 PM) Muwwwhahaha! 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(Yen @ Nov 10 2007, 11:33 AM) That would be an excellent guess if I knew how to spell one vs the other and could tell the difference. my wife pointed out the two words were spelled differently. :headbang: again! Ben

QUOTE(PeterB @ Nov 9 2007, 10:00 PM) I BELIEVE the event does fire in the UI thread. That does not mean the Event case executes in the UI thread. Property nodes do executes in the UI thread. Controls and indicators should not be used to "store" data in all but the most simple VI's (and even then with great care!). They lead to yet another form of race conditions. I tend to use controls and indicators as a "window" into the data I store in Action Engines. 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) 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

QUOTE(mross @ Nov 10 2007, 03:54 AM) :thumbup: Wow - I couldn't agree more with mross's post - almost verbatum of what I was thinking.

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".