PDA

Просмотр полной версии : Использование SysLibCallback с Modbus Slave TCP



livethreads
29.06.2018, 09:25
Здравствуйте.
Собственно, набрёл на данную тему в поисках информации, как правильно привязать callback функцию к событию обращения к интерфейсу со стороны Master (с помощью SysLibCallback.lib). IMHO было бы здорово, если бы и данная библиотека сразу имела в своём комплекте оболочку вызова для SysCallbackRegister и SysCallbackUnregister для конкретного события обращения к интерфейсу.
Буду признателен, если подскажете, на какое событие подписаться для обработки события обращения к TCP Slave. EVENT_BEFORE_WRITING_OUTPUTS ?

Осинский Алексей
02.07.2018, 10:51
Здравствуйте.
Собственно, набрёл на данную тему в поисках информации, как правильно привязать callback функцию к событию обращения к интерфейсу со стороны Master (с помощью SysLibCallback.lib). IMHO было бы здорово, если бы и данная библиотека сразу имела в своём комплекте оболочку вызова для SysCallbackRegister и SysCallbackUnregister для конкретного события обращения к интерфейсу.
Буду признателен, если подскажете, на какое событие подписаться для обработки события обращения к TCP Slave. EVENT_BEFORE_WRITING_OUTPUTS ?

SysLibCallback предназначена для уведомлений о системных событиях.
События протокола все же не системные события, поэтому при помощи этой библиотеки не отловить обращений от мастера к Slave'у.
Судя по названию EVENT_BEFORE_WRITING_OUTPUTS срабатывает после завершения цикла ПЛК, но перед установкой значения выходов и будет вызываться в каждом цикле.

А какую задачу Вы пытаетесь решить, отлавливая обращения от мастера к Slave'у?
Может сможем предложить решение.

livethreads
03.07.2018, 12:06
А какую задачу Вы пытаетесь решить, отлавливая обращения от мастера к Slave'у?
Может сможем предложить решение.
Slave режим по сути является сервером, "слушающим" интерфейс и выполняющим запросы клиента(ов). У меня вполне нормальное (по моим представлениям) желание - иметь контроль над данным процессом: знать кто, когда и зачем обращался к интерфейсу. Кроме того, это наиболее естественный способ быстрой реакции на запросы, связанные с записью в регистры. В идеале это регистрация callback процедуры на событие завершения чтения запроса и передача этой процедуре в параметрах указатель на буфер, содержащий прочитанный запрос. Со своей стороны, обязуюсь долго в данной callback процедуре не висеть. Просто фиксирую событие, а для его обработки использую механизмы отложенных прерываний.

livethreads
03.07.2018, 12:08
Какие проблемы ?
Для начала - понять, что сказать хотели.

livethreads
04.07.2018, 19:53
На землю спуститесь. Нету здесь никаких адекватных калбэков.
Это я уже понял. В принципе, ваше сообщение идеально подходит для закрытия данной темы.

livethreads
05.07.2018, 10:06
.. но вполне можно событийно программировать (а с обменом - это самый правильный пусть). Флажки решат все проблемы. Тока авторам либ нужно заранее позаботится о флажках. Какие проблемы ? )))

Можно, но IMHO это не вписывается в канонические концепции ПЛК. Зачем извращаться, для решения подобных задач существует другое железо. И этта.. для стабильной работы одних только флажков маловато будет :)
Что же касается именно ПЛК (в моём случае - Овен ПЛК100), то проблемы в том, что авторы либ не позаботились :( А иметь нужный флажок на входе в цикл PLC_PRG - это правильно! Только это уже не совсем событийное программирование.

livethreads
05.07.2018, 12:37
С чего бы это ?
Вынужден отослать вас к трудам Петрова И. В. (ISBN 5-98003-079-4)

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

Например авторы modbus.lib позаботились. См. Complete
Пользуюсь данной библиотекой для организации Master на RS485. В целом доволен. Не подскажете примерчик, как с помощью этой библиотеки организовать Slave на TCP ? Ну или шире поставим вопрос: у меня есть огромное желание иметь возможность получать информацию о том, в каком состоянии находится slave в начале каждого цикла PLC_PRG. И заметьте, желание вполне законное даже с точки зрения канонов ПЛК. По логике, slave интерфейс - это вход. Разница лишь в том, что на нём не 0/1 как на дискретном входе, не величина как на аналоговом, а поступившая от Master последовательность байт. И вот как раз об этом разработчики не позаботились. Какие проблемы ? (с) Всего-то флажок о том, что пришёл запрос и указатель на его содержимое.

murdemon
05.07.2018, 12:41
Все делают hertbit на слейве... Мастер меняет 1 регистр 0-1-0-1 и тд. А слейв смотрит если регистр не менялся допустим 1 сек. А частота опроса у мастера 100мс. То слейв считает , что связи с мастером нет и данные не валидные от мастера. Вот и все.

livethreads
05.07.2018, 13:09
Все делают hertbit на слейве... Мастер меняет 1 регистр 0-1-0-1 и тд. А слейв смотрит если регистр не менялся допустим 1 сек. А частота опроса у мастера 100мс. То слейв считает , что связи с мастером нет и данные не валидные от мастера. Вот и все.

У меня была похожая мысль, если со стороны мастера формируется запрос на запись. А как быть с запросом на чтение? Запрос-сигнал "Ща будет запрос на чтение", после чего собственно, сам запрос на чтение? Костыли, однако :(

livethreads
05.07.2018, 16:01
Так у автора того слейва целая тема. Там что не говорите ?
Форум очень большой, а я здесь новичок. Если вас не затруднит, ссылочку на тему дайте.
По поводу остального: мы переходим в режим флуда, который не имеет ни конца, ни отношения к изначальной теме. Если вы полагаете, что я в чём-то заблуждаюсь, то пусть будет по-вашему. Sorry.

livethreads
05.07.2018, 18:44
Так ходили ж там.
http://www.owen.ru/forum/showthread.php?t=28996

Спасибо :)