timeout on transmit about iec104-python

[m-unkel]

Hey,
first of all the transmission should be fast enough to wait for the response, but technically it would be possible to add an argument for a non-blocking transmission.
How many commands do you want to send per second?
Maybe there is an undesired locking problem.
Does the problem occur only by sending the same point multiple times or also by sending different points at the same time?

Your code does not show how send_point(...) is called.
But your thread calls transmit in a loop without any sleep.. you are bombing your RTU with command messages, which is not an to be expected behavior unless you want to attack a system. Is that the case?

By the way.. the callbacks you define (cl_pt_on_receive_point, cl_on_new_station cl_on_new_point) reproduce exactly the default behavior in case the callback is not set, so you could remove them unless you want to add additional logic.

[jeremykalvar]

Hi,
Thanks for the reply!
No my goal is not to attack a system haha... Yet !
Ideally, I would like to be able to send 1 command every second.
Right now I am working on a single point, so yes, the problem seems to occur only by sending the same point multiple times.

I am using it in a fastApi router:

@router.post("/send-iec-point")
    async def send_iec_point(, ioa: int, filename: str):
        value = self.csv_handler.read_next_line_from_csv(filename, ioa)
        iec_master_client.send_point(ioa=ioa, value=float(value))
        return value

If the endpoint is called more than once every 3 seconds, my app breaks.
I may be missing something...

[divinity666]

I was also playing with this beautiful library and ended up at a similar point:

I am also receiving False as a response to transmit, though I implemented the on_receive callback and always return c104.ResponseState.SUCCESS.

The transmit call always runs into the command_timeout in this case - no idea why.

Sounds pretty much, like the same issue.

[divinity666]

Ok, I found the root cause for me:

I was calling transmit(cause=c104.Cot.SPONTANEOUS). If I change the call to transmit(cause=c104.Cot.ACTIVATION) it works as expected.

Nevermind.

[m-unkel]

I am also receiving False as a response to transmit, though I implemented the on_receive callback and always return c104.ResponseState.SUCCESS.

This is the default behavior, you do not have to implement the callback to always simply return c104.ResponseState.SUCCESS.

Ok, I found the root cause for me:

I was calling transmit(cause=c104.Cot.SPONTANEOUS). If I change the call to transmit(cause=c104.Cot.ACTIVATION) it works as expected.

Nevermind.

Yes SPONTANEOUS should be used in monitoring direction only and ACTIVATION is the right choice here AFAIK.

[m-unkel]

@jeremykalvar could you please generate some logging information? A command+confirmation should consume milliseconds not seconds..

c104.set_debug_mode(mode=c104.Debug.Client|c104.Debug.Connection)


def con_receive_raw(connection: c104.Connection, data: bytes) -> None:
    print("RECV] {1} [{0}] | CONN OA {2}".format(data.hex(), c104.explain_bytes_dict(apdu=data), connection.originator_address))


def con_send_raw(connection: c104.Connection, data: bytes) -> None:
    print("SEND] <--| {1} [{0}] | CONN OA {2}".format(data.hex(), c104.explain_bytes_dict(apdu=data), connection.originator_address))

class IECClient:
    def __init__(...):
        # [...] 
        # append the following to your __init__
        self.connection.on_receive_raw(callable=con_receive_raw)
        self.connection.on_send_raw(callable=con_send_raw)