Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation


About theoneandonlyjim

  • Rank

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2011
  • Since
  1. Cool. I’m not reinventing the wheel. I think so, at least on the face of it. In my most recent applications, I’ve applied OOP as far as my storage type goes – Storage (parent), Access DB (child), text (potential child), etc. My present approach is to bundle new data into an application-specific cluster, which is converted into a variant before input into a dynamic dispatch “Store” method. It works because the DB queries included with LV are able to decode the variant and insert results in the proper columns. I haven’t tried another file format because of time/lack of need, but I’d like to i
  2. I feel I've plateaued in my approach toward data storage. I am still stuck routing data from a tool through a central mediator to a component specifically designed to manage data. My applications have had low data rates or been manually controlled, so the approach has worked, but I'd expect that a faster data rate or more components could induce lag at some point. Here's a reduced-scale example: User presses "Store Data from A" or timer expires, message is sent to mediator >> Mediator routes "Store Data from A" message to Tool A >> Tool A makes measurement, passes to mediator >
  3. Unchecking "Inline" throughout the project did the trick. Thanks. I guess I have some learning to do about to what level I can use that option. Accessors only? Small operations like array indexing, adding, comparison? I'll look on LAVA and NI, but any insight is welcome. Agreed. The debug tool wouldn't connect and generated an access violation, so I was left with forum and Google crawls. I considered that it was reentrancy, but didn't think of inlining. When the VI got stripped to little more than an event structure, initialization code, and empty while loops and the EXE was still broken,
  4. As part of my latest debug process, I've been building EXEs with a basic test platform and the necessary support files - hopefully cutting down on places to look for problems in each component. The test platform in each case is a basic UI where I can enqueue messages (start, stop, do something) or receive messages (data, status, errors) plus the control code I want to trace. I've been successful with debugging and building several components (temperature readout and calculations, stage control, voltage measurement), but have hit a wall with building the last (a pair of power supplies). I have
  5. OK - I think I'm on my way to figuring this out, but I have a more specific question I hope will generate an answer. If I pursue this course of action, one of the "Choose Implementation" windows looks like the attachment. It seems like I leave myself open to slowdown as a result of the large dynamic dispatch tree the project would have to navigate through. Am I right in this thought? If so, to break it into smaller trees seems like it would require duplicates of the more basic methods that each parent class would have, since their class data would be very similar. This would lead to longer
  6. I've started a project as a way of transitioning from task-based to object-oriented programming. So far, I wish I'd put the effort in sooner. OOP solves a lot of problems I spent frustrating hours considering ways to get around. Platitudes aside, I want to make sure I'm making the right choices as I learn, so that the right practices are in place beginning early in the process. I favor a hierarchical architecture similar to what's been discussed in other topics on the board, and an observation I've made as I write is that much of the code falls into two categories: abstraction layers and medi
  7. Thanks for the illustration. It generated some additional questions for me. I'll admit I don't have a CS background, so please excuse any ignorance I show. When you say "don't know the specific VI at compile time", do you mean that I have (for example) three subVIs, and based on the input used to choose my plugin, I load the correct one? Or, do you mean that I'm leaving a placeholder for a VI with this specific connector pane that I haven't written yet? If it requires inclusion in my build, how is this an advantage over standard subVIs? If I'm not including VIs in my "always included" list f
  8. Sorry - I meant dynamically loaded VIs using Open VI Reference. OOP is something I've yet to tackle.
  9. I'm kind of new to the use of dynamic subVIs, but I've come to recognize just how powerful they can be. I'm revising some existing code and really want to implement them. Before I make them a part of the project, I've been working smaller examples scratch-pad style to get my head around a couple of concepts. I've been able to develop a main and sub-vi example that I've successfully built into an application. While doing so, I've come up with a couple of questions. I'll throw them out to the 'net and see what I get back. -For diagram clarity/readability, I intend to use subVIs within the dyn
  10. I've been working on a bug for sometime now. On two separate Windows systems (one XP and another Vista), I've run into a situation where I temporarily lose connection to a tool connected by USB - just long enough to throw an error in the code and stop the program. I have been thus far unable to figure out a set of conditions which induces this failure, which appears at irregular intervals: 700+ hours, 400+ hours, 48 hours after test start. This has now happened with a two different GPIB-USB and SCXI-1600 connected by USB. I've been told (and observed) two things: that occasionally Windows w
  11. I only need temp at that specific point in the loop, so I was trying to economize with my loops. I didn't think I needed to monitor T throughout and pick off at needed times, but it seems like the overhead involved with the "Start Task -> Take Measurement -> Shutdown Task" is throwing my timing out of sync. I'll try producer/consumer where I pass a current value from loop to loop, but there seems like something easier that I'm missing.
  12. Thanks everyone. Live in Raleigh, work in Durham, NC I hadn't thought of that. I'd better polish my "No, thank you, I'm all set on new hardware" speech. LAVA's been great for specific stuff, but I'm thinking more in the abstract. I don't always have a question, but I always need to learn. Like crelf suggests, I want someone better, whose code I can look at in an idle moment and say, "That's a great way to do that." Maybe I can drift around LAVA when I have that urge. I've been thinking of a change, maybe it's time. Any chance of a Raleigh branch opening?
  13. Not specifically from this board, necessarily, but I'm looking for ways to build my skills. I'm the only person who uses the language at my company and I get around well enough to run our test sector, but if I'm going to move up or on, I need to get better. Does NI sponsor user groups? Are there real-world LAVA lounges? Any pointers in the right direction are appreciated. Thanks.
  • Create New...

Important Information

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