This document discusses considerations for multithreaded architectures for test stand applications. It presents the case of a test stand with 4 independent test slots that uses some shared hardware. A single-loop state machine would not be sufficient to handle the multiple slots and user interactions. Multithreaded architectures can improve user interface responsiveness by offloading processing to separate threads. Approaches discussed include using multiple instances of independent slot objects or a single test stand object controlling multiple slot objects in separate threads. Key points are selecting the right architecture, considering alternatives, and identifying blocking operations to move to separate threads.
6. The Case
• Create the application for the test stand.
• 4 independent test slots.
• Some test hardware is shared between
slots.
• Operator mounts the UUT in the slot and
starts test. Operator then mounts another
UUT in another slot.
• Operator needs some control over the slot
when mounting UUT.
• Application needs to communicate with
PLC and other equipment.
8. Simple
State
Machine
• A single loop that combine
user interface control and
application logic.
*File->Create Project->Simple State Machine
9. Simple
State
Machine
• How do we handle multiple
slots?
• How do we handle user
interaction during test?
• How do we handle PLC and
other equipment
communication?
*File->Create Project->Simple State Machine
12. Improving User Interface
responsiveness
• 0.1 second is about the limit for having the user
feel that the system is reacting instantaneously
• 1.0 second is about the limit for the user's flow
of thought to stay uninterrupted
• 10 seconds is about the limit for keeping the
user's attention
*Jakob Nielsen, Usability Engineering (1993)
13. Queued
Message
Handler
• Respond to user actions
instantaneously in Event
Handling Loop
• Offload any processing to
Message Handling Loop
*File->Create Project->Queued Message Handler
15. Considerations
• Make User Interface independent from the application logic.
• Focus on proper messages design.
16. Considerations
• Make User Interface independent from the application logic.
• Focus on proper messages design.
• Start project using existing architecture (QMH, Delacor QMH, your
own code).
17. Considerations
• Make User Interface independent from the application logic.
• Focus on proper messages design.
• Start project using existing architecture (QMH, Delacor QMH, your
own code).
• Consider splitting UI into multiple VIs.
19. How to make 4 independent slots?
• Design a single Slot.
• Use 4 instances of this Slot in
application.
• Design a single Test Stand that
controls 4 Slots.
• Use 1 instance of Test Stand in
application.
20. Single Test Stand
• Slots are processed sequentially. They should not do too much
processing.
• Any message to the Slot must be sent to the Test Stand with proper
Slot ID.
21. Multiple Slot instances
• Every slot is independent from another. They can do heavy processing
internally without blocking each other.
• Any message must be send to proper slot using this slot specific
communication channel.
• Slot VI and all subVIs must be reentrant (harder debugging).
24. Considerations
• Select the right architecture for your application.
• Consider alternatives.
• Identify blocking and time-consuming operations, move them to
other threads.