Если ув. RV9WFJ не ошибается, тогда просьба к Александру Приходько- исправьте шаблон.
Вид для печати
Подробнее, пожалуйста. Со скриншотами желательно. Во время тестирования таких проблем замечено не было.
---UPD---
Возможно я понял в чем проблема - периоды ШИМ пишутся по команде (RISISNG EDGE, Триггер) для разгрузки сети т.к. вряд ли возникнет ситуация, в которой нужно будет постоянно их писать.
Чтобы записать значения установите переменную типа Bool, которую меняйте с FALSE на TRUE в тот момент, когда нужно записать переменную и с TRUE на FALSE в следующем цикле ПЛК.
Скриншот: Вложение 15501
Если Вам нужно писать периоды постоянно - смените триггер опроса с RISING EDGE на CYCLIC.
Скриншот: Вложение 15502
2жды кликните по каналу на вкладке Modbbus Slave Channel и измените тип опроса "2" на скриншоте
Обновился сегодня до CODESYS V3.5 SP5 Patch 4. В проектах было замечно, что у модуля 8А на месте стандартного изображения появился значёк красног цвета с вопросом внутри, хотя у других модулей такого нет.
Устраняеться обновлением устройства
Реализована новая версия шаблонов МХ110.
Теперь мы поддержали все модули, имеющиеся в нашей линейке.
В новой версии мы постараемся сделать реализацию формата REAL для чисел с плавающей точкой (которые на данный момент передаются как 2 переменные WORD) и доделаем пользовательскую документацию.
Александр Приходько, когда выложите новую версию шаблона? С ув. Дмитрий.
Есть ли возможность добавить в библиотеку ModulsOwenLib модуль выходов МУ110-16К? В данный момент есть только 16R, но нужен именно K. Задача - писать ШИМ напрямую.
Откуда у Вас такие сведения? (см. рисунок)
Вложение 16466
Если у Вас каким-то образом оказалась версия инсталлятора, в которой модуль называется просто 16R (хотя я таких версий не помню), то смело используйте шаблон 16Р для модуля 16К.
Номера регистров там идентичны.
Или скачайте из 1го поста этой темы последнюю версию инсталлятора.
Я имел ввиду малость другое - шаблон именно в ModulsOwenLib, подключаемый не к порту (Devices) а с помощью CommCon
Там и брал. КДС3.5, чистая установка.
--------------
Или подскажите обозначение регистра, который сообщает об ошибке связи с модулем.
Скажите, а шаблон для МЭ110-220 будет?
Конкретно интересует МЭ110-220.3М. Хотя в библиотеке шаблонов нет ни одного модуля МЭ.
Так что, про шаблоны никто не знает?
На МЭ110 3М могу на ModBus.lib код дать, но у меня там не все параметры опрашиваются. Если чего не хватит можете сами допилить. Только версия прошивки модуля должна быть не ниже 1.23
Уважаемый производитель, когда же будут шаблоны на все модули, выпускаемые Вами?
А почему шаблоны построены не на групповых запросов. Ведь для того же мв110-8а один запрос где читаются 48 регистров должен быть быстрее чем 40 отдельных запросов или нет?
Мне очень интересно разобраться как происходит обмен при работе через конфигуратор. Смотрите на скорости 38400 запрос одного регистра примерно 3мс+2мс задержка ответа модуля+3мс ответ модуля+10мс время между фреймами по умолчанию. Итого 18мс. В шаблоне 40 запросов, пусть нам нужны только 16. На это нужно 288 мс. Значит больше трех модулей в секунду мы не опросим . А при групповом запросе всех регистров получаем 3мс+2+16+10=31 мс. Что почти в 10 раз быстрее. И второй момент как ведёт себя планировщик, если он не успевает опросить регистры с отведенной частотой. В шаблоне по умолчанию 100мс. С такой скоростью по моим подсчетам можно успеть опрашивать только 5 регистров. А что случается когда их допустим 16?
Немного не пойму, откуда взялось ограничение. И почему именно 100мс?
Признаться, я такого не помню.
Модули опрашиваются по кругу. Т.е. 1-й,2-й,3-й,... n-nй.
Программа вернется к 1му модулю не раньше, чем будут опрошены все модули вне зависимости от того, сколько времени займет опрос 1го модуля и от того, сколько времени займет опрос всех модулей.
Но это относится к функционированию модуля Modbus Master, а он реализован компанией 3S.
Нами же реализованы только шаблоны модулей Mx110
это не ограничение, это время цикла опроса, регистров в вашем шаблоне. Разумеется время можно изменить, но по умолчанию оно такое.
В том и дело если опрос по модбас не используется на максимум. Опрос идет не по модулям, а по циклу опроса регистров. У меня например мастер успешно опрашивает 4-ый по счету модуль каждые 100мс, 1 и 2 каждые 500мс, 3 каждую 1000мс. Тут все логично и понятно обмен успевает пройти в оговоренные рамки. Меня интересует что будет когда мастер не может опросить регистр с скоростью установленное во времени цикла. Ваш шаблон был просто для примера у вас 40 запросов, с временем цикла каждого 100мс. Если модуль один и остальные настройки таргета в части модбаса не трогать. То после опроса 5 регистра, наступит время опроса 1, но остаются не опрошенными еще 35 регистров. И вполне очевидно что мастер продолжит опрашивать их и только дойдя до последнего, вернется к первому. Т.е. реальный опрос будет идти каждые 700-750мс, вместо установленных 100мс. Вроде бы тоже логично сами виноваты :) . Мастер танцует как может.
Но если среди слейв устройств будут разные по времени опроса регистры. Они также будут опрашиваться с тем временем которое получится? Или более низкая уставка опроса будет иметь приоритет?.
Если приоритета нет, то отсутствие групповых запросов в шаблонах это просто вредительство:)Потому что работа по шаблонам в текущем виде ( я про те модули где регистров много) и так не высокий отклик по сети модбас, делает не предсказуемым
Сами по судите у меня в системе 4 модуля. мв110_8а, мв110_8а, му110_16к,мк110_8д_4р. Если строить все на ваших шаблонах то опрос дискретных входов в последнем модуле наступит. Только через 1500мс и даже если убрать из опроса половину не нужных регистров, то время реакции системы 400-500мс на дискретное событие видеться чудовищным. Я уже не говорю что запрос реал значения скажем температуры и циклическое время измерения очень желательно синхронизировать
Все, понял о чем речь.
Со 100% уверенностью не могу сказать (а на практике отследить этот момент достаточно сложно), но думаю, что под периодом опроса имелся в виду "минимальный период опроса", а не гарантированный период опроса.
Т.е. если очередь опроса параметра дошла до него, а время до след. опроса еще не прошло, то параметр просто пропускается, но все параметры опрашиваются циклически.
Но это мои догадки. Ответить со 100% вероятностью смогут только разработчики в 3S.
На днях, возможно, придется работать с большим кол-вом модулей, там на практике попытаюсь отловить этот момент.
У меня такой вопрос.
Модули ввода вывода МВ110.2АС и МВ110.8А подключены к СПК207, CODESYS загружена в СПК. При этом программа предусматривает опрос и других модулей (см. изображение). Модули, находящиеся слева отображают результаты измерений верно, однако остальные модули не подключены к сети RS485, но статусы измерений у всех входов успешны. Почему так? Пользовался шаблонами Мх110.
1. Если связь с каким-либо модулем в сети пропадает, как это передать в панель СПК207? Как реализовать в CODESYS формирование ошибки связи с модулем? Предполагется ли данная реализация в библиотеке шаблонов модулей Мх110? Если нет, просьба подсказать как программно реализовать ошибку связи с модулями.
2. Как уйти от цифр (в модулях слева), если датчик отключен? Через редактор интерфейсов?
3. Увеличение скорости. К одному из входов модуля подключен термометр сопротивления. Так вот, значение температуры обновляется раз в 20-25 сек. Скорость передачи задана в настройках МodbusCom 38400. Так же и в модулях.
Так как все-таки ПРАВИЛЬНО реализовать в СПК207 ошибку связи с модулем ввода-вывода? Можно ли так, как во вложении? Или по другому это делается? Где-то эта тема обсуждалась?
Зачем он Вам? Все равно, Вы не будете брать все переменные модуля. А тогда - лишнее время ответа.
Если был пример на языке CFC, тогда было бы легче, но пример только на ST.
СПК110 + модули линейки Мх110 (32ДН/8АС/8И/16К), CDS v3.5 SP5
Последние версии таргета, библиотек etc...
Установил библиотеку Mx100 Assistant, добавил модули, привязал переменные - в общем, выполнил все стандартные манипуляции. Все запустилось, но как-то странно все работало. Все модули опрашивались без ошибок, на дискретных входах сигналы корректно обрабатывались, дискретный выход задавался, но ридбек не подтверждал на выходе наличие сигнала. Светодиоды (что светодиоды каналов дискретных выходов, что RS-485) на модулях мерцали с большим периодом, в целом, сложилось впечатление, что периодически "отваливалась" сеть.
Как бы то ни было, поэкспериментировав с периодом опроса регистров, таймаутами задержек и временем между фреймами, и не обнаружив причину таких странностей решил полностью продублировать проект, заменив только модули на стандартные из модбас либы. Все завелось и заработало с первого раза - работа нормализовалась.
Добавлю, что очень интересно будет узнать результаты эксперимента по опросу большого кол-ва модбас слейвов. А именно, через какой промежуток времени (здесь стоит сделать отступление и дать понять, что я осознаю, полученные данные таких замеров будут относительными - влияет и кол-во опрашиваемых регистров и проч настройки сети) опросится последний модуль в сети...
Очень хотелось бы, чтобы в MV110_Get_Real можно было подсовывать не только массив из двух значения флоат, а тупо, через запятую эти два значения. Поясняю. Считываю с ТРМ138 каждый канал в архив из пяти значений - положение десятичной точки, значение датчика трёхзначное целое, флаг аварии датчика и два значения флоат, которое склеиваем MV110_Get_Real. Так вот, прежде чем конвертировать значение датчика в REAL, надо проверить, не в аварии ли датчик, т.к. ТРМ138 - странная железка - в случае ошибки датчика, на экране LLLL, а по модбасу отдает последнее верное значение.
Здравствуйте.
Настроил опрос с помощью шаблонов: Вложение 17654
Версия таргета 3.5.4.20
версия Modbus COM 3.4.0.0.
Modbus Master 3.5.5.0
Пытаюсь управлять релейным выходом, но при каждом новом цикле опроса состояние выхода сбрасывается. Т.е. если подаю TRUE на первый выход, то он не включается на постоянно а щелкает на некоторое время в каждом цикле опроса.
Подскажите пожалуйста с чем это может быть связанно?