Configuring KFlop Switch Alarms Through KMotionCNC

KFLOP sees the hardware-switch change, but the PC dashboard receives nothing until the controller explicitly asks KMotionCNC to run a configured action. Start here: configure M100 as an Execute PC action, then call DoPCInt(PC_COMM_MCODE,100); from the KFLOP C program. Keep PC_COMM_MCODE equal to 14; it is not M100 minus one.

Read the switch symptom first

The panel symptom separates the input problem from the PC-command problem. Confirm that the KFLOP program detects the switch before changing batch files, SQL logic, or dashboard code. If the input state never changes in the controller, the PC path is not the fault.

Do not begin by adding file writes to the controller. A text file may transport data, but it adds file-format, path, locking, and polling issues before you have proved that the switch event reaches the PC.

Understand the command path

The useful architecture has three stages:

1. The KFLOP C program reads the hardware input and recognizes the required state change.
2. The program requests a KMotionCNC M-code action through DoPCInt.
3. KMotionCNC executes the PC-side action assigned to that M code, such as a program or batch file that updates the dashboard data.

This division matters. The controller handles deterministic input logic. The PC application handles operating-system work and any database or dashboard integration. The demonstrated interface is a request to KMotionCNC; it is not evidence that a KFLOP C program directly launches an executable or directly writes to SQL.

The two numeric arguments have different jobs. PC_COMM_MCODE identifies the PC-command operation and remains 14 in the supplied pattern. The second argument, 100, selects the configured M100 action. Changing the definition to 99 confuses the command selector with the requested M-code number.

Prepare the KMotionCNC action

Configure and test the PC side before calling it from KFLOP:

1. Assign M100 to an Execute PC action in KMotionCNC.
2. Associate that action with the required executable or batch file.
3. Run the M100 action through the normal KMotionCNC path.
4. Verify that the target program starts and performs the intended update.

If this manual test fails, changing the KFLOP C program wastes time. Correct the PC action, working directory, arguments, access rights, and downstream application behavior first. When a batch file passes data onward, log its received values and completion result on the PC side so that a successful launch is distinguishable from a successful dashboard update.

Keep the action short or hand work to a separate PC process. A dashboard update can fail after launch because of application errors, database connectivity, or malformed data; those failures belong in PC-side diagnostics rather than the controller input routine.

Request M100 from the KFLOP program

Use the command pattern from KFLOPtoPCCmdExamples.c:

#define PC_COMM_MCODE 14

DoPCInt(PC_COMM_MCODE,100);

Place the call in the branch that handles the required switch event. Do not call it unconditionally on every scan while the input remains active. Store the previous input state, compare it with the current state, and request M100 only on the desired edge—for example, when the switch changes from inactive to active.

A practical event sequence is:

1. Read the switch through the input mechanism already used by the machine program.
2. Compare the current state with the saved previous state.
3. On the selected transition, call DoPCInt(PC_COMM_MCODE,100);.
4. Save the current state for the next program cycle.

Mechanical contacts may change state several times during one physical operation. If testing shows duplicate events, apply input filtering or debounce logic appropriate to the switch and scan behavior. Read the required interval from the switch data and machine response requirements; no fixed debounce time applies to every installation.

Verify each boundary

Test one boundary at a time. This prevents a dashboard failure from being mistaken for a KFLOP input fault.

1. Watch the controller’s interpreted input state and operate the switch. Confirm both states and the intended transition.
2. Add temporary diagnostic indication around the event branch. Confirm that it executes once per operation.
3. Invoke the configured M100 action manually in KMotionCNC. Confirm that the PC command works without KFLOP involvement.
4. Run the KFLOP C program and operate the switch. Confirm that DoPCInt requests M100.
5. Check the PC-side program’s log or observable output. Confirm that it received the event and completed the dashboard update.
6. Cycle the switch repeatedly, including slow operation and long holds. Confirm that each intended transition produces one event and that a held input produces no repeated launches.

Also test startup behavior. Initialize the saved switch state from the actual input before enabling edge detection; otherwise, program startup can look like a genuine switch transition. Decide separately whether a switch already active at startup must create an event.

Avoid recurring configuration mistakes

• Do not set PC_COMM_MCODE to 99. For the supplied interface, define it as 14 and pass 100 to select M100.
• Do not debug SQL first. Prove the input, event branch, M100 request, and PC launch in that order.
• Do not use level-triggered launching. A scan loop can issue repeated requests for as long as the switch remains active.
• Do not treat process launch as transaction completion. Record success or failure in the PC-side application if the dashboard update matters operationally.
• Do not hide startup semantics. Define whether an active switch at initialization represents an alarm event or only the current state.
• Do not duplicate command ownership. Keep controller logic responsible for detecting the event and PC logic responsible for executables, files, and database access.

FAQ