After the fix, the parent project can route alarms from the integrated subproject through its existing SMS MessageControl without requiring changes inside that subproject. The working pattern is to expose the subproject alarm variables to the parent, map them to internal variables there, and use those parent-side variables to trigger message sending. This keeps the SMS sending function and modem ownership in the project where MessageControl already works.
What does the access problem look like?
The parent project contains a third-party subproject, but the parent cannot directly access the subproject alarm variables needed to associate them with its SMS send function. The subproject also does not have access to the parent project’s existing send function. The integration boundary, rather than SMS delivery itself, is the first problem to solve.
Separate the three parts of the signal path before changing configuration:
- Alarm source: a limit violation in the subproject produces or changes an alarm variable.
- Project boundary: the parent must receive that alarm information through a mapping or import.
- Message dispatch: the parent-side MessageControl sends the SMS when its configured trigger is activated.
If an alarm already reaches the parent as a usable variable, focus on the mapping and trigger. If it does not, first establish how the integrated project exposes alarm variables. Do not begin by duplicating modem configuration in the subproject: the reported integration pattern routes the alarm toward the already functioning parent sender instead.
| Signal | Source | Wrong-value symptom |
|---|---|---|
| Alarm state or alarm variable | Subproject | The parent-side trigger never changes, so no SMS is initiated for that alarm. |
| Mapped internal variable | Parent project, assigned from the subproject alarm variable | The trigger stays inactive, follows the wrong alarm, or does not reflect the alarm transition. |
| Message-send trigger | Parent-side MessageControl configuration | The trigger may activate without producing the expected SMS; check the parent sender configuration and test the complete route. |
Where does the message function act on the alarm?
In the described arrangement, MessageControl is configured per project. A limit violation starts the “send message” function associated with the alarm. That makes project ownership important: a function configured in the parent does not automatically gain access to alarm details that remain private to the subproject, and a subproject variable cannot simply be assumed to invoke the parent’s function.
The practical design is to move the trigger information across the project boundary, not to assume the function crosses it. Parent-side internal variables provide an intermediate point: they receive assignments corresponding to the subproject alarm variables, then can activate the parent project’s send-message function. Treat this as a signal bridge. Confirm which alarm identity and state are available at that bridge, because a trigger alone may not supply the message content or context the operator expects.
There is also a resource-ownership constraint. The reported configuration notes that multiple projects cannot simultaneously access one serial or USB modem. Keep a single project responsible for the modem in this architecture—the parent project that already has MessageControl working—and avoid configuring a second concurrent sender against the same modem. Recheck this constraint against the software and modem arrangement actually deployed, especially when updating an older installation.
Which bridge should carry the subproject alarm?
The documented no-change approach leaves the subproject untouched and creates internal variables in the parent project. Assign the corresponding subproject alarm variables to those parent variables. If needed, export the alarm variables as XML from the subproject and import them into the parent project’s internal driver. In the parent, use the resulting internal variables to trigger the existing send-message function.
This is a useful choice when the subproject belongs to another supplier or cannot be modified. It also keeps message configuration and the serial or USB modem in one project. A direct association from a subproject variable to a function in the parent was raised as an alternative, but its support and its ability to obtain alarm information from the subproject were uncertain. Do not make that direct link the primary design unless the product’s current documentation or a controlled test confirms that cross-project invocation and alarm-context transfer are supported.
How do you build the parent-side relay?
- Record the existing working route. Identify a parent-project alarm that already sends an SMS. Note its alarm variable, the trigger condition used by MessageControl, the intended recipient, and what alarm information the message carries. Preserve this as a baseline rather than changing the existing sender while integrating the subproject.
- Identify the source variables. In the subproject, determine which alarm variables represent the relevant alarm conditions. Confirm that the parent can receive or import those variables through the project integration. If direct access is unavailable, use the XML export/import path described above, with the parent’s internal driver as the destination.
- Create corresponding parent variables. Add internal variables in the parent for the alarm information that must drive notification. Map or assign each one to its corresponding subproject alarm variable. Keep the relationship explicit so a technician can trace a parent trigger back to its alarm source.
- Connect the relay to the sender. Configure the parent-side internal variables to activate the send-message function in the parent project. Follow the same working configuration pattern used by the parent’s existing SMS alarms; do not invent a new modem path or rely on a subproject-local function to reach the parent sender.
- Check alarm information, not just the trigger. Compare the imported or mapped variable set with the message requirements. If a message must identify the source alarm, verify that the relevant identification or state is available to the parent-side function. Add only mappings supported by the project’s variable model and sender configuration.
- Test one alarm path at a time. Use a controlled alarm condition and observe the source variable, parent internal variable, send trigger, and SMS result in sequence. Then test the other mapped alarms individually. This isolates a bad mapping from an SMS transport or recipient configuration issue.
Keep an unambiguous mapping record: source alarm variable, corresponding parent internal variable, and the parent message trigger it drives. This makes later changes to the subproject easier to assess. If the subproject’s exported variables change, revisit the mapping rather than assuming the old import still represents the current alarm set.
How can you verify the alarm-to-SMS path?
Verification must follow the signal chain, not stop at the first variable that changes. Trend or monitor the subproject alarm variable and its parent-side assignment during a controlled alarm. Confirm that the parent variable follows the intended source and that the send trigger activates under the intended alarm condition. Finally, confirm receipt of an SMS and check that its content identifies the intended alarm well enough for the service recipient to respond.
Use the following pass/fail sequence:
- Source pass: the intended subproject alarm variable changes when the test condition is applied.
- Mapping pass: the corresponding parent internal variable reflects that same alarm state.
- Dispatch pass: the parent send function activates for that mapped alarm, not for an unrelated variable.
- Delivery pass: the expected SMS arrives through the parent’s existing sender and is identifiable to the recipient.
If the source changes but the parent variable does not, investigate import, assignment, or integration visibility. If the parent variable changes but the send function does not activate, inspect the parent-side trigger association. If the trigger activates but the SMS does not arrive, troubleshoot the parent MessageControl and modem path using a known-working parent alarm as the comparison. This isolates project-boundary faults from message-transport faults.
What failure modes recur with this arrangement?
| Observed condition | Likely point to inspect | Next check |
|---|---|---|
| No parent variable change | Subproject variable exposure, XML import, or assignment | Compare the source alarm state with the mapped parent internal variable. |
| Parent variable changes, but no send trigger | Parent-side association between the internal variable and send function | Compare the trigger configuration with a known-working parent SMS alarm. |
| Trigger activates, but no expected SMS | Parent MessageControl or modem route | Test the parent sender with its existing alarm path and confirm which project owns modem access. |
| SMS arrives with inadequate alarm context | Variables or alarm information available to the parent sender | Check whether the required alarm identity and state were exposed and mapped, not merely the trigger bit. |
A common design mistake is configuring a second project to use the same serial or USB modem. The described setup explicitly rules out simultaneous access by multiple projects; a parent-side relay avoids that contention by keeping the sender in the project where it already works. Another mistake is treating a successful variable import as proof of successful notification. Import, state mapping, trigger activation, and SMS receipt are separate checks.
Alarm signals may also have state transitions beyond the initial activation. During commissioning, observe the actual behavior on activation and return to normal so the relay does not generate unintended repeat messages or miss a required notification. The evidence describes activation of the send function from an alarm limit violation, but does not define reset, acknowledgement, edge, or repeat behavior; read those rules in the installed project’s alarm and MessageControl configuration and test them explicitly.
Frequently asked questions
Why do subproject alarms not send SMS through the parent project?
The parent cannot directly use alarm variables that remain inside the subproject, and MessageControl is configured per project. Expose or import the alarm variables into parent-side internal variables, then use those variables to trigger the parent sender.
Why should the parent project own the modem?
The parent already has working MessageControl, and the described arrangement does not allow simultaneous access by multiple projects to one serial or USB modem. Keep the sender and modem path in one project rather than starting a competing subproject sender.
When should I stop testing and escalate?
Stop changing the relay if the source variable, parent mapping, trigger, and sender path do not identify a clear fault, or if the installed software does not confirm cross-project variable import or modem ownership behavior. Escalate with the project versions, variable mapping, MessageControl configuration, modem connection details, and the observed signal sequence to the product manufacturer’s official support channel.