Jump to content

Michael Aivaliotis

Administrators
  • Posts

    6,217
  • Joined

  • Last visited

  • Days Won

    120

Posts posted by Michael Aivaliotis

  1. QUOTE(Jim Kring @ Apr 20 2007, 10:06 AM)
    You should be forewarned that this is not just a place for you to get answers to your questions.
    I agree that LAVA is a lot more than "answers to questions", however let's not scare those that want to ask questions. Questions are perfectly fine and acceptable here as long as you are not a homework hustler (HH) - A student that tries to get solutions to homework questions.
  2. QUOTE(Eugen Graf @ Apr 17 2007, 07:55 AM)

    Your code does not make sense:

    1. In the top event structure, you are generating a user event.
    2. The bottom event structure responds to this and executes the <Command> case.
    3. The top loop is ALSO registered for the same event. It ALSO responds to the same event however it's too late, the message has already been removed from the queue from the bottom event structure. It then just iterates a timeout.

    What is the purpose of your design? Multiple recipients? If so, then you need to use a different approach. See attached image:

    QUOTE(Tomi Maila @ Apr 17 2007, 07:58 AM)

    :)

    Agreed.

    QUOTE(Eugen Graf @ Apr 17 2007, 08:23 AM)

    And I know too, that two event structures in one VI have to be avoided.

    This is not true. You can have multiple event structures without problems as long as they are not using the same event registration refnum.

    QUOTE(Eugen Graf @ Apr 17 2007, 08:23 AM)

    Another option is to create the user events in the main task VI and pass this to the other tasks, however register the events at the task level.

    QUOTE(Eugen Graf @ Apr 17 2007, 08:36 AM)

    P.S. firstly I wanted to replace Queues in tasks with User Events, because I have this problem:

    How do you think, what is better to use Queues or User Events? What is faster and eats less memory?

    You are presenting multiple issues here. Are you trying to get speed and less memory, or are you trying to solve your problem? The reason I'm asking is because you don't need to switch to a completely different architecture to solve your problem. Queues are pretty powerful on their own and still viable for your situation. From what I can see, your problem is that you are mixing your communication mechanisms. Why use "Set Value Property" on top of queues? You already have the pipeline so utilize it. See:

  3. Just want to apologize to all for the latest server outage. This was purely my fault and not due to any hack\crash or anything of the sort. Apparently, when you tell the server software to create a backup of all your domains on a daily basis, it does what you tell it... until your hard drive fills up! How nice! :headbang:

  4. QUOTE(Jim Kring @ Apr 13 2007, 11:37 AM)
    the software service providers that provide the best service to their customers and treat them well will win (I hope).
    None of the bugs I cared about were fixed in 8.2.1. as indicated from the NI buglist. So NI has dissapointed me with the 8.2.1 release. Am I being selfish? Of course I am... I'm a customer.
  5. This is a good point and is an issue I'm trying to resolve. Currently, every edit will generate a new revision. This is why it's important to include the revision number in the zip filename. This way we can determine if it's a real file change or just an edit to the page.

    The moderators have access to delete or hide the unnecessary files. I'm not sure if you (as an owner of the file) have this permission. I don't think you do.

  6. The number has been reduced to 50. Regardless of the number, there is always the chance that you will miss something. What happens if you are away from your computer for a week? Should the number be changed to 1000 to accomodate you? Thus is the nature of RSS. The higher this number, the more resources used on the server to cache these posts and generate the feed.

×
×
  • Create New...

Important Information

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