-
Posts
390 -
Joined
-
Last visited
-
Days Won
16
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by Bryan
-
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$.
-
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.
-
I never noticed that option before. I always thought that you had to apply it to all items on the panel, except those that are locked. I noticed that some objects move with the window size, but don't scale with it. Is this done with a tricky combination of locks and scaling?
-
I've been looking at the front panel for the OpenG commander for a little while this morning trying to figure out how Jim got certain controls to move, scale and even stay put when adjusting the size of the window. I checked to see if the "Scale objects with window size" box was checked in the VI properties, but it wasn't. How did you dood it Jim?
-
Thanks for the pointer, I learned a few things, but unfortunately, this isn't what I'm looking for. I'm not looking to make my application THE executive. I would like to know the best way to launch TestStand and start the execution of a sequence file (possibly even login as well) FROM labview, not within labview. It's simpler than that even. The program I've created in LabVIEW is a test sequence browser. It allows a user to view revisions of sequence files stored in Visual Source Safe and select one to run. At startup, the LabVIEW program downloads the latest revisions of the support VIs and other files used in the sequences. When a user selects a sequence to run, it downloads that sequence from VSS to a specific directory and (currently through a command prompt VI) opens the sequence in TestStand. When the operator is done running sequences and closes the program, the program removes all of the support files and *.seq files leaving behind the file structure and collected test data. I know there's probably a MUCH better way of doing what I'm doing, but since I'm still learning TestStand and don't have a whole lot of time to become a TestStand guru, I've been working with what I know. TestStand's source control stuff seems limited to workspaces and such. What we're doing is running individual sequences, more specifically on average of 15 sequences for different tests per UUT. Because of the uniqueness of each unit (and our lack of available development time) we've had to develop these sequences as we get each unit. Back to my problem though, so far it seems like the command prompt route I'm using currently best fits my needs whereas the TestStand API is intended to create a test executive out of a LabVIEW VI, which is much further in depth than I need to get. Thanks for your help though! :beer: I'll keep messing with the example to see if I stumble across something that fits my needs.
-
I'm running LV7.1 and TS3.1. What I want to do is somewhat the opposite of how TestStand and LabVIEW were intended to interact I believe, since TestStand is intended to be the top level application calling LabVIEW. What I want to do is control the TestStand application from LabVIEW. More specifiaclly, open the application, display the window, open a teststand sequence file and start it. That's basically it, sounds simple enough doesn't it? I looked through the ActiveX APIs and couldn't find any clear-cut way of doing it. For example, when controlling MS Office, you can open the application, make it visible, open files, etc. I'm having a hard time finding a way to do it through creatable objects. I'm probably missing something that's really easy. Could someone who knows point me in the right direction? I should be able to take it from there. So far, the only path I've been down is with the Engine API. For now, I've been calling the sequence file through the command prompt subVI. It works, but doesn't allow me the level of control I'd like. Thanks, Bryan
-
Accessing OPC/DDE Servers W/O LabVIEW DSC Module?
Bryan replied to Bryan's topic in Calling External Code
Thanks for the detailed information Michael. That helps me understand it more. To date, I think I've been using the DSC module waaaayyy below it's capabilities, but not having time to really get familiar with it has me using it in the way I've been able to initially get it to work. Using DataSocket will probably be the least efficient way for us to do what we want, but like you said, will be the cheapest and require far less time to implement than other solutions I've been looking at. -
Accessing OPC/DDE Servers W/O LabVIEW DSC Module?
Bryan replied to Bryan's topic in Calling External Code
We're going to be using quite a few tags I believe, so datasocket would be out. I forgot to mention. We're using profibus cards from a vendor that supplies both DDE and OPC servers to use with their cards. Is the OPC server from Kepware more "friendly" to use with LabVIEW? -
Is it possible? We're going to be developing a rather large application using multiple computers, all of which will have OPC servers running on them. Currently, we're using LabVIEW with the DSC module to access the OPC tags. DSC licenses are rather expensive, and cost is definitely a factor in our case. Does anybody know if there is a way to access OPC Server objects/tag values in LabVIEW without purchasing the DSC module? An option we're keeping in the back of our minds is using the OPCDAAuto.dll and essentially creating our own little version of it, but it requires time (of which we don't have much) and a learning curve. If anybody's done something like this, I would much appreciate a point in the right direction, example code or anything I can get my hands on. Thank you much-ly!