Grampa_of_Oliva_n_Eden

Another one of my favorite Dilbert cartoons is the one where they convice the pointy haired boss that using a smaller font will help conserve disk space. Bureacracy is OK when you know how to twist it to your whim. Ben

Try using a "Pciture Ring" with four images? Ben

Just for the sake of discussion... Show the ramp, customize to adjust the size and then write the marker values. That will give you the arc. Ben Download File:post-29-1143567436.vi

It would be very handy for wiring through those shift registers when we add new cases. I'm still working on the eye-trcker. Vision system watches my eyes and moves mouse to where I am looking. Left blink = left mouse, etc. (Don't hold yur breath) Ben

There are a limited number of thoughts that I have had in my life that are worth repeating. For the most part they warrent a "Duh" and not a wow. Three that come to mind are. 1) People always find things in the last place they look because after they find it, they stop looking. 2) If you are always early you are never late. (Einstien says I'm wrong on this one when the speed of light is involved). 3) I can do nothing in less time than you can do something. (Works well for optimizing code). Thanks for your help Chris! Ben

Final Update (?): After testing and personally witnessing the results this is what I found. 1) Globals are still evil. Eliminating these got rid of "Finished Late" issue due to dragging windows around. 2) One of the 600+ VI's passing a bad "Period" value into one of the timed loop sub-VI's. 3) The remaining failing module will be restructured to stream line its processing. Once again, I thank you for sharing your ideas. Ben

In this thread (on the NI Developer Exchange) http://forums.ni.com/ni/board/message?boar...=125133#M125133 Chilly Charlie posted some examples that show you how to access all of the hidden properties of the cursor pallette. I hope that help, Ben

Years ago I read a posting by either Jim Kring or Jean-Pierre about NI's patent for a 3D bloack diagram. Does anyone recall this discusion and have any info on this subject? Ben BTW: Many times my mother looked at me and told me "Benny, don't ever get old!" Well I did not follow her advise and sometimes remember dreams as if they were memories.

Update: After reviewing our notes and more testing, our observations indicate that the problems may have been the timed loop itself. We replaced the timed loop with a while loop and then replaced that with a Timed Loop and now that module is not repoting any "Finished Late" events. I have asked for four more test runs to confirm the fix. I have no plans to return to using the global "Stop Boolean". I will update more when the testing is complete. Again thank you for your "processing time". Ben

CORRECTION! The revised CPU load of 4% were BAD numbers! After concentratitng getting rid of the finished late errors and watching the CPU loads we found that we were not getting updates. WE eventually found that all o the timed loops were exeting prematuturly. Running a preliminary test WITHOUT GLOBALS show only a small reduction in CPU. We are still seeing the FINISHED LATE issues with only two of the 30 Timed Loops. Same two. We are going to have to retrace our steps but globals are NOT involved anymore. It is currently looking like an issue with the two timed loops. I WILL update this thread when I know more. Thanks for acting as a sounding board! It really helps. Ben

Well if I have to take these types of "body blows", I might just as well provide some entertainment while demonstrating what NOT to do. Ben

Chris, Experimenting indicates that the global reads are probably executing in the UI thread. Switching all of the globals (in the timed loops) over to LV2 versions has dropped my CPU loads from 75% and 50% to 4% and 4%. Ben

You are fast Chris! Lacking any more info I will have to read that as aplying to BOTH read and writes. Now I have to wonder why the two loops in question are always "low man on the totem pole" when trying to get at the UI thread. Well, I did give the globals a chance! Maybe this will be better in the long run. It was going to get tough deciding to use LV2's or globals for those "single writer, multiple readers" situations. Ben Come to think of it, we never saw the issue before yesterday! All of the timed loops are clones each other (before I started hacking). They are given unique names based on which module they are in. I can try ruling that out tomorow. Yes I agree they are evil, but I try to give people (and LV functions) another chance. Are the new LV8 shared globals just as evil? Ben

Hi All, After some trouble shooting the engineer I was working with looked at me and said "WHY?" "Why questions are always the hardest Q's to answer. Warning! I am going to be asking about normal LV globals NOT LV2 globals. Using LV 7.1. I have to admit that I have very little experience using globals and this is probably my first attempt to use them. I am using them in this application because I found that a simple boolean global can be read a lot faster than the best LV2 version I could think of. In my application, the "Stop Boolean" global is only written one place but read in about 250 sepearte loops to indicate it is time to stop. About 30 of those loops are timed loops and we noticed that two of the timed loops were asserting the "Finished Late" flag. The actual finish time was about 1 msec after what was expected. We found that if we ran the application without the two loops that were flaging the "Finished Late", none of the other loops had problems. If we added either of the two loops that were finishing late, they would again finish late but the others never had trouble. Running either of the two loops by themselves never give an error. Add any of the other non-late-finishers, BINGO we start seeing the finished late again. Oh bother! I removed ALL of the code inside the loops that finished late except the read from the global boolean and still the loops finish late. At this point I had to question the global! I replaced the global boolean read with a LV2 style boolean and the finished late erros stopped! We could not make (dragging a window around on the desktop helped produce the error) that loop to finish late as long as it was using the LV2. I restored the global boolean and >>>> Finished late! More background info. The application dynamically loads all the VI's required to operate. A timed loop is used in every loaded module. This is how I am quickly including and excluding the offending code. Continuing.... Changing the order in which the modules (timed loops) are loaded did not make a difference. So..... Why would 2 timed loops always take longer to read a global boolean than any of the other timed loops? Do gloabl reads have to execute in the UI thread? Thank you for reading, Ben

"I'd like to be sure, that the students from labviewforum.de do not pass out my demos as their own invention " For that single example you could paste an image of the BD on the FP, then arange your controls and indictors to overlap their terminals of the pasted image.... Then just password protect the code. That way they can see inside without having to look inside. Ben

Does LAVA have a "Board"? It is not just "on these forums." He has been proving himslef to be a true LabVIEW Champion. One of my favorite Dilbert cartoons (my wife insists I am Dilbert) goes like this. Dilbert walks in Radio Hut and is approached by the young sales guy who says "Hi, I am half your age and know more about computers than you ever will, can I help you?" Dilbert replies "Yes, I need a half dozen niad-pulse converters and an Anza-brush..... or am I bluffing?" Jim, you are probably close to half my age and you DO know more about LV than I ever will. Congratulations Jim! Ben

i read that phrase as "...simply wire the Enum into the... numeric inputs to sub-vi's. " Ben

Nitpicking is good! Ben

Yes I have to agree! Now all we have to do is make sure all posts with CAR #'s end up in a list somewhere. Ben (repeated inf times)

This is a confirmed bug. It was added to the Feb 2006 Bug list (see reply #17) found here http://forums.ni.com/ni/board/message?boar...message.id=1698 and is discussed in this thread http://forums.ni.com/ni/board/message?boar...ssage.id=167942 Ben

I do not have a diffinative answer but I will share my thought. Those constants are populated based on what ports LV thinks your PC has. I have noticed that VI's with VISA constants can take quite a while to open the first time. I suspect..... MAX is being invoked in the background and a refresh is happening. Does right-clicking and selecting "allow undefined names" change this behaviour? Done guessing. Ben

Hi i2dx, That is quite a shopping list you posted there! Have all of those issues been reported to NI? Ben

Michael wrote: "It seems that this Version 8.0 is meant to please the advanced LV developers but it seems to be pissing us off more and more..." Michael, you inspired another BLOG entry. Check out the entry labled "The leaders lead". Ben

Please keep us updated Ed. I am looking for at least one positive report re: LV 8.0.1. When it comes to computers in general, predictability is highly desirable. Ben

Set WhatIsHeTalkingAboutFlag? = True LV Power users are a lot like Shadowfax. You can't just jump on his back and expect to make him to move in the direction you want OR to come out of the adventure un-scratched. But make him your ally, and the next thing you know, you are in for an incredible ride! Set WhatIsHeTalkingAboutFlag? = False Ben