Jump to content

John Kelly

Members
  • Posts

    15
  • Joined

  • Last visited

    Never

John Kelly's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Hi Ven, Thanks for your suggestions. I freely admit I'm a newbie when it comes to Labview and will try things that don't make sense. I've been working through some of the LV examples supplied with the development system; still a lot to learn. Regards, John
  2. Greetings, On one tab I provide the user with two buttons: (1) Connect/disconnect a motion controller on another computer and (2) Manually jog an axis. On the second tab, the user clicks a button to run experiments, during which the motion axis is successively jogged: move, take some measurements, move, measure, ... All the motion code resides in .NET DLL. To provide the 'connect' capability, I using a .NET constructor and invoke methods to connect up. If everything's cool, I use a .NET refnum to hold on to a reference to the DLL. To provide the 'jog' capability, I create a local variable that holds the .NET refnum; I can then use the local as the reference to the DLL and make use of the motion capability provided by the DLL. Where I'm running into problems is on tab 2. Here I want to make use of the same motion capability 'jog' uses; therefore, I figured I'd create another local pointing to the .NET refnum (i.e. RMB the .NET refnum and choose 'Create local' from the popup menu) and paste that onto tab2. That way, I could use the motion system as part of an automated experiment. When I paste, however, I get another .NET refnum along with the local. I'm dazed and confused; could someone suggest the correct or a better way to accomplish my objective? I've tried moving the .NET refnum 'outside' the tab control...my lame attempt at widening the scope...but that was not successful. I'd be tickled to provided any additional info that might be useful. I'm running Labview Express...I think that means 7.0...on a win2k box (hey, I'm just a contractor doing maintenance!). Using a DLL for the motion is mandated, but everything else is up for grabs. As always, thanks for your time in reading this. Regards, John K.
  3. G'day, I'm doing maintenance on some LV7.1...it's a mess. I'm struggling with run time menus: one menu choice is designed to pop a VI that lets the user jog some stages. The popped VI had an error, so I replaced it with a functioning version with the same name. Now when I light up the top level VI, the 'jog stages' VI doesn't pop (appear) when I click the runtime menu choice. It appears I've lost the 'connection' between the menu choice and running the jog VI. Can anyone shed light on how to correct this? I've poked through the LV examples and found some information...more study needed there. I'd be glad to supply any additional info that might be useful. Thanks for any help you can provide. Best, John
  4. Ahhh, that worked! :thumbup: This is one time where the LV message: "Do you want to overwrite the in memory VI" was welcome! Thanks so much, now on to run time menus, my next tragedy, but that's a story for another thread. Flame on I had maintaining other people's code Flame off Best regards, John
  5. Greetings from sunny Massachusetts, USA... orko: Last night I built a tiny app with one parent vi and one subvi. I made two copies of the sub vi, with slightly different names and function. Then I experimented with replacing the subVI by RMB, choosing 'Replace' and navigating to the new subVI...and that all works as expected and in line with your suggestions (much appreciated, BTW!). I'm beginning to think my problem is I'm dealing with global variables, so 'items'...variables representing one of the multitude of global variables...show up all over my calling vi. I can't select them all at the same time. I haven't found a way to replace the global variable file with another of the same name. In the past, I've avoided using globals, maybe this is one reason? ton: That sounds exactly right for what I need. I followed some links...not a thorough search by any means...but only found a vi for LV8.2, I'm stuck at 7.1. Do you know if there's an equivalent out there for 7.1? Thanks to both of you for your efforts on my behalf, John
  6. Greetings, I'm poking through someone else's Labview 7.1 code. The former owner wrote many very similar top-level VI's, so there was a chance to reuse subVI's. It appears to start a new project to create another top-level VI, he'd copy a folder that had similar LV code in it and then make changes. Sometimes he'd copy folders, sometimes just the contents, sometimes files one-at-a-time.\ Here's a typical example: A vi named 'ScreaminRead.vi' makes use of some global variables contained a subVI named 'Control Global Variables.vi'. There are many (>20) copies of 'Control Global Variables.vi' on the computer...and they may differ slightly. 'ScreaminRead' is linked to or referencing an incorrect version of 'Control Global Variables'. How do I reconnect 'ScreaminRead' to the desired version of 'Control Global Variables'? Thanks, be glad to supply any additional info that might be useful. ...and I think this gets me to 10 posts! Yaaay! John K. One more bit of info: I've tried navigating in the block diagram of the top level VI to the subVI that I'd like to replace, right mouse button, select 'Replace' and find the subVI I'd like to plug in, select it, and then save the toplevel VI. But it doesn't seem to 'take'; that is, the top level VI maintains a reference to incorrect subVI. Does this occur because the subVI shows up in a bunch of places in the top level VI and I've selected just one instance? Given that the subVI in questions contains global variables, it actually shows up on the top level VI's block diagram in various places, with different global variables. I select one of the variables, do the 'Replace' thing, but no luck. Sorta related, is there text readable 'project file' that one can examine and potentially edit that maintains the paths to all subVI's? Wow, lotsa info here, hope I haven't overloaded the kindness of this group. Best, John
  7. Hi Aristos, Thanks for suggesting that method, it seems like it would work. The data is actually just a double, not a waveform, so the data size is not a problem. I want to finish the technique suggested by Jimi...using callbacks...before I try this approach. And of course since it's Monday morning here in the eastern US, someone cycled the power to whole optical table over the weekend and pretty everything is not working. ...engineering, you gotta love it! Best, John Hi Chris, As it turns out, at least my version of 7.0...something my client had before I came on the scene...is .NET capable. I've actually been doing the majority of my work on this project by building C++ and C# DLL's with usually just one method, and then using that as a portal to use some classes I've constructed in the past. I found what I needed in the Functions panel, under 'Communication'...next 'TCP' and some others. It could be that a previous engineer downloaded and installed something, if NI put that out as an option...dunno. Given Jimi's handle, I couldn't resist asking if he was a player. :question: I hack at guitar myself. Best, John
  8. Hi Jimi, Thanks for that info. I'll try your suggestions and report back. Best regards, John
  9. Good morning Chris, Jimi, and Omar- Jimi, your suggestion sounds perfect for what I need. When I went looking for the cited examples, I didn't have an 'events.llb' in my 'labview\examples\comm\dotnet\' path; instead, I have 'SimpleTaskMonitor.llb' and 'Calculator.llb'. I cracked those open and while they supply useful info on using .NET assemblies, I didn't spy anything on callbacks. I poked around the directories, found some stuff on ActiveXEvents which might prove enlightening...but I figured I'd ask if perhaps running 7.0 is the reason my directory structure is different? Is there another source for those, or similar, examples? I've run into the case where I find a cool looking VI on the Web, only to have the dreaded 'You must have 8.x installed to run this example'. Maybe I can beat my client over the head if this is a 7/8 issue. Anyway, thanks for all the help, I'm learning a ton about LabView as part of this at times painful process. Hey Jimi, you don't play guitar by any chance, do you? :thumbup: Best, John
  10. I think that will work. It's not synchronous with the C#, but certainly better than no value at all! I'll try this out first thing tomorrow and report on how it worked. Thanks for your help, hopefully one of these days I can be the helpER instead of the helpEE. :thumbup: Best, John
  11. Hi Chris, Thanks for your suggestions. I responded to a few of your points: Why not have LV log the value for you? <John>The subordinate C# DLL is the only code that 'knows' when it's time grab the power meter value; the parent LV just continuosly reads the power meter value. I can't help you with the C#, but I know that you can pass a value to a C DLL and do something with it. Of course you have to have access to the C code that made the DLL and make a new function. <John>The C# operates pretty much the same way as using a C DLL; that is, called from LV into a C# DLL. What I need is a function that calls FROM the C# TO Labview; what I have now is a bunch of methods/functions baked into a DLL that my be called FROM LabView. Hey, can I just turn my DLL upside down and have it work backwards? :headbang: You'll have to have some way to determine logging frequency no matter what, once you determine its time to log the value, you would either call a function in the C# DLL or log the value with LV. <John>The C# knows when to log. When that time comes, how does it initiate fetching the power meter value from LabView? Chris <John>I appreciate your efforts. Thanks!
  12. Good morning from sunny Massachusetts, USA... I'm doing maintenance on an image processing/laser holography application written in LV7.0. The application is structured with LV calling a C# DLL (accessed via .NET constructor and invoke) that handles the heavy lifting of manipulating pixel data and adjusting the position of a few mechanical stages. Other than the C# aka .NET assembly being a little slow to start up, this approach works fine... ...until my client, after observing the system in action, said, "That's great. Could you add one more feature, namely, every so often the C# should log the value of the laser power meter?" The problem I'm facing is the laser power reading is being acquired by the 'parent' LV program, inside a while loop, so it's continuously available, but I don't know how to 'ask' LV for the value from my C# DLL. Could the forum suggest a mechanism to accomplish this? I'd be glad to supply any additional info that might be useful. Thanks for your help. Regards, John
  13. Even though I'm a newbie...and a rank LabView punk to boot... ...I think I'm gonna like it here! :worship: -JJ
  14. Good morning, Thanks Ton, Chris and Chris for your prompt and correct suggestions. :beer: 's for all, on me! Best, John
  15. Greetings from a newbie, I'm doing some image processing with LV7.0. My client doesn't want to updgrade. My task is to read in a .bmp file that's written by another process snagging images, and then cause some stages to move based on the contents of the bmp. I'm trying to examine the values of the 2D array that I've created from the 8-bit pixel data. Could anyone suggest a technigue for display the contents of a 2D array of unsigned byte [8-bit integer (0 to 255)]'s? I tried dropping an array display on the front panel, and setting the number of dimension to 2, but when I wire up my 'unflatten pixmap.vi' 8-bit pixmap output to the array input, I get an error message complaining the source is unsigned 8-bit integer, but the sink is type void. Can I coerce the type? How does one do that? Thanks for any help you could provide, I'd be glad to provide any additional info that would be helpful. Regards, John
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.