Bryan

I'm trying to write a little program using GOOP Developer Evaluation just to see if I understand/implement GOOP. Here's my scenario: I have a VME Chassis, in the chassis are 2 potential types of cards, for each card, there can be up to 6 potential modules (I/O, communication, etc) and then there are specific module types. I've created essentially a master class (VME Chassis) and under it are a bunch of child classes: VME VME.Card VME.Card.Module VME.Card.Module.Type1 VME.Card.Module.Type2 VME.Card.Module.Type3 ...and so on. Now, am I implementing GOOP/OOP as intended? It feels like I'm setting it up for 2 diferent usages: Components and subcomponents and Generic Components and specific components? What I've done, is when I create a VME object, it searches for all available cards and creates new VME.Card objects. Each of those card objects then searches for modules and creates module objects, each module object determines what type it is, and then creates a specific module type object... and so on. I'm still at the "creating" stages and haven't run any of this yet... am I on the right path?

I actually have an A.A.S. in Electronics Technology, Communications: Fiber Optics Emphasis. I had one semester of LabVIEW 4 while in school. I started out as a Test Technician for Corning Inc, demonstrated some LabVIEW ability and was tasked to built an automated test system for passive and active optical components. I've stayed in the testing realm since then and have worked my way from an entry level technician to an engineer (though I'm afraid I've hit the ceiling ) and that's where I currently sit after 7 years in the field. I'm currently a test enginer for Northrop Grumman Naval Systems (Sperry Marine) That's my background.

Someday I'll get there. I want to be in and around the LAVA forums more and be an OpenG contributor... work just keeps getting in the way (unfortunately, little "work" is LabVIEW at the moment).

I thought my movie blurbs were pretty funny (apparently I'm the only one :embarassed:). Looks to me like he may sit in a room with coat hangers hanging from the ceiling and a foil hat on his head.

That was my goal posting in here. I've not spent much time in text-based languages. I started in LabVIEW, THEN started learning a couple text-based languages. OO has always interested me. I understand it, and yet, I don't... if that makes sense.

I see that. I'm inclined to think he's a bot... they're not very coherent.

It's a city (albeit a small one). I have no idea what you're saying.

Exactly my thinking. I've just been having a hard time explaining it.

Why, oh why didn't you take the blue pill? Do you see "GERONIMO" in your dreams? "Just because you're paranoid, don't mean they're not after you." - Kurt Kobain Album: Nevermind Song: Territorial Pissings

dsaunders has pretty much written here what I've been thinking. I have nothing against GOOP. I've been using solely LCOD to this point and am trying to figure out if I should be using one or the other or a combination of both. I haven't had a chance to mess with GOOP too much to understand it completely. One of my things is that LCOD keeps me from having to wire up and maintain a crapload of refnums. I'm going to have to search around here and look at some posted examples of usage I guess.

Thanks for your reply! So, you've essentially done a HD install of DSL, essentially making the filesystem writeable? That's where I run into problems. I guess I'd have to find a way to do a HD install, then create a new ISO image of that install.

For those who don't know, LCOD stands for LabVIEW Component Oriented Design. Quite some time ago, I read the book: "A Software Engineering Approach to LabVIEW" (By Conway Watts), recommended reading to me by JohnRH before he left our company to become a mountain man. For those who don't know what LCOD is, it's essentially elaborate functional (LV2-style) globals that use an enum-controlled state-machine (commands... i.e. methods, property get/set commands) that can be used for data hiding and auto-initialization (1st call, invalid refnums, etc). In the book, it talks about LCOD and modular LV programming, some interesting stuff. I've actually been implementing usage of it in LV projects I'm able to work on (unfortunately, being a TE in my company so far is only allows me about 25% time using LabVIEW at the moment). I've found it to be very easy to work with and manageable. All functionality is contained within one VI subroutine without having to pass around refnums and have multiple subVIs for a particular "module". Now, I haven't had a whole lot of time to mess with or really learn GOOP or OpenGOOP, although I have been trying to follow it with what little time has been available. It definitely is a tool I'd LOVE to use, however, I've been finding myself reluctant to use it because of what little I know about it so far and the fact that it's not as "compact" as LCOD. Has anybody used both, used hybrids of the two, am I just comparing apples to oranges or just not making any sense (it's early and my coffee hasn't kicked in yet)?

Oh, c'mon now. You mean to tell me that nobody in here has ever tried to run LabVIEW in a Knoppix-Based distribution?

Has anybody in here ever run the LabVIEW developent environment on Damn Small Linux? I'm trying to do 2 things with this type of setup... not necessarily on the same machine. The reason I'm looking at DSL is because of it's ability to run completely in RAM. Now, if I'm doing LabVIEW development, I wouldn't be running in RAM. What I want to do is create an executable that will run in the DSL environment. This will give me the ability to boot a computer (with USB Booting ability) and start my application... unmount my media and the computer would still be running and running my software. I would then be free to do the same thing on another computer, and so on. This way, I could have an application running on multiple (networked) computers in RAM without having to install it on the computer itself and/or disturbing the computer's on board hard drive contents. I did develop an exe in Mandrake 10.1 with Labview and get it to run in DSL once before, I don't remember how I did it. I would like to be able to do development in DSL as well so I can test for any inter-distribution problems, etc. If I get this figured out, all I would have to do then is figure out how to reimage my "custom" copy of DSL so that I can install it on a pen drive. I won't be surprised if nobody responds. Pretty much all of the LabVIEW/Linux stuff I've been doing I have figured out myself. It's still neat to wire up programs in an OS other than Window$.

I completely agree. A new install would save us a lot of time (and my company a lot of money for that time).

UPDATE: After a few emails with SST, I got something working. Turns out that I was loading the wrong driver with the DLL, but the DLL isn't specified in any of the documentation. SST had to actually provide an example showing me which DLL to access. There's no way to have known otherwise, except with a good guess. That and the DLL is named appropriatetly: SSPBM32.dll None of the PBMMAN32.dll functions will work without that driver dll loaded.

I was watching some show a month ago about tornado chasers and it showed a computer with a LabVIEW FP and an NI PXI setup.

I've been trying to view/control the online status and configuration of a SST PBMS-5136 multislave profibus card using the "pbmman32.dll" and (decent)documentation provided by SST (Woodhead) with minimal success. The only function that I've been able to get to successfully execute is "PBM_Version", which returns the DLL version. Any other function, even the simplest ones return "FALSE" (error) when I try to run them. The other route I've tried with this card is via ActiveX. I've had better luck this way. I've been able to open a connection to the card, view it's online status and set it offline, but when it comes to configuring the card and setting it online, that's where it gets flaky. The card never configures the way I want it to. I've tried feeding the configuration method the .bss and .pbc file contents, filenames and file paths and if it can't configure the card, it won't set it online. In the rare occasion that it does configure the card, it doesn't configure the card properly. I've even manually configured the card with their config software, used ActiveX to "getConfig", then "put" that same data back on the card and put it online and it still doesn't match the .pbc file configuration. None of the documentation I have for this card documents control via ActiveX, although their website claims compatibilty with it and LabVIEW. I'm at a loss now. I've contacted SST and am currently waiting for a response. Our experience is that they haven't been very timely in returning correspondence so I've been scouring the net trying to find examples/drivers involving successful interface with these cards, but surprisingly have found very little information. Actually, I haven't found a thing that helps in any way. Can anyone help?

I meant using DAQ hardware to control various circuits of lights and sync them to a song. The guy is a GE engineer I hear who got some module to synchronize various outputs to music. He did an awesome job. Apparently, his electric bill is $100 higher/month when he's running this setup (estimation based on last year's, where he did something similar with a little fewer lights).

http://members.cox.net/transam57/lights.wmv

Check your VISA serial configuration VI (where you set up baud rate, etc). There should be a parameter where you can specify using the EOL character (windows it's <cr><lf>). When reading through serial connections, I believe LabVIEW's default configuration is to read until it reaches an end of line character, then it returns everything up to that character. If you disable the EOL character, it will return a specified number of characters instead of waiting until it receives the EOL character. I was going to fire up LabVIEW to check this to make sure I'm giving you accurate information, but it appears my installation is corrupted at the moment. Someone else can probably confirm for me.

Thanks! He's not really (micro) managing, he's got absolute control! Especially when it comes to our sleep schedule, as is what normally happens. Both my wife and I have a new-found respect for our parents. They're coming down to help out today around the house. I'll be giving them really big hugs when they get here.

Wow, I'm sorry that I seem to have taken over this thread (at least at the end) but just FYI, my wife had our baby early yesterday morning. First Name: Ethan Middle: James Weight: 6lbs 2oz. Length: 22" DOB: 9/18/2005 @ 11:22am Just thought you would like to know

I have a couple of questions. Perhaps I misunderstood some of your instructions: You said to lock your central, resizable object. If I do this, the object will then not resize with the window. Did I miss something? Also, you said to anchor your panel to the origin (i.e. FP.Origin = 0,0). I've done this, but it seems that my resizable object "walks" down in vertical height each time the window is resized vertically. I should also mention that I have 2 objects I would like to be resizable. I grouped the 2 together before setting it as resizable. Would this be the cause for the behavior I'm seeing? Finally, is there a way to force objects to resize vertically, but not horizontally (and vice versa) with the panel. Sort of like locking it's "resizability" in one axis. I'm probably looking at doing some things that LabVIEW doesn't yet have the ability to do.

Thanks for releasing the secret Michael! I won't share it outside of LAVA so that only we are the magicians.