Jump to content

GeorgeG

Members
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

2

About GeorgeG

  • Rank
    More Active

Profile Information

  • Gender
    Male
  • Location
    Washington, DC

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2013
  • Since
    1998
  1. The distinction between an actor and a service is somewhat lost on me.
  2. Thanks for pointing out that white paper. I hadn’t read it and it was enlightening about why the Actor Framework is the way it is. The coupling section is interesting, but it seems really quite difficult to get the zero coupling case. I am wondering if I have been using the Framework in an efficient way. Suppose we have a brain. The brain has eyes, feet, and a mouth, which itself has a tongue. The eyes report position and the feet can walk. The brain starts the feet walking until it is happy with the position reported by eyes. Maybe the brain wants to do something else while walki
  3. I've used the AF three times now in delivered applications and I am finding it is "just okay". I really like the concepts that it embodies, but its implementation of the details is very frustrating. My biggest gripe is in the coupling between actors. If I am actor A and want to send actor B a message, I have to call a method on actor B. Which is fine until I want to send the same message to unrelated actor C. It seems like actor A needs to “know†too much about the destination to be able to send messages. Next on my list would be how incredibly easy it is to write an unreadable app
  4. I've been looking for information on the details of what LabVIEW really does with these two different parameters specs. There doesn't seem to be much Google knows about the difference between the two (besides the obvious, one is handle and one is a pointer to a handle), or why you would use one vs another. I am working in the context of returning data to LabVIEW from external code, where I want to allocate memory in the external code. I understand about LabVIEW's handles, and what a pointer to a handle means. Why would you chose one of these paramter specs over another? From testing it
  5. Thanks Rolf! I thought I'd written code quite similar to yours, but it didn't work. Following along with your suggestions I did get something working... go figure. Pointers and handles are tricky beasts... not so impossible to understand, but very devil-in-the-details. I wasn't able to use the DSSetHandleSize function though... anytime I executed that branch of code an exception would get thrown (somewhere else). So for now I am just deallocating the whole thing, disposing the handle, and starting over (instead of trying to "resize"). Thanks again for your help!
  6. I'm not exactly sure what you're trying to do, but I took a stab at it anyway. Does this VI do what you want? Crude on-off event.vi
  7. I am trying to use the LabVIEW memory manager functions (DS/AZNewHandle,DS/AZSetHandleSize,DS/AZDisposeHandle,others) to populate the array of clusters shown below. The number of elements and the string lengths will not be known before the DLL call, so I am really trying to make it work as shown. I've tried quite a few combinations of Type/Data Format/Manager Function calls, but I consistently crash LabVIEW or create severe memory leaks. It isn't even 100% clear to me whether this is in Data Space or Application Zone. Google has been decidedly unhelpful. Can anyone help me /* insert code her
  8. I think this is what I am trying to wrap my head around. To do any local error handling I need to know what happened and what didn't happen right? If I tried to enqueue an element into a queue and I get an error from the enqueue function, I need to know what happened to the element before I try to do local error handling... local error handling shouldn't enqueue the element again if the operation was successful notwithstanding the error. Is it possible for that to happen? I'm not talking about specific error codes here. I just want to know for sure whether the element got into (or out of)
  9. So you could follow an Open with a Close-if-Error and that way you could make the open either fully succeed or fully fail. What about Enqueue or TCP write (or any of the others)? Is there a way to know whether the fuction failed completely?
  10. Whew, that really helps me constrain my thinking about how to deal with Close and its errors. Along similar lines I have been trying to understand what happens with the non-close primitives. Let's start with Open... if it returns an error, does that mean I am guaranteed that the open failed completely? That is, might I be left in an ambiguous partial state where some resources were allocated, but the open still failed? And is that behavior consistent? Obtain Queue, Open TCP Connection, Open VI Reference, etc And then the VI's that do work (like enqueue, TCP write, Start Async Call, Gener
  11. The close/release primitives for things like files, queues, notifiers, VISA references, TCP sessions, Application/VI/Control refnums, etc have an error out terminal. Many return error 1 if the input refnum is invalid (like a constant) or has already been closed. Close reference for VI server seems to return 1026 under the same conditions. What other conditions could cause a close function to fail besides having an invalid or previously closed input reference? Assuming there are other conditions, if a close function does fail, does it create a memory or resource leak? If by chance there ar
  12. I have some projects on the horizon that have to be more reliable than anything I have done in the past. And this new requirement has me thinking about how I deal with errors in LabVIEW more and more. Simultaneously I have been looking into the Actor Framework. The sample project in LabVIEW 2012 for the Evaporative Cooler does a great job of showing how many of the pieces of a full application fit together. However, as I have studied the example, I have noticed that in many places error handling has simply been ignored. An example of this is in the water level control... specifically, I take
  13. I am looking for a list of errors that could be returned by the things in vi.lib. I've tried searching, but the search terms are pretty generic and I get lots of links to the list of ALL error codes. But I want to know the (exhaustive?) list of errors that could be returned by each VI (like Enqueue Element, or Release Notifier, or Property Node). Does such a thing exist? It seems hard to do really good error handling without it... And hard to know what kinds of things will give the code trouble.
  14. Well I played around with some other apps on windows to see if there was a "standard" behavior. And it's true that nothing else really behaves the way LabVIEW did. That being said, LabVIEW still doesn't behave the same was as other Windows apps (at least on Win7). Both explorer and google chrome require you to release the right mouse button before displaying the context menu. *shrug* It isn't exactly the apocalypse... just one of those little things that irritates. In fact, the change was so subtle I first thought my mouse button was starting to break.
  15. Argh! I lose again. First it was the great palette shuffle caper. Now it is the right click menu! It is funny how something so tiny gets ingrained into such a strong habit. In 2011 and before you could right click a thing, hold the right button down, navigate to your choice and release. Now when you let go, LabVIEW just stares dumbly back at you. But hey, conditional tunnels! Yay.
×
×
  • Create New...

Important Information

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