Is there an option to report if connection is lost and make the comport object try to reconnect?

for example if I have an arduino that is connected to pi and sending data via serial. if I disconnect it and connect it again it won't send any data unless I am openning the port again.
Is there any way I could do that automatically?

@KMETE said:

for example if I have an arduino that is connected to pi and sending data via serial. if I disconnect it and connect it again it won't send any data unless I am openning the port again.
Is there any way I could do that automatically?

So... think about what distinguishes a normal, functioning state from the abnormal state.

Usually Arduino sketches are sending data regularly several times per second. This means, the time between incoming packets should be a few hundred ms at most.

When it stops sending, the time since the last packet will be much larger.

Is there a way to measure time since the last bang in an inlet? Yes, see [timer].

So you could use a trigger object to generate a bang from the comport outlet and send it to the reset inlet of a [timer]. Then you could use a metro to bang the measuring inlet of the same timer. If the timer outlet is larger than one or two thousand ms, then you can assume that the connection got broken and send a message back up, to reconnect.

Haven't tested but it should be pretty close.

hjh

I did the follow:

example reset comport.pd

so if there is no data at the comport outplet it will bang the open $1 message every 1 sec.

Does it make sense? is there any problem with sending open message to the comport every x interval? can it stuck it? or make more harm then good?

When I rethink about it - why that a connection will be lost? only if the usb cable is dissconnected. In thay case it won't help to reopen the port.. isn't it?

@KMETE said:

Does it make sense? is there any problem with sending open message to the comport every x interval? can it stuck it? or make more harm then good?

I think you would have to try it and see.

For anyone else on the forum to test it, we would need your hardware device. We don't have that, so the final testing really is up to you.

If the device is disconnected, then a failed attempt to connect to it could not damage the device (because it's not connected).

If comport is well-programmed, then a failed connection attempt would just print an error while the object remains in stable condition.

why that a connection will be lost? only if the usb cable is dissconnected. In thay case it won't help to reopen the port.. isn't it?

Hm, your initial question is about automatically reconnecting when the device becomes available. There would be only two ways to do that: 1/ get a signal from the OS when the device is plugged in and use this to trigger the connect message (I don't know how to do this, it may not be practical) or 2/ keep trying until it succeeds.

hjh

@KMETE The rpi can also communicate with Pd using pdsend..... probably pdsend.linux in the Pd distribution. You could call pdsend in your Python code (probably copy it into a folder where python can find it).... and send a trigger message..... usb_connect 1 to a [netreceive] object in your patch.
When the message arrives in Pd use that to trigger the "open" connection of [comport].
Example code....

In the case of the above code you would use [netreceive 3000] in Pd.
David.

Thanks. I might don't use that at all but It was a good learn.

I wandering something else now.
I have build an abstraction for that comport reconnecting. Here is the inside of it:

and this is from outside

I don't think the argument 4000 and 1000 are passed to $0 and $1 inside the abstraction. I'm missing something?

@KMETE $0 and $1 values (in objects) are translated from the abstraction arguments as the patch is created...... ($0 automatically, $1 $2 etc. set in the abstraction name) and do not change afterwards.
So $1 will become 4000 and $2 1000 within [og.reset_comport 4000 1000] and $0 will be an automatic value above 1000, that can change depending on whether any other patches are open when this one is opened.
So $0 is best avoided for use from outside the abstraction. It is intended to be used as a local variable..... not global..... see below.
$ values in messages are translated as the message receives incoming data.
David.

could it be that the loadbang message inside my abstraction is overdrive my arrguments freom outside the abstraction (4000, 1000) ?

@KMETE Maybe. [metro $1] will normally become [metro 4000] and the 1000 value will be ignored as you have not put $2 in any object.
[> $0] will become [> 1001] if this were the only, or the first patch opened.
You can bang a [$0] object and print its value to discover it.
What you probably wanted was [> $1] and [metro $2]

The [loadbang] could replace those values in your patch....... that might depend on the order in which you created the object...... but I am unsure about that.
There is some documentation about what happens in what order as Pd is opened...... and maybe also as the patch is created here...... https://puredata.info/docs/developer/PdStartupOrder
I have no time to reread it right now but you might find the information there.

Arguments or [loadbang]....... not both...... will be the safe option.
David.