# Serial Module Write Timing

**URL:** <https://forum.inductiveautomation.com/t/serial-module-write-timing/110851>\
**Category:** Ignition\
**Tags:** ignition81, vision\
**Created:** [September 22, 2025, 8:29pm UTC](https://forum.inductiveautomation.com/t/serial-module-write-timing/110851 "2025-09-22T20:29:38Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![warren](https://avatars.discourse-cdn.com/v4/letter/w/97f17d/32.png) [@warren](https://forum.inductiveautomation.com/u/warren)\
**Post date:** [September 22, 2025, 8:29pm UTC](https://forum.inductiveautomation.com/t/serial-module-write-timing/110851/1 "2025-09-22T20:29:39Z")

</div>

Hello,

I have an HMI using the serial module to communicate with a third-party controller using serial commands to R/W and display these values on the HMI, send to database, etc.

This is a working communication line where I’m currently setup to only R/W as a one-shot, so basically to update parameters. However, there’s a handful of data that I want to constantly monitor, which means I need to have a continuously looping R/W script.

My first thought was to use my embedded 1Hz PLC clock bit, connect that to an OPC tag, and then run the script. So every 1s, send, read, etc. I don’t think the OPC server is fast enough to handle this because I don’t get an HMI tag response for that speed.

What would be another way to accomplish this? I don’t want this to slow down my HMI by running a script continuously on the client, or a window open.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [September 22, 2025, 8:34pm UTC](https://forum.inductiveautomation.com/t/serial-module-write-timing/110851/2 "2025-09-22T20:34:21Z")

</div>

> [@How to listen serial data without interruption](https://forum.inductiveautomation.com/t/how-to-listen-serial-data-without-interruption/15709/2):
>
> This is actually a rather challenging task, requiring a background thread constantly listening to the serial port. You might find inspiration in this example: [clientserial.py](https://www.automation-pros.com/ignition/clientserial.py).

(Read the back references that link to the topic, too.)