orko

There's this terrible rumor circulating that this guy that used to be on here is poking around the threads... And I may just be here for a little while this time 😉 Howdy from Tulsa, OK 🤠

Oh, and here I am jumping back into the forums one month later to see the backside of a great contributor leaving it! Congratulations, AQ! This sounds like one of those "couldn't say no" opportunities, I'm truly excited for you, go forth and dequeue 🤣 I recently got my own boost of adrenaline, started work with the Facebook Reality Labs crew who are turning out to be a great team. Time to knock off that VI rust and get back in the game 👍

Yeah, this is quite the new look. I like the usability of it so far, even though I miss the old site's simplicity. I know Michael was having some scaling issues back then, so this is probably a huge improvement, eh? I was around a few years ago when I was working for Jim, but since then it's been oil & gas test work all the way. You know how it goes with learning curves and big mega corporations, and having to stick to the tools they like to play with. LabVIEW was always there and I did use it when I could, but it fell on the side burner as I played with other things like .NET, JavaScript and inhouse applications/firmware for the big O&G. Now I've got a project that makes LabVIEW come back into focus in the R&D lab here. orko is happy again :-) Nice to see you again, Brian!

Whew. What happened? I turn my back for a second and years go by since I've been on the boards. A warm hello from beyond the veil of the corporate firewall. He is still alive...

Hi Manfred, These timings look like two processes that are both logging at 10m, but are independent (not synced). Are you sure that there isn't another instance of this application (on the VM or your host computer) that is running without your knowledge?

Hi all, I'm very excited to be getting back into the LAVA community, and am glad to see familiar faces (avatars) in the forums I recently joined the team at JKI, and am having a blast working with Jim and his talented crew. It's unthinkable to me that I could catch up with every single unread post, so I will be resetting my "unread" counter and doing what I can to catch up. In the meantime, just wanted to drop a note to say I was "back in town". See you on the boards! Joe "orko" Sines

Hello fellow LAVA members, There has recently been a few Microsoft positions opening up in Redmond, WA for vendor positions. Northwest Contract Services (NWCS) is currently looking for people to fill the following roles, and I don't want anyone to miss these great opportunities: - Labview and SQL Server, tools development experience some experience interfacing to hardware - Mechanical engineer with electronics experience or electrical engineer with mechanical knowledge - Hardware test engineer with software test experience to run interop tests - PM with hardware experience - Optical disk drive engineer - MTE Working for NWCS as a vendor on the Xbox group has been a life-changing experience for me. If you are interested, please respond to this post or PM me your resume and I will directly forward it to people who can give you more information. I am not a recruiter, but have been asked if I knew of any people looking for jobs in these areas. So I figured, why not give back to the community that has helped me out time and time again? LAVA is full of intelligent, talented people. Exactly the kind of people I want working with me on my team. ;-) Here is a brief description of Northwest Contract Services: Northwest Contract Services partners with our customers in the development of significant consumer electronics devices. Our employees work on each project until it is on the marketplace and then move on to other newer projects. Our employees enjoy company paid medical, dental, vision, long term disability and life insurance as well as a 401k program. Joe "orko" Sines

There was a time in my life where I worked 16-17 hour days as a backend web developer for about three years in order to make ends meet. Constant "hair-on-fire" drills, calls in the middle of the night, and a couch next to my desk that probably saw more sleep time than my bed at home did. When the new baby came at home, let's just say that my family life was a little...strained. The turning point came on a very memorable weekend, when my wife was talking to me about future babysitting options for our daughter. After a pause, my response to her was "Okay, I'll get that script up and running next week..." Dream of debugging? At that point my eyes were open, while dreaming of debugging, while sleep-talking to my wife. Of course, 1.2us later I was wide awake...and my arm hurt. Bad. I started job-hunting that week.

Oh I like this last one. I (and several others) actually have projects that have a temporary workaround in place...until the next release comes. Joe PS. It's something about making each class a [dll]/llb before building an OOP designed exe...to avoid inheritance spew in the build folder. You know all about it though

Indeed it sounds like you had your hands full, but you all have endured, and I am extremely thankful. The LAVA resource was sadly missed by all in it's abscence. Great work! Joe

Well, heck...I won't be able to go this year, but I'd buy one!

I think the 1 Million mark should obviously be... "Insane Object" The lowest rating in my mind would be "broken arrow"

You should only have to download or re-install the correct version of NI-VISA (make sure to keep the installation folder around so you can build installers from it). I had a similar problem because I upgraded a needed runtime but didn't keep the downloaded setup files for my installer builds.

Okay, bringing This Thread out again... sorry AQ In the app builder, anyone that has built an OOP based EXE or DLL has experienced the "conflicting name" warning, and seen the suggestion to rename the files in the build process as a workaround. Well, the app builder actually lets you do this with class members...which totally breaks inheritance. I'll post an example later, but basically: 1) Create three classes; a parent and two children, with a common method "A.vi" with dynamic class terminals and a single numeric output 2) Create a test.vi that uses a numeric input to a case structure to select which object (parent, child1, or child2) to pass into the A.VI method, and an output to tell which method was called 3) Build this test.vi into a DLL with the test.vi as it's exported function (numeric input, numeric output) 4) You'll of course notice that this creates subfolders for the conflicting name A.vi 5) Test the DLL, you should get the desired output for the corresponding input you set up in the test.VI 6) Now, re-open the DLL build spec and tell the app builder to rename the A.vi method in each class to "<className>_A.vi" (yes, it lets you do this and hence the bug) 7) Build this DLL and notice that no subfolders are created (if you look into this closer, you'll find that it actually is creating VIs with names "<className>_A.vi" like you told it to) 8) Test the DLL, you'll notice that no matter what you feed into the input, you'll always get the parent method output NOTE: I actually considered hard before I posted this as a "Bug", since I would have loved it if the renaming actually worked... but I understand with the current way LabVIEW handles classes why it "shouldn't" allow me to rename class members in the build. QUOTE (orko @ Apr 29 2009, 08:15 PM) Here it is: http://lavag.org/old_files/post-3266-1241062428.zip'>Download File:post-3266-1241062428.zip (LV 8.6.1) 1) Unzip and open the project 2) Build All 3) Run both test VIs. One uses the DLL built without renaming the methods, the other uses the one with renaming.

WORKAROUND: Add the following manually to the lvproj file in the build specifications: &lt;Property Name="Dll_includeHeaders" Type="Bool"&gt;true&lt;/Property&gt;

In the Advanced dialog of the DLL build specification: This checkbox is non-functional, in that it does not copy the cintools header files over to the build folder, and it will not stay checked. 1) Create a LabVIEW project 2) Create a new DLL build specification 3) Open the build specification properties 4) Check the above checkbox, click OK 5) Open the build specification properties again - see that it is unchecked

Thank you for the example, AQ. I am going to be delving into this in these next few days, so clarifying the process helps tremendously. QUOTE (Aristos Queue @ Apr 21 2009, 01:58 PM) I think I see what you mean. Interfaces have always been tricky...and there are many different ways to implement them. However (at least for my purposes) I think the LV2 Object array method serves many if not all of the wants/desires for LVOOP built instrument drivers. Similar to the problems that IVI faced, there are just too many ways to do this, so it seems best to just pick one way that works and run with it...

I've attached a VI that describes this issue. Tested on LV8.6.1 and LV8.5.1 Download File:post-3266-1240351713.vi (LV8.5.1) I've noticed before that my text string searches take incredibly too long on some of my larger applications, but haven't been able to pinpoint the circumstances until now. Basically, as arrays (I wouldn't doubt if clusters behaved the same or worse) grow in size...the searches for text strings get linearly longer to return results. The example uses a U16 integer array, so I'm not searching through a massive text array, which I could understand. I mean, the label/caption text of all array elements are the same....so why search through them all? (I'm assuming that's what's happening) Joe

Thanks Mark. That solidifies the concept in my mind. Now that I understand...I'll try this out and see how much time is required. Is it me or doesn't this seem like something that would be able to be done programmatically within the App builder? The whole "Build me a DLL from this class" concept.

QUOTE (ragglefrock @ Apr 20 2009, 01:48 PM) This is an interesting concept (and I may be able to use this on other applications), but seems a little overkill for this situation. I'm also a little leery on creating another level of abstraction with queues when this will require the same or more "wrapper" VIs to be created anyway. I can see doing this though if you wish to pass complex structures back and forth from the calling (C++/C#) code and the underlying LabVIEW. QUOTE (Aristos Queue @ Apr 20 2009, 02:13 PM) You're not going to like these two solutions but I'll mention them anyway... I always cringe when I hear this kind of preamble... QUOTE (Aristos Queue @ Apr 20 2009, 02:13 PM) 1. Any VI that has a class on its FP (as either an input or an output) that you want to expose through the DLL should be wrapped by a VI that takes a cluster instead (as input or output) and creates the class from that cluster (input) or creates the cluster from that class (output). Doesn't work if you were hoping for something that uses different object types for different calls into the API, and you may have to expose more public methods than you would want to. But to get through the DLL layer, you have to shed the class sheild. ACK! Even though this would work, it seems that it would be a maintenance nightmare... Probably valid on small onesy-twosy type calls into a DLL, but I think I'll pass on this for now. QUOTE (Aristos Queue @ Apr 20 2009, 02:13 PM) 2. Create either an LV2-style global of an "array of object" type that can do get/set on individual indicies of the array or some sort of reference architecture (a la the GOOP Toolkit) and any time you would pass an object out to the DLL layer, pass the index into the LV2-global or the refnum out instead. When you make a call back into the API with an object input, pass the previous index/refnum as input. You can use -1 or not a refnum as a sentinel for "create a new default object." Now this...this has me thinking. I can see how this method could be very useful in keeping the LabVIEW architects on their side of the fence and the C guys happily on the other. The main goal I had was to keep using the LV OOP code base in LabVIEW applications, while exposing the functionality to external calling code. This seems to fit that bill! It would seem that I could make generic "LabVIEW object" setObject/getObject/deleteObJect methods (init/get/close) that perform the indexing you talk about. Then the non-class member VIs that are going to be used in the DLL could all have the getObject VI as the precursor to get the right object out of the array. Hmm...Wouldn't there also have to be another VI to put that object back into the array (to maintain state and avoid copies)?

Hello all, I've been working now with LVOOP for some time and have developed a class hierarchy that seems to work well to interface with test instruments and other hardware *inside LV built code*. Our team has used this hierarchy to quickly develop our test tools *in LV* while maintaining a common (re)usable code base. Now we've attracted the attention of others and we're being asked to provide this functionality to external code (C++/C#) calls inside other test tools. My initial thought was, "Great! I've wrapped LV up into dlls before, should be cake!"... Now I'm having difficulty in seeing the path to success here. Although I was dissapointed to see that you can't just point the App builder to a class and say "Build me a DLL", I can understand why it would be difficult for it to do such a thing. In LV code everything is by-value, and relies on a class wire to hold the instance in memory to work from. When you are calling exports from the outside however, we would expect to initialize an instance and have all subsequent calls use it (as a pointer to the object) with parameters to perform our functions. I think I see some ways of doing this, but I feel I may be off-track. So I'm asking the forum if you have dealt with this and if so, what did you find worked for you? I am shooting for some method that I can re-use on all of my LVOOP projects I want to expose as shared libraries to other languages. How about: Wrapping up all the methods into exportable non-class members? If so, we would need to hold the class data somewhere... so perhaps wrapping up an "initialize/destroy" that holds an LV object in a shift register to be used by subsequent VIs? Is it possible to do this without the other team having to know anything about LV? Providing just the dll/header file and defining the instances to be just C data types such as I32 pointers? Basically, I (they) would prefer that they could build their projects without having a bunch of NI stuff installed. I would appreciate any and all ideas before I start on this grand adventure! Joe

QUOTE (jdunham @ Mar 5 2009, 10:44 PM) Thank you for this. It helps to clear up some confusion I had of what Source and Destination actually are. QUOTE (jdunham @ Mar 5 2009, 10:44 PM) OK, I think what you want is a bit more complex that the normal mask. Let's see... Do I have it right that the only part of the RGB image to preserve is places where the mask is zero, and everywhere else, you want the to keep the grayscale values in the 'mask'? Yes, that is absolutely correct. QUOTE (jdunham @ Mar 5 2009, 10:44 PM) I think you could invert your mask with the IMAQ Compare, and then that is your mask you apply to the RGB image. At that point you should just be able to IMAQ Add that to the grayscale image, since no pixel would be non-zero in both images. HEY! That sounds doable! I'll try that!

QUOTE (jdunham @ Mar 5 2009, 09:18 PM) I guess I was confused about the nature of the mask VI itself. Reading the docs, I thought it was supposed to copy the Source *into* the Destination, but only in the pixels defined by the mask as non-zero. I think what you're saying is that the function instead makes a *new* copy of the source with the mask non-zero defined pixels...and replaces anything that was in the Destination memory location with this copy. So if I'm understanding this correctly... how then would I replace the pixels in the RGB image with the non-masked out pixels in this new Masked image? Man, I know this is a very basic question, but the "ah ha!" switch is not quite closed yet... Thanks for all your help.

Thanks for the prompt replies! Neville, unless I'm mistaken, adding a 32bit-casted grayscale image to the color RGB will give me darker/lighter colors in the areas that I want to totally replace (with the actual grayscale intensity value). I wish it were that easy JD, I took your and Neville's advice and tried to apply a mask to the color RGB image using the grayscale image casted down to an U8 grayscale image as the mask. It didn't do what I expected, instead the grayscale RGB image is replacing all of the pixels in the color RGB image. Can you take a look and see where I'm going wrong here? Download File:post-3266-1236298441.vi (LV 8.6)