StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POControlling a camera from Qt: interaction of OS threads with the event loop
primarykey
Id
10705490
data
AcceptedAnswerId
0
AnswerCount
2
ClosedDate
CommentCount
5
CommunityOwnedDate
CreationDate
2012-05-22T15:47:24.920
FavoriteCount
1
LastActivityDate
2016-10-27T15:12:16.110
LastEditDate
2012-06-02T12:48:45.480
LastEditorUserId
371248
OwnerUserId
371248
ParentId
0
PostTypeId
1
Score
0
ViewCount
1024
LastEditorDisplayName
text
Body
I'm working on a Qt application to control an industrial camera, and in particular I need to trigger the camera at a particular time (when various illumination settings have been put in place, for example), and wait until a frame is returned. In the simplest case, the following code does the job nicely: <pre><code>void AcquireFrame() { // Runs in the main GUI thread: camera -> m_mutex.lock(); camera -> frameHasArrived = false; camera -> m_mutex.unlock(); camera -> triggerImageAcquisition(); forever { camera -> m_mutex.lock() bool isReady = camera -> frameHasArrived; camera -> m_mutex.unlock() if (isReady) { return; } else { Sleep(10); } } } void callback(camera *) { // Called by the camera driver from a separate OS thread - not a Qt thread - // when a frame is ready: camera -> m_mutex.lock(); camera -> frameHasArrived = true; camera -> m_mutex.unlock(); } </code></pre> ...and most of the time this works perfectly well. However, this being the real world, occasionally the camera will fail to receive the trigger or the computer will fail to receive the frame cleanly, and the above code will then go into an infinite loop. The obvious thing to do is to put in a timeout, so if the frame is not received within a certain time then the image acquisition can be attempted again. The revised code looks like: <pre><code>void AcquireFrame() { camera -> m_mutex.lock(); camera -> frameHasArrived = false; camera -> m_mutex.unlock(); camera -> triggerImageAcquisition(); QTime timeout; timeout.start(); forever { timeout.restart(); fetch: camera -> m_mutex.lock() bool isReady = camera -> frameHasArrived; camera -> m_mutex.unlock() if (isReady) { return; } else if (timeout.elapsed() > CAM_TIMEOUT) { // Assume the first trigger failed, so try again: camera -> triggerImageAcquisition(); continue; } else { Sleep(10); goto fetch; } } } </code></pre> Now, the problem is that with this latter version the failure rate (the proportion of 'unsuccessful triggers') is much, much higher - at least an order of magnitude. Moreover, this code too will eventually find itself in an infinite loop where, however many times it tries to re-trigger the camera, it never sees a frame come back. Under these latter circumstances, killing the application and checking the camera reveals that the camera is in perfect working order and patiently waiting for its next trigger, so it doesn't appear to be a camera problem. I'm coming to the conclusion that in fact it's some sort of a system resource issue or a thread conflict, so that Qt's event loop is not allowing the camera callback to be called at the proper time. Is this likely, and is there in fact a better way of doing this? <hr> Update on 6th June: For what it's worth, I've seen no more problems since I adopted the method below (having given the camera object an extra member, namely a QWaitCondition called 'm_condition'): <pre><code>void AcquireFrame() { bool frameReceived; forever { camera -> triggerImageAcquisition(); camera -> m_mutex.lock(); frameReceived = camera -> m_condition.wait(&camera->m_mutex, CAM_TIMEOUT); if (frameReceived) { // We received a frame from the camera, so can return: camera -> m_mutex.unlock(); return; } // If we got to here, then the wait condition must have timed out. We need to // unlock the mutex, go back to the beginning of the 'forever' loop and try // again: camera -> m_mutex.unlock(); } } void callback (camera *) { // Called by the camera driver from a separate OS thread - // not a QThread - when a frame is ready: camera -> m_condition.wakeOne(); } </code></pre> This still has the effect of pausing the main thread until we have either received a frame or experienced a timeout, but now we have eliminated the Sleep() and the Qt event loop remains in full control throughout. It's still not clear to me why the old method caused so many problems - I still suspect some sort of system resource limitation - but this new approach seems to be more lightweight and certainly works better.
Tags
<multithreading><qt><camera><sleep>
Title
Controlling a camera from Qt: interaction of OS threads with the event loop
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. This table or related slice is empty.
PostTypePostTypeId
1. PTQuestion
UserLastEditorUserId
1. USEos Pengwern
UserOwnerUserId
1. USEos Pengwern
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. PO
 singulars
 PostTypePostTypeId
 PTAnswer
2. PO
 singulars
 PostTypePostTypeId
 PTAnswer
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.