Results 1 to 13 of 13

Thread: Threading or not - best way to regularly check/wait

  1. #1

    Thread Starter
    Addicted Member
    Join Date
    Sep 2013
    Posts
    144

    Threading or not - best way to regularly check/wait

    Hi,

    I have two cases that are closely related around the subject of waiting/checking some status before updating, but at a different scale.

    1. The first case:

    I have a button that triggers an external dll method. When the command is received it takes around 6-7 seconds for a controler to perform this command.

    For the moment I have a Do ...Loop Until status=correct. inside the loop I send the CheckControlerStatus method from the DLL + a WaitOne(200) method from a ManualResetEvent(False).

    The button is a Position ON / Position OFF button, meaning it always trigger the same movement witht he same delay back and forth.
    Is there a better way to wait for these 6-7sec while communicating with the controler ? I would like to avoid asking the controler for his status so often if possible. I tried to increas ethe time for the WaitOne but the problems with the controler answers increase in this case.


    2. Second case:

    For the moment I start a thread at LOAD time refreshing 6 textboxes. It needs to have a ~200ms refresh rate at maximum. this thread is presently running while the app is running (never stops).
    I would like this refresh to be started by the first click on one of the 6 "go" buttons facing the textboxes (they all are buttons that start a movement and the textboxes have the positions of the movement updated every ~200ms). And the refresh to be stopped when the movement is over. Then if I click on another one of the "go" buttons (or even on the same one), the refresh starts again; and again stops when the movement is over.

    For the moment the refresh is in a thread that runs all the time as I mentionned, so it's not linked to any of the buttons or the end of a movement. But I really only need it when a movement is starting/occuring. As some events can interrupt the movement I need to have the position at which it has been stopped, hence the refresh every 1/5th sec to display the position in a textbox.

    What would be a better way to implement this without having a second thread ticking all the time like I did ?

    Thank you !
    Last edited by LiamC; Jul 22nd, 2014 at 06:40 AM.

  2. #2
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,989

    Re: Threading or not - best way to regularly check/wait

    In the first case, what you are doing seems reasonable. I would increase the delay, but you state that it causes some kind of problem that I didn't understand. If you know the action will take X seconds, then you could theoretically sleep the thread that is waiting for just less than X seconds. However, if your actions resulted in checking just before the event occurs, then the event would occur during the next sleep cycle, and you would be almost one full sleep interval late. For example, if the event would occur in 6 seconds, and you slept the thread for five seconds, you would certainly not see the event for 10 seconds. The first 5 second interval would elapse and the event would not have occured, so you'd sleep for another 5 seconds, at which point the interval would have occured....four seconds back. If you made the interval 7 seconds, then you should see the event after that first interval, but if anything delayed the event for a bit over a second, then you'd see it in the second interval.

    What you are doing is checking in much shorter intervals. You will be a bit late responding to the event, but never more than one interval, which in your case would be 0.2 seconds, which isn't much. The longer you make that interval, the longer the worst case scenario will wait. On the other hand, the shorter you make the interval, the more time you waste checking for an event that hasn't occured. The balance you have struck seems pretty reasonable to me.

    As for the second question, it seems like you need only start the thread in the button click event, then let the thread do as it must, and when the thread is finished, it expires. The thread doesn't have to live longer than the method it is performing, as long as you can determine when it is supposed to end. In fact, this sounds like a Task rather than a thread (Tasks are slightly lighter weight threads). The idea would be that when you start the Task, it begins a loop that does an update every 200ms until it determines that the movement has finished, and then the method exits, which ends the task. That is dependent on the Task being able to tell that the movement has ended, though.
    My usual boring signature: Nothing

  3. #3

    Thread Starter
    Addicted Member
    Join Date
    Sep 2013
    Posts
    144

    Re: Threading or not - best way to regularly check/wait

    OK thanks Shaggy Hiker,

    In the first case, I think the small problems (delay or a bit of unresponsive period) lie with the fact that the controler is network connected (ethernet) and maybe I'm asking too much to get the "ready after motion" status. The other answer could be that the long lasting thread that I start (case 2) is not well accepted by this one (although they are not interfering with the same objects, the case 2 refresh is pointing at 6 textboxes that are not concerned by case 1).

    The second case is the one that concerns me the most, because all motions are involved. I will look for tasks on MSDN too see what I can do at this point.

    If the thread/task really ends at the end of the method that it's linked to, then all I need to test is start the thread 6 times from the 6 "go" buttons, right ? Thread/Task will then start with the button click and end with the end of the motion method and start once again with the next click on one of the 6 buttons. In this case it seems I only need one thread/task that repeats itself ?

    Cheers for the hints !

  4. #4
    PowerPoster Evil_Giraffe's Avatar
    Join Date
    Aug 2002
    Location
    Suffolk, UK
    Posts
    2,555

    Re: Threading or not - best way to regularly check/wait

    In the first case, I would investigate the API of the DLL to find a way of asking to be notified of the completion of the action, either by passing in a callback, or by handling an event, or some other mechanism. If there isn't one, are there any other libraries you could use that do have such a construct?

    The second case sounds like a classic example of animating. When you click a button, you should check if any animation is currently in progress. If not, mark that an animation is in progress, and then write some state to a field that will allow you to determine the correct position of the textboxes at a given time. Then kick off a Windows Forms Timer that is set to tick every 200ms (this shouldn't make the Forms Timer break a sweat). In the timer's Tick handler, first of all calculate the correct position for the current time for each textbox, move the textboxes and then check whether the animation is complete. If it is, stop the timer and mark the animation as not active so that the buttons can work again.

  5. #5

    Thread Starter
    Addicted Member
    Join Date
    Sep 2013
    Posts
    144

    Re: Threading or not - best way to regularly check/wait

    Ok Evil, I think the timer is a good idea.

    I think I didn't express myself correctly when I read the end of your post. The texboxes don't move. They display the position returned by a motion controler. The controler has 6 axis connected to it and those axis will move upon command.

    To have a seemingly flawless display of the POSITION of these axis when they are in motion, I need to refresh Textbox number i that is concerned by axis number i, every 200ms or so.

    When an axis starts, stops or a motion is canceled (all methods are provided by the external DLL from the controler manufacturer) the texbox will display a rather precise position of the axis when the event occured.

    A motion is in progress only when a command has been sent to an axis, i.e. when I clicked on a "goto" button. Simple example: axis 1 is at position=0, user enters 200 µm in an input textbox and clicks "goto", axis 1 goes to position=200. If a cancel is needed or an unexpected error occurs, I want the "precise" position of the axis when it stopped (displayed in a textbox). And I need it for every axis (6 in total).

  6. #6

    Thread Starter
    Addicted Member
    Join Date
    Sep 2013
    Posts
    144

    Re: Threading or not - best way to regularly check/wait

    Now if I continue on the first idea provided by Shaggy Hiker:

    - I'd like to start my motion thread at the same time as the refresh thread.
    To do so, I'm thinking of a AutoresetEvent(false): WaitOne() in the refresh thread and the Set() method in the motion thread (just after the external DLL "MoveAxis" method). If I got it right, this way, the refresh thread will wait for the flag to be raised by the motion thread.

    Now, my question for this: how to start two threads that will BOTH be started again and again (by every click of a "go" button) ?
    I will next try the following (twice the same):

    vbnet Code:
    1. '
    2.  
    3. If IsNothing(MotionTh) OrElse Not MotionTh.IsAlive Then
    4.                 MotionTh = New Threading.Thread(AddressOf MotionMethod)
    5.                 MotionTh.IsBackground = True
    6.                 PROCTh.Start()
    7.  
    8. End If
    9.  
    10. If IsNothing(RefreshTh) OrElse Not RefreshTh.IsAlive Then
    11.                 RefreshTh = New Threading.Thread(AddressOf RefreshMethod)
    12.                 RefreshTh.IsBackground = True
    13.                 RefreshTh.Start()
    14.  
    15. End If

    Can it work to start 2 threads from the same button.click ?

    Important thing to note: each motion will wait for the one before to finish (for instance: axis x moves from 0 to 200, axis Y will wait before beginning its motion. This is done with the controler DLL, no additional VB.NET code is needed => two calls to the "MoveAxis" method will be synchronous, motion 2 will only start after motion 1 has ended.

    Cheers,

  7. #7
    PowerPoster Evil_Giraffe's Avatar
    Join Date
    Aug 2002
    Location
    Suffolk, UK
    Posts
    2,555

    Re: Threading or not - best way to regularly check/wait

    What framework version are you targeting. With the additional context I'd say using Tasks would help you out a lot rather than creating all those threads (threads are super expensive to create and destroy, which is why things like the ThreadPool exist)

  8. #8

    Thread Starter
    Addicted Member
    Join Date
    Sep 2013
    Posts
    144

    Re: Threading or not - best way to regularly check/wait

    I have framework 4.0 and VB.NET on Visual Studio 2010 and win7. The workstation is intended for image processing aswell so it is a very powerful PC.

    I never worked with tasks so I'd be glad to have a few hints as where/how to begin as I've only looked at MSDN a bit since Shaggy Hiker pointed out it might be the best answer. Is the behaviour the same as with threads ?

  9. #9
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,989

    Re: Threading or not - best way to regularly check/wait

    Tasks are simpler than threads, which is why they were introduced (multi-threading is important and potentially difficult, so better and better tools show up). The Task would be very much like your thread, except that you can chain an action to perform once it completes, wait on a bunch of them...and really so much more that it can't be simply described. You may even find that it makes sense to fire off a Task every 200ms to get one position rather than fire off a Task to do the whole polling thing. That could be problematic, though, as there is no guarantee that the Tasks would occur in order. A stranger approach would be to fire off a Task to get the current state, show that state, then fire off a Task again, and so on. In other words, you'd have a Task getting the current state (generally it will happen on a different thread), and keep repeating the Task once the current Task returns rather than looping. That's probably a really bad idea, though, because it would be happening way too fast. Having a position update five times a second is likely to be faster than your eye can register, but WAY slower than the API would answer, so chaining Tasks would be wastefully fast.
    My usual boring signature: Nothing

  10. #10

    Thread Starter
    Addicted Member
    Join Date
    Sep 2013
    Posts
    144

    Re: Threading or not - best way to regularly check/wait

    Thx Shaggy hiker,

    Eventually, what approach would you recommend with the use of tasks knowing the context ?

  11. #11
    PowerPoster Evil_Giraffe's Avatar
    Join Date
    Aug 2002
    Location
    Suffolk, UK
    Posts
    2,555

    Re: Threading or not - best way to regularly check/wait

    Does the textbox need to visually update every 200ms? That seems a little odd to me. Think of the UX: The textbox currently shows 0. The user types in 200 and clicks the Go button. The textbox jumps back to 0 and counts up to 200 as the servo rotates.

    How about a slightly different approach: The textbox currently shows 0. The user types in 200 and clicks Go. The textbox remains showing 200, but in a disabled/readonly state. When the servo finsihes rotating, the textbox shows the value the servo finished on and re-enables itself.

    That way you can have a single Task for each button press that produces the stopping position of the servo movement.

  12. #12
    PowerPoster Evil_Giraffe's Avatar
    Join Date
    Aug 2002
    Location
    Suffolk, UK
    Posts
    2,555

    Re: Threading or not - best way to regularly check/wait

    Also, don't think of Tasks compared to threads. Tasks are a much higher level abstraction of "work that needs to be done" along with associated ways of defining when it should be done (Schedulers) and what should happen when it is finished (continuations). Some usage of Tasks won't involve threading at all.

  13. #13

    Thread Starter
    Addicted Member
    Join Date
    Sep 2013
    Posts
    144

    Re: Threading or not - best way to regularly check/wait

    Thx Evil,

    In response to your first post:

    I already have the display of a single position after the axis have stopped: One request when the axis status is "ready after motion" and I display the position. So that isn't a problem. The textboxes are already readonly aswell.

    I want to be able to check the position almost real time AND display the stopped position (be it end of motion or cancelled)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width