RE: Vision systems
Thanks. DC -Original Message- From: William Rance [mailto:[EMAIL PROTECTED] Sent: Sunday, January 25, 2004 10:37 PM To: Info-LabVIEW Mailing List Subject: Vision systems Diego, The book Image Processing with Labiew and IMAQ vision -isbn0-13-047415-0-gives a good introduction to this topic Colour and Pattern Matching are touched upon (page 274..). It may be useful as a lead in..as i find this book gives a good basic coverage of image processing with some useful functions for algorithm design. Bill Rance === Subject: Fuse Vision System suggestions. From: Castro, Diego [EMAIL PROTECTED] Date: Tue, 20 Jan 2004 12:49:18 -0500 Hello all: Our Corporation Engineering Group is looking to develop a Fuse Color Detection system based on LabVIEW, although I have plenty experience working with LabVIEW, I am far from being an expert in Vision System Design, so I am looking for advice on a minimum Cost system being able to look at 40 different components (fuses) simultaneously , capable to identify Colors and Patterns and being easily upgradeable. Any suggestions as the minimum software add-ons I will need will be greatly appreciated. Thanks Diego Castro NGV Systems Engineer Alphabet Portland Stoneridge Corporation (260) 726 6501
Re: Replacing one instance of a VI versus many
If you wish to swap out one subVI for another, unload your VIs, rename or relocate them in the file system, then reload. If you want to rename a subVI, do as Scott suggested and Save As. If you are changing the connector pane pattern, you will need to visit the callers since LV doesn't want to mess up the wirings. We've often talked about the ability to save a recipe with the new connector saying where the old terminals map to, but for the moment, you can usually avoid this by choosing a connector with a few spares. Greg McKaskle
Re: New Tech Support Policy - Record Profit
bottom line! : ) Wish I would have bought NATI in April 2002. Hey Greg, what color is your new Jag? White with gray and black hilights and really really soft -- Oh wait, that is our new Norwegian Forest mix from the kitty rescue shelter. My car is still a dirty Nissan with well over 100K miles. Seriously, I'm happy with the stock price too, but I still get to go to work, fix your bug reports, and rely on you guys for my next house payment -- the Nissan is payed for. Cheers to all of you wise enough to buy some 2002 or earlier vintage and stick with us. Greg McKaskle
RE: Greg's Car
At 11:27 -0500 01/26/2004, Coradeschi, Tom [AMSRD-AAR-AIS-E] wrote: You probably went to the County Line. And yes, there is stuff other than pork on the menu: Beef (it's what's for dinner tonight). There was a crowd of us in that car! And we went to the Salt Lick. There was beef BBQ as well and there was always beer! Malted barley makes for a great meal! -Scott
Re: Off-topic : County Line BBQ
At 11:47 -0500 01/26/2004, Jim Henry wrote: All answers are here: http://www.countyline.com/ Actually http://www.saltlickbbq.com/ Good thing it is Monday and we aren't supposed to be coherent or on topic.
Re: How to throw an exception in COM Library?
I'm writing ATL/COM component in VC6++ (MFC). My component works in VC and should work in LabView. Different custom exceptions (OLE Exceptions) are thrown by my component. How should I throw exception correctly? (AfxThrowOleException()? AfxThrowOleDispatchException()?) How can I catch this special exception in LabView? I think you will need to write your own wrapper DLL to catch the exception and return it to the diagram as an error code. LV doesn't have a built-in catch structure, as it is typically used with other LV code or C code that isn't supposed to return an exception. When a call into a DLL throws an exception, LV catches it and at the moment LV notifies that an exception was caught and I believe it aborts the execution. Greg McKaskle
RE: Greg's Car - salt lick
Ok, I guess this is a good time to plug this: http:\\niweekblog.com There you will find all the groovy details on the NIWEEK Salt Lick trip. Also some pics... Michael Aivaliotis At 11:27 -0500 01/26/2004, Coradeschi, Tom [AMSRD-AAR-AIS-E] wrote: You probably went to the County Line. And yes, there is stuff other than pork on the menu: Beef (it's what's for dinner tonight). Scott Hannahs wrote: There was a crowd of us in that car! And we went to the Salt Lick. There was beef BBQ as well and there was always beer! Malted barley makes for a great meal! Yeah it was Salt Lick and it was a good night way back then in summer 2003. We had to take the beer with us to this special district. For safety reasons most of the beer was tightly locked in the trunk of Greg's Nissan and we were not at all allowed to take a few sips while riding our cars. Was it that way too when the Texas Cowboys rode their horses to the barbecue at the neighboring ranch? Anyway the Salt Lick has a prominent place in a pretty non volatile memory space of my brain. Well I guess this is way off topic now and I hope Tom does not kick me out of info-labview for this. :-)
Re: Fw: [A] Call by Ref Open VI Ref Question
Irene, There is indeed something happening in my state machine that might be part of the problem. I test the issueseparetly (slider connect to a change detector (the one from OpenG) connected to a case where true do the calling by ref. Everything is in a while loop). The true case execute twice (one when you start holding the slider and one when you release it). In between, the execution is "halted" on the Open VI ref (the first time the case become true). It seem that my problem is that in my app I do not catch the second execution (which contain the last"valid" value for the slide). I will need to investigate further why it is so (it might be because by the time the second firing occurs, I am still doing other stuff and I am missing it). As a side note,I am not using event structure in this app. In any case, thanks for the reply. PJM Irene He [EMAIL PROTECTED] wrote: Could that be that when you press down the sliderthere is an event occurred that cause you to executeother states in the state machine, so that it nevergets to the "call by ref" case in your state machineuntil you release the mouse?Just guessing...Irene - Original Message - From: PJ M To: LABVIEW INFO Sent: Monday, January 26, 2004 12:15 PM Subject: [A] Call by Ref Open VI Ref Question Hi everyone, I have a main VI that call a SubVI containing a call by reference. The call by ref pass some parameters to the target VI. One of the parameter is from a control on the main VI (UI). As long as I dont hold the control (a slider), everything is fine. If I do hold the control, the call by reference does not execute until I release the mouse (to be more specific the Open VI reference does not execute). It would not be a problem if the call by reference was not in a state machine, (and expected to be called several time while the user hold the control), the consequence is that my VI execute only once with the first value from the control which is always never the one when the user release the mouse. It might very well be a know behavior (but until now it has never been an issue for me). Does it happen because my SubVI is in the UI thread (because of the call by ref ? )? Is there a way to prevent this from happenning (or do I have to redesign my VI around that behavior ?)? Thanks PJM Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it!=Irene He[EMAIL PROTECTED]www.hytekautomation.comwww.geocities.com/irene_he Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it!
test
The message contains Unicode characters and has been sent as a binary attachment. body.zip Description: Binary data
Close aplications.
Hello smart people!! How can I do to close an aplication in LabView and close windows and turn off PC. Exist some function that do it in LabView? Daniel
Re: Greg's Car
PS. By the way, I don't eat pork and don't fancy to go the that BBQ restaurant again! There is no other item in their menu!:)?? I'm really sorry about that. Some of us try to be culturally or culinarily aware, but with crowds, it always comes down to LCD and compromises. Being something of a hippy town, Austin has some good vegan restaurants, and almost every restaurant has veggie items. The BBQ joints, however, are not ones to bend over backwards. I love BBQ, but if anyone would prefer Mexican next time... Greg McKaskle
Re: [A] Call by Ref Open VI Ref Question
it has never been an issue for me). Does it happen because my SubVI is in the UI thread (because of the call by ref ? )? Is there a way to prevent this from happenning (or do I have to redesign my VI around that behavior ?)? I believe what you are seeing is that various parts of the VI Server must run in the UI thread, and they may need to wait for user activity as well. In particular, you are loading a VI, and load must take place in UI. It is possible that a future version of LV will be able to put load in another thread or that it will not need to wait for the user to release the slider, but for the moment, that is just the way it works. Greg McKaskle