CODESYS V3.5. Настройка обмена с другими устройствами (Modbus, ОВЕН, OPC и др.)

[melky]

keysansa вы не поняли, стандарт прозрачен, путаницу вносят производители, указывая то физический адрес, то логический как первый в карте регистров своих устройств.

[keysansa]

Читайте внимательно стандарт, там все описано.
Регистры нумеруются с 1, адреса с 0. Зачем так сделано? Не знаю.

Я прочитал и не раз. Поэтому и пишу, что не прозрачно.

[keysansa]

keysansa вы не поняли, стандарт прозрачен, путаницу вносят производители, указывая то физический адрес, то логический как первый в карте регистров своих устройств.

Я согласен, что производители вносят путаницу смещением. Но мне не понятно, что в части Modbus является физическим, а что логическим адресом, которые отличатся 1,2,3,4. Я так понимаю, что физический адрес переменной - это адрес памяти устройства, где хранится переменная, доступная обмену по Modbus по ее логическому адресу в таблицах. Но тогда у их смещения могут быть более одной страницы памяти, а никак не +1..4...

[Евгений Кислов]

Коллеги, если кто-то хочет продолжить дискуссию чисто о Modbus (не применительно к конкретной ситуации с ПЛК, программируемыми в CODESYS V3.5) - создайте отдельную тему в курилке, пожалуйста.

P.S. - про нюансы адресации с конкретными примерами можно почитать здесь (п. 1.1).

[M.Juanito]

Добрый день.
Честно пытался найти на форуме ответ, но по "запросу" передний фронт (rising edge) ничего подходящего не нашел.

В проект подлкючено несколько slave устройст. Естественно они орашиваются значительно дольше, чем идет цикл программы.
Я хочу записывать значение в регистр слева, только если оно было изменено и по триггру "передний фронт".

Вопрос:

Если у меня цикле программы будет такая конструкция:

IF A<>B THEN
wNewValue:=B; //переменная привязанная к каналу
xWriteValue:=TRUE; // триггерная переменная
xWriteValue:=FALSE;
END_IF;

слейв заметит этот "передний фронт"?
или надо держать триггер в TRUE и ждать когда значение регистра изменится и только потом сбразывать в FALSE?


наверное есть какое то более надженое решение?

[Евгений Кислов]

слейв заметит этот "передний фронт"?

Нет, не заметит.

или надо держать триггер в TRUE и ждать когда значение регистра изменится и только потом сбразывать в FALSE?

При подобном подходе в некоторых конкретных ситуациях могут возникнуть проблемы: например, записываемое в слэйв значение выходит за допустимый диапазон.
В результате слэйв не будет его обрабатывать, значение в регистре останется прежним и триггер навсегда зависнет в TRUE.

наверное есть какое то более надженое решение?

Есть типовое решение - использовать ФБ R_TRIG из библиотеки Standard для генерации переднего фронта команды записи.
Чтобы говорить про "надежность" - для начала нужно определить ее критерии.

[M.Juanito]

Есть типовое решение - использовать ФБ R_TRIG из библиотеки Standard для генерации переднего фронта команды записи.

ага. спасибо.

я правильно понял, что после того как R_TRIG отработает, можно будет сразу скинуть тригерную переменную?

IF A<>B THEN
     wNewValue:=B; //переменная привязанная к каналу

     RTRIGInst(CLK:= TRUE);
     xWriteValue := RTRIGInst.Q;
     xWriteValue:=FALSE;

END_IF;

[Евгений Кислов]

Нет, вы поняли неправильно.

IF A <> B THEN
     wNewValue := B; //переменная привязанная к каналу
END_IF

RTRIGInst(CLK:= (A <> B), Q => xWriteValue);

Пояснение - передача значений переменных, привязанных к каналам, в коммуникационный драйвер происходит после выполнения цикла задачи, к которой привязана программа.
"Промежуточные" значения (которые переменная принимает до окончания цикла) не учитываются.
В обоих ваших примерах, которые выложены выше, переменная xWriteValue к концу цикла будет иметь значение FALSE - и коммуникационный драйвер "увидит" только его.

[M.Juanito]

Спасибо!

а может посоветуете учебные материалы для изучения этого вопроса?
или примеры использования откуда можно идеи списать)

[Евгений Кислов]

Спасибо!

а может посоветуете учебные материалы для изучения этого вопроса?
или примеры использования откуда можно идеи списать)

Для изучения какого именно вопроса?