Страница 2 из 4 ПерваяПервая 1234 ПоследняяПоследняя
Показано с 11 по 20 из 32

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

  1. #11
    Пользователь Аватар для capzap
    Регистрация
    25.02.2011
    Адрес
    Киров
    Сообщений
    10,254

    По умолчанию

    хм, значит я в тот момент не понял Валенка, а так то все изменения в ФБ будут заключаться в добавлении разности на смещение
    Bad programmers worry about the code. Good programmers worry about data structures and their relationships

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

    По умолчанию

    Цитата Сообщение от Осинский Алексей Посмотреть сообщение
    Добрый день.
    Не понятно, только, кому это облегчит жизнь?
    За последние года 3 я с Modbus-ASCII ни сталкивался ни как программист, ни как сотрудник техподдержки.
    Не могу утверждать со 100% гарантией, но, вероятно, в то время, когда разрабатывались эти устройства Modbus-ASCII использовался чаще.
    RTU режим корректно работает только если RS485 представляет собой физическую пару от отправителя до получателя. Если же RS485 "пробрасывается" через преобразователи интерфейсов (например, через оптическую линию), где есть буферизация, то получатель не сможет корректно определить конец фрейма (по паузе, как заведено в RTU). В этом случае - только ASCII.

  3. #13

    По умолчанию

    Цитата Сообщение от livethreads Посмотреть сообщение
    Спасибо за полезную библиотеку. Хотелось бы иметь такую для режима Modbus Slave TCP.
    Спасибо за отзыв. Ваш вопрос по SysLibCallback выделил в отдельную тему.

    Цитата Сообщение от livethreads Посмотреть сообщение
    RTU режим корректно работает только если RS485 представляет собой физическую пару от отправителя до получателя. Если же RS485 "пробрасывается" через преобразователи интерфейсов (например, через оптическую линию), где есть буферизация, то получатель не сможет корректно определить конец фрейма (по паузе, как заведено в RTU). В этом случае - только ASCII.
    Согласен.
    Как считаете, в описанной выше ситуации автоопределение протокола нужно?
    Или же предпочтительнее, чтобы программист в явном виде указывал, что хочет использовать ASCII?
    OSCAT.ru читать стандарты и статьи по автоматизации на русском без регистрации и СМС

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

    По умолчанию

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

  5. #15

    По умолчанию

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

  6. #16

    По умолчанию

    Цитата Сообщение от Валенок Посмотреть сообщение
    По либе.
    За деревьями лес просто теряется. Зачем такие тяжелые имена, столько промежуточных структур и т.п. ? Понимаю что совсем без них - тяжело, но в таком количестве 8(. Похоже на что-то учебно/отладочное.
    Постоянно таскаются данные туда-cюда. Автор фанат функций ? Он хоть отличает массив-переменную от массива-параметра ? Это сильно утяжеляет исполнение. В большинстве случаев и program подошел бы.
    Умиляет буквальное следование фразе "очистить буффер" )) Ну накой ?
    и т.п.
    Спасибо за отзыв. Обязательно учту в своих будущих проектах.
    OSCAT.ru читать стандарты и статьи по автоматизации на русском без регистрации и СМС

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

    По умолчанию

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

  8. #18
    Пользователь
    Регистрация
    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 непосредственно перед формированием ответа. При этом, если в данных действиях нет необходимости, то вышеуказанные переменные просто не будут им использованы при обращении к ФБ. Никаких изменений в уже написанных программах не потребуется.

  9. #19

    По умолчанию

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

    Цитата Сообщение от 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 читать стандарты и статьи по автоматизации на русском без регистрации и СМС

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

    По умолчанию

    Здравствуйте.
    Цитата Сообщение от Осинский Алексей Посмотреть сообщение
    На текущий момент в планах такого нет.
    Уточните пожалуйста, почему использование Modbus-TCP через конфигурацию не подходит?
    Нужно дублировать данные для нескольких мастер-устройств?
    С дублированием данных для разных Master в Modbus-TCP как раз проблем нет: Достаточно добавить в Modbus[FIX] ещё один подмодуль TCP и указать в параметрах другой порт. Я пару лет назад так делал, у меня работало. Проблемы в другом:
    1. Необходимо запретить выполнение команд записи в определённые адреса (регионы адресов).
    2. Необходима проверка (кастомная) записываемых величин на корректность. Например, целое по адресу 444 может быть исключительно в диапазоне, определяемом значениями в адресах 222 и 223.
    3. Бывают ситуации, когда данные, выставляемые в Slave могут быть результатом достаточно тяжёлых вычислений (например, сумма медленносходящегося ряда). В таких случаях готовить их каждый цикл не слишком здорово, хотелось бы выполнять подобные операции только тогда, когда на них есть запрос от Master.
    Цитата Сообщение от Осинский Алексей Посмотреть сообщение
    Если я правильно понял идею, то цель следующая: сделать некое подобие "событий" (ниже буду называть так), обработку которого пользователь сможет запретить.
    Идея мне нравится. Но есть несколько уточняющих вопросов:
    В принципе, можно это назвать обработкой события. Смысл в том, чтобы дать возможность пользовательской программе сделать дополнительные действия непосредственно перед выполнением запроса вашим ФБ.
    Цитата Сообщение от Осинский Алексей Посмотреть сообщение
    Я правильно понимаю, что эту переменную мы должны взводить только в случае, если получен корректный запрос (корректный CRC, адрес совпадает и т.д.)?
    А в остальных случаях ФБ сам отвечает мастеру об ошибке (или не сообщает, если адрес не тот) не уведомляя об этом пользователя.
    Да.
    Цитата Сообщение от Осинский Алексей Посмотреть сообщение
    Если я прав с вопросом о <xReqReady : BOOL>, то эта структура содержит "лишние" данные
    Я предложил сделать видимой структуру <OMB_SlaveRecievedFrameDescription> потому что это упрощает как вашу задачу, так и работу модернизированного ФБ, нет необходимости создавать новые структуры и в них что-то копировать. Если же вы решите создать отдельную структуру, то перечисленного вами достаточно.
    Кстати, в вашей структуре <pRequestData> это указатель на буфер целиком или же только на данные запроса?
    Цитата Сообщение от Осинский Алексей Посмотреть сообщение
    Но, на сколько мне известно, стандартной ошибки Modbus для такого случая нет (ILLEGAL_DATA_VALUE возвращается в случае, если № первого регистра в диапазоне допустимых значений, а № последнего - выходит за него).
    Как Вы считаете, как себя должен повести Slave в таком случае?
    Пока что в голову приходит 2 варианта:

    Вернуть ответ "запрос обработан", но не записывать данные в буфер SLAVE'а (в таком случае пользователь может быть обескуражен тем, что запросы проходят, но данные не меняются);
    Вернуть код ошибки (например, тот же ILLEGAL_DATA_VALUE), а в документации на библиотеку указать в каком случае может возникнуть эта ошибка (в таком случае пользователь опять же может быть удивлен тем, что запрашивает явно корректные регистры, но ошибка указывает, что нет).
    Я предложил добавить входную переменную <eCustomErr : OMB_Slave_SLAVE_BLOCK_ERROR> для того, чтобы пользователь сам решил, какой код ошибки должен быть передан, если запрашиваемая операция по его мнению невозможна (естесственно, в пределах значений от 0..3). Ваш ФБ получает данное значение в следующем цикле ПЛК и продолжает как ни в чём не бывало (0) или же формирует ответ об ошибке (1..3). Всё остальное исключительно на совести пользователя. Если значение за пределами (0..3) то можно поступить на ваше усмотрение: либо считать это (0), либо просто не отвечать мастеру. Мне же встречались устройства, которые на попытку записать в адреса, предназначенные только для чтения возвращали как ILLEGAL_FUNCTION так и ILLEGAL_DATA_ADDRESS.
    Спасибо, что откликнулись на предложение.

Страница 2 из 4 ПерваяПервая 1234 ПоследняяПоследняя

Похожие темы

  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

Ваши права

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