Как определить состояние соединения с ПК по Modbus TCP

[krollcbas]

Зачем делать для обмена с HMI ПЛК-мастером? Должна быть на мой взгляд логика иной. HMI мастер и он отслеживает состояние подчиненных устройств.
ПЛК мастером должен быть для модулей IO.

Курица тащит за собой цыплят, а не наоборот.

Еще часто пускаю в обмене целочисленную переменную, которая постоянно инкрементируется и отслеживаю на другом конце изменение

[teo111]

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

[teo111]

Мы все умрём.

Не надо умирать )). Вопрос, выходит, таков. ПЛК будучи слейвом (сервером) в режиме Modbus TCP может определить наличие соединения штатными средствами? Или нужно отправлять ему периодически что то для проверки соединения (инкрементировать ему какой-нибудь регистр, или записывать туда единичку, а ПЛК будет обнулять) и другого решения НЕТ?

[teo111]

Ну слава богу. На 5й день разобрались ху из ху.
1.Штатных средств контроля связи в штатном конфигураторе - нет
2.Простейшие способы решения проблемы - вариации по мотивам пост#3 (см)

Не протокол - карта. Вам нужен контроль - добавляете регистр и описание назначения. С той стороны ребенок 2-х летний или там будут упираться рогом ?
3.Можете заюзать программный сервер. Тогда страшных заказчиков не придется беспокоить. Но - программный.
Всё.

Спасибо, к сожалению, не знаю как удалить предыдущий пост.

[imaex]

ПЛК будучи слейвом (сервером) в режиме Modbus TCP может определить наличие соединения штатными средствами?

Извините, что вмешиваюсь, но ПЛК-то зачем это знать? ПМСМ, это как раз мастеру (условно - SCADA) нужно знать статус соединения с источником данных.

[tracemodefan]

Извините, что вмешиваюсь, но ПЛК-то зачем это знать? ПМСМ, это как раз мастеру (условно - SCADA) нужно знать статус соединения с источником данных.

Бывает сидит оператор и смотрит за тех.процессом, а процесс вялотекущий, и изменения не всегда фиксируются взглядом оператора после 9 часов упорного смотра в монитор. В этот самый момент связь отваливается и контроллер ставит процесс на паузу, а в скаде маячит "ОШИБКА СВЯЗИ!!! АХТУНГ!!!". Контроль нужен с обеих сторон.

[kondor3000]

Бывает сидит оператор и смотрит за тех.процессом, а процесс вялотекущий, и изменения не всегда фиксируются взглядом оператора после 9 часов упорного смотра в монитор. В этот самый момент связь отваливается и контроллер ставит процесс на паузу, а в скаде маячит "ОШИБКА СВЯЗИ!!! АХТУНГ!!!". Контроль нужен с обеих сторон.

Допустим вы определите в ПЛК, что отвалилась связь, если он слейв, толку от этого никакого. Только со стороны мастера можно переподключить порт ( если не физический обрыв).
Поэтому надо делать так, чтобы связь не отваливалась. А если отвалилась, то переподключить порт на Скаде.

[melky]

kondor3000 может тут речь о том, чтобы ПЛК позакрывал сокеты, если связь пропала ? Мастер при очередной попытке откроет соединение вновь. А вот если у ПЛК зависнут открытые сокеты, к нему уже будет нельзя подключиться, пока не перезагрузят его.

[Валенок]

Причем тут сокеты ?
Алгоритм работы может менятся. Командир сказал вперед и помер, и что, так и идем ?

[melky]

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

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