OwenSmsLib cfg_ok: Modem Setup Is the Fault, Not PLC Logic

On the PLC watch window or operator panel, cfg_oknever becomes ready, so the SMS sequence never starts. Treat this as a failed modem-initialization path.

Read the symptom before changing code

cfg_ok separates modem setup from message transmission. If it stays false, work on the serial command path first. SIM, network, and message-service problems become relevant after the library completes configuration.

The configured Universal Network Module - RS-232[SLOT] and the physical DB9 connection show where communication should occur. They do not prove that the modem and PLC use matching serial parameters. That is not the fault clearance.

Understand the failed initialization path

An SMS library normally initializes an AT-command modem before it accepts a send request. It transmits commands, waits for recognizable replies, and advances through its internal configuration sequence. A missing, corrupted, or unrecognized reply prevents the sequence from reaching cfg_ok.

RS-232 does not negotiate its operating format automatically. Both ends must agree on baud rate, data bits, parity, stop bits, and any flow-control method. The transmitter, receiver, and signal reference must also reach the correct pins. A DB9 connector alone does not establish those conditions.

The modem can retain a serial profile that differs from the PLC example. The PLC may then transmit correctly for its configured format while the MC52i interprets different bit timing or waits for flow-control signals that the cable does not provide. From the application, this looks like a library problem even though the failure occurs below the SMS logic.

Check the serial chain first

Start here. Isolate the modem from the PLC and prove that it accepts AT commands through a PC terminal.

1. Check the MC52i power source and indicators using the modem documentation. An underpowered or restarting modem cannot complete a repeatable command exchange.
2. Open a terminal on the selected PC port. Begin with the modem's documented or previously recorded serial profile rather than guessing values.
3. Send an AT command and look for a valid, repeatable modem response. Repeat the test after closing and reopening the port.
4. If there is no response, check port selection, transmit/receive crossover, signal reference, baud rate, framing, and flow control in that order.
5. If the response is unreadable, correct the serial format. Garbled characters indicate that electrical communication exists but the terminal and modem are not decoding the same format.

Do not start with SIM or network troubleshooting while the modem cannot answer locally. Registration cannot repair a broken RS-232 exchange.

Configure the modem and reconnect the PLC

The evidence does not provide the required baud rate, frame format, or flow-control selection, so read those values from the library example, PLC port configuration, and modem command reference.

1. Record the modem's current serial parameters before changing them. This gives you a recovery point if communication is lost after a setting change.
2. From the PC terminal, set the modem's baud rate, data format, and flow-control behavior to match the PLC configuration. Change one category at a time and test after each change.
3. Save the profile only through the persistence method defined for the MC52i. Then remove and restore modem power and repeat the terminal test using the saved settings.
4. Disconnect the PC and reconnect the modem to the PLC's RS-232 DB9 port using the verified wiring arrangement.
5. Open the PLC configuration and confirm that Universal Network Module - RS-232[SLOT] represents the physical port in use. Match every exposed serial setting to the modem profile.
6. Run the OwenSmsLib example without adding message sequencing or retry logic. Monitor cfg_ok and the library's available status outputs during initialization.

If PC communication works but cfg_ok remains false, capture the library status and compare the actual PLC transmit and receive activity. No PLC transmission points to port binding or program execution. Transmission without a modem reply points to wiring, flow control, or the modem profile. A reply that reaches the PLC but is rejected points to framing or response-format handling.

Verify each layer after the fix

1. Power-cycle the MC52i and confirm that the PC can still exchange AT commands using the selected profile. This verifies that the modem retained its settings.
2. Reconnect the PLC and confirm that its RS-232 configuration is unchanged and attached to the intended DB9 port.
3. Start the library and watch cfg_ok. It must reach the ready state before you request an SMS.
4. Only after cfg_ok is ready, issue one controlled send request and monitor the library's result indications.
5. If initialization passes but sending fails, check the SIM state, network registration, and required message-service settings with the modem's documented AT interface.

Keep the successful modem profile, PLC port settings, cable pinout, and test result in the machine record. Those four items make a replacement modem test deterministic.

Avoid the recurring traps

• Editing the SMS logic first: Application changes do not repair an AT-command channel that never initializes.
• Assuming the example configures the modem: A PLC library can send configuration commands only after the base serial link already works.
• Trusting the DB9 shell: Verify transmit, receive, reference, and any handshake conductors against both device manuals.
• Changing several parameters together: You lose the causal result. Change one layer, test it, and record it.
• Skipping the power-cycle test: A terminal session may work until the modem restarts and returns to a stored profile.
• Mixing readiness with delivery: A ready cfg_ok proves that initialization advanced; it does not by itself prove network registration or SMS delivery.

FAQ