Delay inside a worker thread

Hi,

I need some help/guidance on improving an application that we have. This 
application controls an XY cutting table machine and does this by interfacing 
with a motion control board (the board manufacturer provide an C++ API ).
Since it's a cutting machine, some tools must be turned on/off during its 
operation. This is archived by setting bits in I/O ports calling a function 
API. This bits must be set on /off in a predetermined order and must be a 
delay between this callings (some tools have an pneumatic actuator and they 
take some time to get in position). The API doesn have a elay function
for this, so the program must do this.

The application has 3 threads, the main thread, a otion controlworker 
thread (MC_T) and a onitorworker thread that just read the I/O ports 
(MO_T). The I/O bits are set in the MC_T worker thread and the delay is 
performed using de Sleep MFC function. We choose to put the thread in sleep 
because it use no CPU cycles and it will give a delay at least as long as the 
programmed sleep time (I understand that due to scheduling in Windows the 
time that the MC_T thread will become active will be longer that the 
programmed sleep time). The delay values usually are between 50 to 1000 ms. 
I looking for ways to improve this response time inside my threads. In 
other words, if the defined value was 60ms for some port for example, the 
MC_T waits only 60ms before executing the next block of code. It desirable 
that the new approach doesn consume CPU cycles.

Thanks !

Hi,
Which verson of windows are you using, and which compiler are you 
developing with?

Does the board manufacturer provide callbacks which you can register for 
i.e. tell me when the status of something is such and such, then you get a 
hardware interupt which is signalled to your callback function in real 
time? They may even provide hardware timers which you can program and 
register for notification.

Alternatively, you can use a multimedia timers
 http://www.**--****.com/ 
m/_win32_about_multimedia_timers.asp

To be honest though, it sounds like your hardware and driver set is a 
little bit lacking. You can turn a tool on, and you can turn it off, so why 
can't you turn it on for a specific period of time. This should be provided 
by the device driver, you should simply have to call an API with an On Off 
flag and a period of time. Alternatively, the driver should inform you when 
the operation has completed with a callback.

Andy Mortimer [MS]
Please do not send email directly to this alias. This alias is for 
newsgroup purposes only

This posting is provided "AS IS" with no warranties, and confers no rights. 
OR if you wish to include a script sample in your post please add "Use of 
included script samples are subject to the terms specified at 
 http://www.**--****.com/ " 

Hello again

Thanks for the help Andy.
I'm using Windows 2000 and Windows XP, Visual Studio .NET2003 and C++ with 
MFC (no .NET framework is used).

About the board and API I think that I wasn't very clear in my explanation. 
The problem is not to let tool on/off for some period of time. Is more like 
switch the tool on, wait x seconds then execute next block of C++ code. I 
really would appreciate if the manufacturer had provided a function that will 
wait xx seconds after the port was set, but that is not the case ... This 
board has 4 ports, each one has 7 bits. Setting the bits in a particular port 
turns that I/O line on/off, but the function expetcs to receive a bitmap of 
bits to set. So all bits on that port are set at once. 

I'm looking at that link and I think that CreateWaitableTimer can do the 
trick. Since we design that part of code in a more procedural way rather than 
event-drive I think it can be more easily adapted.

Many thaks !

I think that what you have to do is ditch the worker thread and the sleep, and 
instead opt for UI threads.

You can have multiple layers of threads with the controlling thread looking 
after the timers and logical device state etc.

Create invisible windows and use PostMessage to communicate between the threads 
(you should logically be using PostThreadMessage, but because of a fundamental 
design flaw in Windows they are useless).

Tulio: Have you tried the Sleep() solution?  If the PC is not heavily 
loaded with other tasks then you will find, on average, that the Sleep() 
duration is quite close to the requested interval.  You could also 
improve it by using SetThreadPriority in the sleeping thread.

Ian: I use PostThreadMessage heavily and find it to be utterly reliable. 
  It is, of course, necessary to respect the documented limitation that 
the destination thread cannot display windows or message boxes.  But 
this is acceptable and hardly a fundamental design flaw.  Why do you 
assert that PostThreadMessage is useless?

-- 
Scott McPhillips [VC++ MVP]

In article < XXXX@XXXXX.COM >, 
 XXXX@XXXXX.COM  says...

[ ... ]



The most obvious choice would be to use multimedia timers instead of 
Sleep. The system is written to go to extra lengths to assure quick 
response to multimedia timers.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

Because they don't always get through.

If you are using PostThreadMessage, try moving windows about the screen or 
something that generates a lot of messages and PTM's will be lost.
If you post to a window they are not.
In a thread, you can never be sure what other threads or the main thread is doing.
I noticed there is some discussion in the 'PostThreadMessage Function' in VC7 
help about how you work around this, but I have found it much more reliable to 
use PostMessage to windows.