After the practice project is corrected, the operator sees the simulated tank fill, the pump status follow the sequence, and an alarm clear only when its cause is gone and it is acknowledged. Build that behavior in a standalone InTouch application with simulated values; keep the exercise disconnected from any real control network.
Does the screen show the right value for the right tag?
Start at the operator display and trace each indication backward. For a tank exercise, choose one level value, one pump command, and one pump-running indication. Give each a clear name and define what value or state it represents before binding it to a screen object.
| Screen indication | Tag or source to inspect | What the reading tells you |
|---|---|---|
| Tank level | Simulated level value | Whether the displayed number follows the intended changing value |
| Pump command | Operator command tag | Whether a button or control changes the intended command |
| Pump status | Simulated running indication | Whether status is distinct from the command and follows the exercise logic |
| Alarm state | Alarm condition and acknowledgement state | Whether the triggering condition and operator acknowledgement are represented separately |
If the tag value itself is wrong, investigate the simulated source or logic before changing the screen. If the tag is correct but the display is wrong, inspect the screen object's binding, formatting, or animation configuration. This separation prevents a binding fault from being mistaken for a control-logic fault.
Does the value change at the source, driver, and controller layers?
For a standalone exercise, establish where each value originates. A value may be entered or generated by the application, or it may come from a configured external data source. Do not assume a driver or controller is involved unless the practice setup actually uses one.
- Change or simulate one input, such as a level value, at its source.
- Read the corresponding InTouch tag. If it does not change, check the tag definition and, when applicable, the communication path or driver diagnostics.
- If the tag changes but the display does not, inspect the object's tag binding and visual configuration.
- If the display changes but the expected action does not, follow the command tag into the application logic and inspect the resulting status separately.
When an external source is part of the lab, check the configured source identity and connection state before editing scripts. A disconnected source and a valid source with a bad display binding produce different symptoms: the first prevents fresh data from reaching the tag; the second leaves a usable tag value that the screen is not presenting correctly.
Does the pump sequence respond correctly at each boundary?
Build a small sequence around a simulated tank level rather than starting with a large application. Define the intended start and stop conditions, the pump command, and the running indication. Choose the boundary values yourself as exercise parameters; they are not universal operating settings.
- Record the start condition and stop condition in plain language before writing logic.
- Make the simulated level move through values below, at, and above each boundary.
- Observe the pump command and running indication separately at every test point.
- Repeat the boundary tests after changing a value, and check for unintended switching or a command that remains latched.
Testing only a value well inside the normal range misses comparison errors at the transition. For example, a condition using “greater than” behaves differently at equality than one using “greater than or equal to.” Select the comparison deliberately and test the exact boundary.
Does the alarm distinguish the cause from acknowledgement?
Add an alarm only after the underlying simulated condition works. Use a clearly defined condition, such as a level crossing an exercise limit. Keep the process condition and operator acknowledgement conceptually separate: acknowledging an alarm records operator response; it does not itself remove the condition that triggered the alarm.
| Test reading | Interpretation | Next check |
|---|---|---|
| Condition false, alarm inactive | Normal state for this test | Drive the simulated value across the chosen limit |
| Condition true, alarm inactive | Trigger logic, tag, or alarm configuration is not producing the expected state | Check the source tag and the configured alarm condition |
| Condition true, alarm active | Trigger path works | Acknowledge and confirm the condition remains active |
| Condition false, alarm still displayed | Displayed state may reflect acknowledgement or alarm history rather than a current cause | Inspect the alarm object's configuration and current condition separately |
Do the InTouch scripts preserve the intended sequence?
Keep the first script exercise narrow. Implement one action, such as changing a simulated command, and then prove the resulting tag change on the screen. Do not copy script syntax from an unrelated InTouch generation or configuration; use the scripting editor and help appropriate to the installed environment.
Separate input handling, sequence logic, and display behavior where practical. A button should not be treated as proof that a pump is running: the command and the feedback indication represent different states. Test script behavior with the command initially false, after activation, and after the reset or stop action. If one test fails, inspect the command tag first, then the script trigger and condition, then the status/display binding.
Expand the same method into conveyor counting or traffic-light exercises: define inputs and outputs, enumerate expected transitions, test each transition, and verify the screen against the underlying tag values. Add acknowledgement or logging only after the base sequence behaves as specified.
Frequently asked InTouch practice questions
What happens if the tag changes but the screen does not?
The data exists at the tag layer, so inspect the screen object's binding, formatting, and animation configuration before changing the simulated logic.
What happens if a pump command turns on but running status stays off?
Treat command and status as separate values. Check whether the exercise logic updates the simulated running indication, then verify that the status object is bound to that indication.
What happens if an alarm remains visible after the level returns to normal?
Check the current alarm condition separately from acknowledgement and any displayed alarm history. Confirm the configured behavior for clearing or retaining the indication.
What happens if I want to practice without a controller?
Use a standalone application with simulated values and verify the tag, logic, and screen at each test point. The final verification is to move the simulated input across every defined boundary and confirm the displayed value, command, status, and alarm state match the expected sequence.