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.

"Needing unreleased LV version to finish project." (LV icon with a +1 beside it)

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

It's been tough going through the last month without our beloved LAVA site, but behold, it's back and better than ever. We're calling this version LAVA 2.0. Welcome back!

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

Since we're running out of time, unless there are any strong objections, I'll set the t-shirt up in the LAVAStore in the next few days - vugie's design on the front and this one on the back.

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

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)

I'll post an example later

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:

<Property Name="Dll_includeHeaders" Type="Bool">true</Property>

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)

If you'll notice, the architectures required to do this vary wildly depending upon requirements and desires. There is not a cannonical solution to this problem. Indeed, the only thing that R&D can assert is what we already assert -- you can't build a DLL with a class directly in the interface. You have to be inventive...

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)

I'm not really sure how much work this would end up being, but you can definitely use LabVIEW queues to store your data, and pass the queue references in and out of DLL calls much like pointers. It's a 32-bit value that is in essence a pointer to your data. You can even just Type Cast the queue reference to an I32 for your public interface. Just create non-class wrapper functions that dequeue the class data, call the class member, and then enqueue the data back into the queue.

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)

I always cringe when I hear this kind of preamble...

QUOTE (Aristos Queue @ Apr 20 2009, 02:13 PM)

• 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)
  
  

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)

Well remember, all the IMAQ stuff is by-reference (this confused the hell out of me the first time), and images are big and copying is relatively slow, so the whole system is designed never to copy an image unless you force it to. Just about all the functions operate in-place by default. So the idea is that you wire your image to manipulate into the Source input, and leave the Destination unwired, and the routine modifies your source. Sometimes you want to preserve your original image, so you create a second image and wire it into the Dest, and then you have the before and after, but it's pretty rare to need this.

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)

Yes, that is absolutely correct.

QUOTE (jdunham @ Mar 5 2009, 10:44 PM)

HEY! That sounds doable! I'll try that!

QUOTE (jdunham @ Mar 5 2009, 09:18 PM)

It looks to me like you have your Source and Destination images backwards in the IMAQ Mask function. If you do wire a destination, it will be overwritten by the operation. Since you never put any data into the source, all you see is a copy of the mask in the output. For most of the IMAQ functions, you don't need to wire the Image Dst at all, and you just modify the source image.

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)

I have a U32 RGB image streaming in from a webcam, and I want to overlay/merge (whatever is faster) a U16 grayscale image over the top of it. The grayscale image has 0-value pixels that I do not want to include in this "merge". Any non-zero intensity value should be included.

What would the proper IMAQ tools be to merge these together? I've tried to cast the U16 to a U32 RGB which works (loses some intensity resolution due to bringing 16bit down to 8bit color, but I can live with it). Where I'm stuck is I can't seem to find anything that would efficiently overlay/merge *just* the non-zero pixels of this casted image onto my background U32 RGB image. I know this is something silly I'm not thinking of...

I am capturing both images at 30fps and need to perform this operation in realtime. Can someone point me in the right direction of the NI-Vision palletes...or an example perhaps that will push my "ah ha!" button?