Страница 1 из 5 123 ... ПоследняяПоследняя
Показано с 1 по 10 из 48

Тема: Релиз библиотеки OwenModbusSlave для CODESYS v2.3

Комбинированный просмотр

Предыдущее сообщение Предыдущее сообщение   Следующее сообщение Следующее сообщение
  1. #1

    По умолчанию Релиз библиотеки OwenModbusSlave для CODESYS v2.3

    Как Вы знаете, во всех контроллерах ОВЕН под управлением CODESYS 2.3 есть возможность настроить обмен по сети в качестве Modbus-Slave’a через конфигурацию ПЛК
    plccong.png
    и для большинства случаев этого достаточно.
    Но бывают следующие ситуации:
    1. Необходимо поддерживать программу на разных типах ПЛК (например, на ПЛК100 и ПЛК154);
    2. Необходимо организовать доступ к данным по 2м интерфейсам сразу (например, по RS232 подключена панель, которая может как записывать, так и считывать данные из ПЛК, а по RS485 ПЛК подключен к облаку, которое может только вычитывать данные);


    И все было бы хорошо – 1 раз сделал конфигурацию и забыл. Но, как вы знаете, клиенты имеют неприятную привычку изменять требования к ПО уже в процессе разработки. И приходится вручную поддерживать актуальность конфигурации в разных ПЛК, либо на разных интерфейсах одного ПЛК.

    Чтобы облегчить Вам жизнь в вышеперечисленных ситуациях мы разработали библиотеку OwenModbusSlave_v2.3.9.4.
    В библиотеке всего 1 пользовательский ФБ, которому для работы требуется минимум обвязки:
    1. № COM-порта
    2. Сетевые настройки
    3. Область, в которой хранятся данные, доступные по сети
    4. Размер области данных




    Работа библиотеки тестировалась на ПЛК100, ПЛК150, ПЛК154, ПЛК110, ПЛК110 [m02]

    Примечание: библиотека не поддерживается на контроллерах ПЛК63/73
    Скачать последнюю версию:

    Список изменений:

    Версия Дата Список изменений
    2.3.9.4 19.06.2018 Первая версия библиотеки




    Документация

    Руководство пользователя:
    Последний раз редактировалось Евгений Кислов; 11.12.2018 в 20:31.
    OSCAT.ru читать стандарты и статьи по автоматизации на русском без регистрации и СМС

  2. #2

    По умолчанию

    Библиотека OwenModbusSlave работает только на плк овен или на плк любого производителя поддерживающего кодесис 2.3 ?

  3. #3

    По умолчанию

    Цитата Сообщение от КИП Посмотреть сообщение
    Библиотека OwenModbusSlave работает только на плк овен или на плк любого производителя поддерживающего кодесис 2.3 ?
    На ПЛК других производителей мы не проверяли.
    OSCAT.ru читать стандарты и статьи по автоматизации на русском без регистрации и СМС

  4. #4
    Пользователь Аватар для Эдуард_Н
    Регистрация
    22.09.2014
    Адрес
    Курган
    Сообщений
    1,437

    По умолчанию

    Так и примерчик бы выложили.

  5. #5

    По умолчанию

    Цитата Сообщение от Эдуард_Н Посмотреть сообщение
    Так и примерчик бы выложили.
    Я не подумал, что может быть полезен пример программы из одного блока.
    В документации (рисунок 3.3) есть пример на CFC.

    Его не достаточно?
    OSCAT.ru читать стандарты и статьи по автоматизации на русском без регистрации и СМС

  6. #6
    Пользователь
    Регистрация
    29.06.2018
    Адрес
    Йошкар-Ола
    Сообщений
    14

    По умолчанию

    Как считаете, в описанной выше ситуации автоопределение протокола нужно?
    Или же предпочтительнее, чтобы программист в явном виде указывал, что хочет использовать ASCII?
    Я не сильный специалист в CoDeSys, сталкиваться с этим приходится раз в пару лет Думаю, надо подходить с точки зрения унификации: если в большинстве процедур, которые используют MODBUS по UART присутствует автоопределение, то да, нужно.

  7. #7

    По умолчанию

    Цитата Сообщение от livethreads Посмотреть сообщение
    Я не сильный специалист в CoDeSys, сталкиваться с этим приходится раз в пару лет Думаю, надо подходить с точки зрения унификации: если в большинстве процедур, которые используют MODBUS по UART присутствует автоопределение, то да, нужно.
    В большинстве решений с которыми мне приходилось работать - пользователь напрямую указывает версию протокола.
    OSCAT.ru читать стандарты и статьи по автоматизации на русском без регистрации и СМС

  8. #8
    Пользователь
    Регистрация
    29.06.2018
    Адрес
    Йошкар-Ола
    Сообщений
    14

    По умолчанию

    Здравствуйте.
    Несколько вопросов по работе предлагаемого ФБ:
    1. В каких ситуациях поднимаются/опускаются флаги xDone и xBusy?
    2. В каком месте цикла ПЛК происходит обработка полученного запроса?
    3. В каком месте цикла ПЛК формируется буфер ответа и начинается передача ответа мастеру?
    4. Можно ли рассчитывать на появление в обозримом будущем подобного ФБ для TCP Slave?
    Спасибо.

  9. #9
    Пользователь
    Регистрация
    29.06.2018
    Адрес
    Йошкар-Ола
    Сообщений
    14

    По умолчанию

    Здравствуйте.
    Извиняюсь за поспешность предыдущих вопросов, вопросы 2 и 3 снимаются. Более детально ознакомился с ваши ФБ и рискнул сделать свои предложения, которые позволят более гибко использовать данный ФБ.
    Предложения по модернизации:
    Бывают ситуации, когда до выполнения запроса от Master требуются дополнительные действия со стороны Slave. Самая типичная из них это когда необходимо сделать доступным для записи не весь буфер данных Slave, а лишь конкретный регион. Если пытаться подобные нюансы реализовывать внутри вашего ФБ, это сильно усложнит и логику работы блока, и понимание, как этим всем пользоваться. Извиняюсь за свои поспешные вопросы, связанные с процедурами обратного вызова, в среде CoDeSys это можно решить более естесственным способом.

    Slave может находиться в следующих длительных состояниях:
    - ожидание запроса;
    - получение запроса;
    - задержка перед отправкой ответа;
    - отправка ответа.

    Вероятнее всего, в вашем ФБ в том цикле ПЛК, когда вы получаете признак того, что чтение запроса завершено, сперва производится предварительная обработка (свой ли адрес устройства, проверка CRC), и если запрос по адресу, то включается таймер задержки ответа, выполняется запрос, формируется ответ. Предлагаю сделать следующее.

    1. Сделать видимой снаружи структуру типа <OMB_SlaveRecievedFrameDescription> (сделать её выходной переменной).
    2. Добавить выходную переменную, например, <xReqReady : BOOL>.
    3. Добавить входную переменную, например, <eCustomErr : OMB_Slave_SLAVE_BLOCK_ERROR>, которая по-умолчанию имеет значение <NO_FRAME_ERROR>.
    4. После того, как сформирована структура (1), выставить флаг (2) и уйти в следующий цикл ПЛК.
    5. В следующем цикле ПЛК сбросить флаг (2), проверить значение (3) и в зависимости от него выполнять/не выполнять запрос, формировать ответ.

    Такой механизм позволит пользовательской программе, по признаку (2) проверить, возможно ли выполнение поступившего запроса в её частном случае, а также выполнить необходимые действия в буфере Slave непосредственно перед формированием ответа. При этом, если в данных действиях нет необходимости, то вышеуказанные переменные просто не будут им использованы при обращении к ФБ. Никаких изменений в уже написанных программах не потребуется.

  10. #10

    По умолчанию

    Добрый день!
    Спасибо за хорошие вопросы и предложения по модернизации.

    Цитата Сообщение от livethreads Посмотреть сообщение
    1. В каких ситуациях поднимаются/опускаются флаги xDone и xBusy?
    Действительно не раскрыл этого в описании библиотеки:
    xBusy = TRUE до тех пор, пока xEnable = TRUE;
    xDone = not xBusy.

    Цитата Сообщение от livethreads Посмотреть сообщение
    4. Можно ли рассчитывать на появление в обозримом будущем подобного ФБ для TCP Slave?
    На текущий момент в планах такого нет.
    Уточните пожалуйста, почему использование Modbus-TCP через конфигурацию не подходит?
    Нужно дублировать данные для нескольких мастер-устройств?

    Цитата Сообщение от livethreads Посмотреть сообщение
    Вероятнее всего, в вашем ФБ в том цикле ПЛК, когда вы получаете признак того, что чтение запроса завершено, сперва производится предварительная обработка (свой ли адрес устройства, проверка CRC), и если запрос по адресу, то включается таймер задержки ответа, выполняется запрос, формируется ответ. Предлагаю сделать следующее.

    1. Сделать видимой снаружи структуру типа <OMB_SlaveRecievedFrameDescription> (сделать её выходной переменной).
    2. Добавить выходную переменную, например, <xReqReady : BOOL>.
    3. Добавить входную переменную, например, <eCustomErr : OMB_Slave_SLAVE_BLOCK_ERROR>, которая по-умолчанию имеет значение <NO_FRAME_ERROR>.
    4. После того, как сформирована структура (1), выставить флаг (2) и уйти в следующий цикл ПЛК.
    5. В следующем цикле ПЛК сбросить флаг (2), проверить значение (3) и в зависимости от него выполнять/не выполнять запрос, формировать ответ.

    Такой механизм позволит пользовательской программе, по признаку (2) проверить, возможно ли выполнение поступившего запроса в её частном случае, а также выполнить необходимые действия в буфере Slave непосредственно перед формированием ответа. При этом, если в данных действиях нет необходимости, то вышеуказанные переменные просто не будут им использованы при обращении к ФБ. Никаких изменений в уже написанных программах не потребуется.
    Если я правильно понял идею, то цель следующая: сделать некое подобие "событий" (ниже буду называть так), обработку которого пользователь сможет запретить.
    Идея мне нравится. Но есть несколько уточняющих вопросов:
    Цитата Сообщение от livethreads Посмотреть сообщение
    2. Добавить выходную переменную, например, <xReqReady : BOOL>.
    Я правильно понимаю, что эту переменную мы должны взводить только в случае, если получен корректный запрос (корректный CRC, адрес совпадает и т.д.)?
    А в остальных случаях ФБ сам отвечает мастеру об ошибке (или не сообщает, если адрес не тот) не уведомляя об этом пользователя.

    Цитата Сообщение от livethreads Посмотреть сообщение
    1. Сделать видимой снаружи структуру типа <OMB_SlaveRecievedFrameDescription> (сделать её выходной переменной).
    Если я прав с вопросом о <xReqReady : BOOL>, то эта структура содержит "лишние" данные (адрес устройства мы и так знаем, CRC проверен и корректен, количество байт в запросе для обработки события пользователем не нужно).
    Итого получим структуру
    Код:
    usiFunctionNumber			: USINT;			(* Номер функции *)
    udiFirstAddress				: UDINT;			(* Номер первого регистра или бита (в зависимости от функции) *)
    uiDataCount				: UINT;				(* Количество регистров или бит (в зависимости от функции) *)
    Upd: хотя адрес в этой структуре может быть нужен, например, в случае, если мы хотим написать универсальную функцию реакции на запрос для всех SLAVE'ов проекта.

    На сколько я понимаю при обработке события записи нам бы хотелось иметь возможность проверить данные, которые пытаются нам записать (например если диапазон корректных значений ограничен 0-3, а пытаются записать значение 4), поэтому в ту же структуру добавим
    Код:
    awWrittenData				: ARRAY [1..125] OF WORD;	(* Записываемые данные, если запрос на чтение - заполнено нулями *)
    Но, на сколько мне известно, стандартной ошибки Modbus для такого случая нет (ILLEGAL_DATA_VALUE возвращается в случае, если № первого регистра в диапазоне допустимых значений, а № последнего - выходит за него).
    Как Вы считаете, как себя должен повести Slave в таком случае?
    Пока что в голову приходит 2 варианта:
    1. Вернуть ответ "запрос обработан", но не записывать данные в буфер SLAVE'а (в таком случае пользователь может быть обескуражен тем, что запросы проходят, но данные не меняются);
    2. Вернуть код ошибки (например, тот же ILLEGAL_DATA_VALUE), а в документации на библиотеку указать в каком случае может возникнуть эта ошибка (в таком случае пользователь опять же может быть удивлен тем, что запрашивает явно корректные регистры, но ошибка указывает, что нет).


    Я запланировал эту доработку на следующую версию библиотеки.
    Но, думаю, это будет отдельный ФБ:
    • MB_RTU_SLAVE останется для тех, кому нужно "попроще",
    • новый ФБ - для тех, кому нужна гибкость.
    Последний раз редактировалось Осинский Алексей; 08.07.2018 в 12:21.
    OSCAT.ru читать стандарты и статьи по автоматизации на русском без регистрации и СМС

Страница 1 из 5 123 ... ПоследняяПоследняя

Похожие темы

  1. библиотеки Codesys
    от Радик в разделе ПЛК1хх
    Ответов: 13
    Последнее сообщение: 24.08.2018, 18:16
  2. Релиз библиотеки OwenDebug
    от Осинский Алексей в разделе СПК2хх
    Ответов: 0
    Последнее сообщение: 07.08.2017, 14:05
  3. Ответов: 0
    Последнее сообщение: 23.01.2017, 15:32
  4. Библиотеки CoDeSys
    от Romjke76 в разделе Трёп (Курилка)
    Ответов: 11
    Последнее сообщение: 30.09.2016, 08:43

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •