ПЛК 154 разрывает TCP-соединение

[bidoc]

ПЛК 154
Прошивка 2.17.0
Наше ПО использует протокол Modbus-TCP, соответственно устанавливается TCP-соединение с портом 502.
Проблема в том, что если в течение 7-и секунд не было отправки пакетов, ПЛК разрывает соединение (присылает пакеты с флагами FIN и RST).

[bidoc]

Ну, если описана проблема, то, очевидно, вопрос: "Как решить проблему?". То есть как сделать так, чтобы ПЛК не разрывал соединение.
И не совсем понял, что значит "всё верно"? Это не ошибка? Так себя ПЛК и должен вести?

[bidoc]

Так а сам ПЛК можно заставить не разрывать соединение?
Зачем он это делает? Это ошибка или так задумано?

[bidoc]

Не очень понял указанные причины разрыва соединения (так как плохо разбираюсь в ПЛК). Но в любом случае этот разрыв можно было бы сделать настраиваемым. Например, у нас простейшая задача, и наверняка перечисленные причины нас бы не коснулись. Правильно я понимаю, что разрыв зашит намертво и отключить его нельзя?

PS А откуда указанная цитата?

[bidoc]

Как тогда мне быть?
Я вижу два варианта.

1. KeepAlive. То есть я должен постоянно посылать какой-нибудь запрос на ПЛК. Например, читать какой-нибудь регистр. Причём когда запускается осмысленный запрос, этот keepalive нужно прерывать, так как ПЛК параллельные запросы не выдерживает и рушит соединение.

2. В начале каждого обращения к ПЛК устанавливать соединение, а в конце - разрывать. Но тут ПЛК опять капризничает: между разрывом соединения и последующим его установлением должно пройти несколько секунд, иначе ПЛК откажется его устанавливать. Для наших задач это ожидание неудобно.

То есть первый вариант? Другого выхода нет?

[bidoc]

Почему первый вариант мутный? Вы же тоже его предложили.
Про второй тоже претензию не понял. Что значит "семь секунд на переустановку соединения"? Через семь секунд ПЛК сам разорвёт соединение. А я говорю про инициативу с наше стороны. То есть когда мы хотим совершить какой-то обмен, мы устанавливаем соединение, а в конце сами его разрываем. Только вот потом быстро заново его установить ПЛК не даст.

[bidoc]

Что именно мутного в исполнении?
Что в этом же соединении? Чтение регистра для поддержки соединения конечно происходит в этом же соединении, которые мы поддерживаем этим чтением.

[bidoc]

Если я не прерву чтение регистра для поддержки соединения и параллельно ему начну ещё читать регистр, то ПЛК соединение разорвёт. И как быть?

[bidoc]

Я не понимаю, почему решили (да ещё и уверены), что я использую несколько TCP-соединений? Для доступа к Modbus все потоки используют один объект и соответственно одно TCP-соединение. Да и как вы это представляете? Для поддержки одного соединения я создаю другое?

Также не понял, причём здесь конфликт при доступе нескольких потоков к одному ресурсу, если речь идёт о том, что при быстром чтении регистров из параллельных потоков соединение может разорвать именно сам ПЛК.

Про внутренне устройство ПЛК я ничего не знаю, поэтому ничего настраивать и программировать там не могу. Производители могли бы предусмотреть работу Modbus по UDP.

Ну и еще раз про реконнект, вначале было через семь секунд рвется соединение если нет запроса, далее если разорвать соединение, то было высказано утверждение что соединиться только через несколько секунд, так если не нужны запросы быстрее чем произойдет принудительный разрыв соединения, разве не хватает времени чтоб пересоединиться, где тут проблема?

Запросы происходят в случайные моменты времени.

Как написать два параллельных потока, чтобы они не слали одновременно, я разобрался. Вопросы больше про поведение ПЛК.

PS Странная у вас манера общения.

[bidoc]

Насколько быстром ? Ваш ПЛК вытягивает не больше 200..250 запросов/сек.

Сейчас проверил - быстрые запросы обрабатывает нормально.

слали не раньше получения ответа на предыдущий и будет нескончаемое счастье.

Именно так и происходит.


А куда делись сообщения второго участника?