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.