KpWorkflow: Activation Is Required, Not File Copying

KpWorkflow can appear fully deployed while doing nothing on the operator screen. Copying its files only makes the assembly available to Rapid SCADA; newer Rapid SCADA deployments also require module activation in Administrator. Diagnose the path from the screen backward: HMI binding, server channel or tag, workflow task, driver loading, and controller communication.

What is the screen telling you?

An unchanged value or an unresponsive pump command does not identify the failed layer. The screen only proves that the displayed object has not received the expected state. Trace the signal backward before changing the control logic.

For a control action, confirm both directions separately. The command path runs from the screen through its binding, server processing, workflow logic, and communication layer. The feedback path returns controller state through communication and server channels to the display. A command indication alone does not prove that the controller received or executed the request.

Why is copying the KpWorkflow files not enough?

A DLL on disk is passive until the host discovers, loads, and enables it. Rapid SCADA separates deployment from runtime configuration: files provide executable code, while the project configuration determines whether that code participates in operation. In newer Rapid SCADA versions, activate the module in Administrator after placing the required files in their documented locations.

This distinction explains the common symptom: file deployment completes without a copy error, yet no workflow behavior appears. Check the active project rather than repeating the file copy. If the installation exposes a module list or runtime status, KpWorkflow must appear there as loaded and active.

How should the runtime path be checked?

Start at the host that owns each component. Communicator drivers and SCADA Server modules are DLL libraries, while Webstation plugins contain a set of files. Treat those component types as different extension points; copying a library into an unrelated plugin or server location will not make it execute.

1. Open the active Rapid SCADA project in Administrator and find the configured module or driver entry associated with KpWorkflow.
2. Confirm that the entry is enabled for the active deployment. File presence is not a substitute for this state.
3. Review the runtime diagnostics for a successful assembly load. Resolve missing dependency, configuration parsing, or initialization errors before testing workflow logic.
4. Confirm that the intended workflow task is configured and eligible to execute.
5. Trace each task input to its SCADA channel or tag and each output to its consumer.
6. Verify that the HMI object references the same server item used by the workflow path.

If the screen reads a healthy channel but the workflow never acts, inspect task execution. If the workflow produces the correct value but the screen remains unchanged, inspect the Webstation binding and data refresh path. This split prevents a display problem from being mistaken for a driver failure.

How do you configure KpWorkflow without guessing?

Use the KpWorkflow documentation linked from the beginning of the driver description for the task schema and core behavior. The initial fixed version included a limited number of tasks intended for Rapid SCADA, with task descriptions and core documentation written in English. Do not infer unsupported task names or configuration fields from another driver.

1. Select an existing KpWorkflow task that matches the required operation.
2. Map its inputs to known SCADA data points and its outputs to dedicated test points before connecting live control commands.
3. Define explicit permissive, interlock, and feedback conditions in the project logic appropriate to the machine.
4. Apply the project configuration using the normal deployment procedure for the installed Rapid SCADA version.
5. Observe the task result and runtime diagnostics before binding it to an operator control.

For pump control, separate request, permissive, output command, running feedback, and fault state conceptually even when the final project uses fewer visible objects. A workflow request should not be treated as proof of motor operation; use controller or field feedback for the displayed running state.

When is a custom task library appropriate?

Use a supplied task when its inputs, outputs, and execution behavior match the requirement. Develop a custom task only when the required logic cannot be represented by the packaged task library. Custom development requires the applicable extension interface, build references, deployment location, and a compatible example; the exact API and library targets must come from the KpWorkflow documentation or published source package.

The packaged task is the preferred path because it removes custom build, compatibility, and deployment variables. When a custom task is necessary, begin from the closest official example rather than guessing the interface from a compiled DLL.

How do you verify the fix from screen to controller?

1. Confirm that KpWorkflow is active in Administrator and loaded without a runtime error.
2. Drive a known test input through a safe value change.
3. Observe the corresponding channel or tag at the SCADA Server layer.
4. Confirm that the workflow task executes and produces the expected output.
5. For a control path, verify the command at the communication layer and then verify independent controller or field feedback.
6. Check that the HMI object displays the feedback item rather than merely echoing the command request.

Recurring pitfalls include editing a project that is not the active deployment, activating the wrong component type, testing before the host reloads the configuration, mapping the workflow to one data item while the screen reads another, and using command state as process feedback. Record the observed value at each layer; the first layer where the value diverges identifies the fault boundary.

FAQ