Да, так можно сделать.Цитата:
Сообщение от Эдуард_Н
Да, так можно сделать.Цитата:
Сообщение от Эдуард_Н
И ещё вопрос, во всех примерах модуль 8А висит на другом порту, а как этот модуль на тот же порт повесить на котором висят 16Д и 16Р?
Вопрос непонятен. В примерах показано, как опросить два модуля, подключенных к одному порту. Опрос трех, четырех и т.д. модулей выполняется совершенно аналогично.Цитата:
Сообщение от Эдуард_Н
В смысле без разницы дискретные или аналоговые.Цитата:
Сообщение от Евгений Кислов
Разницы, в принципе, нет. Если углубиться в тему, то у аналоговых модулей есть определенное время обновления значений каналов, и для оптимизации обмена можно опрашивать их в соответствии с этим временем. Но, опять же, никто не запрещает их опрашивать и в цикле программы.Цитата:
Сообщение от Эдуард_Н
Разница есть. Если повесить 8А и дискреты на один порт - начинаются тормоза дискретного ввода-вывода. Дело в том, что 8А занимает шину на 500 - 1000 мс при ответе, даже при опросе одного канала (о чем неоднократно писалось на форуме).
Видимо зная эту особенность авторы и разнесли модули на разные порты. Я на днях вешал все три модуля на один порт - дискреты работают плохо.
Мы их тоже вешаем на один порт, а второй под модем.
Еще интересно выделение на каждый порт своей задачи. Это расценивать как официальную рекомендацию от "Овен" или просто прихотью автора документа? Во всяком случае объяснения в тексте не нашел.
Расценивайте это как один из способов структурирования проекта.Цитата:
Сообщение от alexx751
Ну хорошо хоть не в разные контроллеры обмен вынесен - так еще "структурированее" будет:)
И все же если серъезно - так надежнее/более стабильно? Или такой информации нет?
Вопрос надежности/стабильности в данном контексте не рассматривался, и сложно представить, что между ним и разнесением программ опроса различных портов по отдельным задачам есть явная взаимосвязь.Цитата:
Сообщение от alexx751
Повторюсь, это просто способ структурирования проекта, который упрощает отладку.
В документах "Модули МХ110 для CODESYS 3.5", "СПК. Modbus (тестирование документа) " как то не уточнено почему использованы именно такие адреса 1 и 16, а так-то хочется знать какие адреса можно присваивать при использовании библиотеки "Модули МХ110 для CODESYS 3.5".
1 и 17, если точнее. Cм. стр. 13.Цитата:
Сообщение от Эдуард_Н
Понял, спасибо.
Ладно, я перескажу написанное на стр. 13 другими словами.Цитата:
Сообщение от Эдуард_Н
Модули конфигурируются по протоколу Овен. Во время конфигурирования каждый модуль занимает в сети кол-во адресов, равное числу его каналов.
Предположим, у вас в связке 4 модуля 8А. Вы достали их из коробки, по одному подключали к ПК через АС4, настраивали и задали адреса 1,2,3,4.
Потом подключили к контроллеру. Все работает нормально. Через какое-то время возникла необходимость поменять тип датчиков. Вы подходите к шкафу, отключаете всю связку и через АС4 цепляете ее к своему ноутбуку. Пытаетесь настраивать модули и видите, что происходит что-то не то. Это объясняется тем, что при настройке модуля с адресом 1 отправляются команды на адреса 1-8 (еще раз - в протоколе Овен модуль занимает кол-во адресов, равное числу каналов). Вам приходится разбирать связку и подключать каждый модуль к ноутбуку по отдельности.
Если бы вы задавали адреса с разрывом в число каналов (в данном случае, соответственно, это были бы 1-9-17-25), то смогли бы переконфигурировать любой из модулей, не разбирая связки.
Никаких проблем. Написанную простыню я оставлю для тех, кто столкнется с подобным вопросом.Цитата:
Понял, спасибо.
Когда вы запускаете Конфигуратор Mx110, то он связывается с модулями по протоколу Овен.Цитата:
Сообщение от Эдуард_Н
В остальных случаях вы сами выбираете протокол, по которому работаете (в данном документе - протокол Modbus).
Т.е. задавать адреса в стиле 1,2,3,4 и т.д., в принципе, можно - все будет работать - но возникнут сложности в случае необходимости переконфигурировать модули.
Ещё раз спасибо, извините за все эти вопросы, просто завтра запускать один из объектов на СПК110 и я волнуюсь.
Конфигурация СПК207 (Modbus TCP Slave) <--> Master ScadaЦитата:
Сообщение от Евгений Кислов
Если у нас Codesys v3.5 SP5 Patch5 - будет ли работать?
Будет, но только функции чтения/записи регистров. Функции работы с битами поддержали в более поздних версиях.Цитата:
Сообщение от ALEXSP
По факту: привязка QW работает только по битам, привязанные слова не работают!!!Цитата:
Сообщение от Евгений Кислов
По всей видимости, вы что-то делаете не так. Если вы детально сформулируете проблему, а также выложите проект для СПК и скриншоты настроек вашего OPC-сервера (как я понимаю, данные в скаду вы передаете с помощью него), то постараюсь помочь .Цитата:
Сообщение от ALEXSP
Я думаю все делаем правильно. Проверяли программой Modscan. Запросы делались 4-й функцией. При этом то что в СПК было привязано к QW битами - читалось правильно, то что в СПК было привязано к QW словами - читались 0. Грешим на версию CodeSys - v3.5 SP5 Patch5. Я просто направил это сообщение, чтобы Вы проверили не осталась ли эта ошибка в новой версии.Вложение 24514Цитата:
Сообщение от Евгений Кислов
Есть возможность проверить не Modscan'ом, а чем-то еще? Мне доводилось опрашивать input registers СПК через ворды по TCP различным устройствами (другими СПК, панелями оператора, виртуальным контроллером CODESYS, OPC-серверами), и проблем никогда не возникало.Цитата:
Сообщение от ALEXSP
Если возможности нет, я могу проверить у себя - но тогда прошу прислать архив проекта (на e.kislov@owen.ru) и подробную инструкцию в скриншотах, что вы делаете в утилите Modscan (еще лучше - саму утилиту тоже, чтобы избежать ситуации разных версий).
Upd. - ну, собственно, у меня получилось:
Вложение 24515
Моя версия компонента Ethernet: 3.4.2.0
Моя версия компонента Modbus TCP Slave Device: 3.5.2.0
У нас те же версии, к сожалению то что не работает мы уже стерли, а вместо этого есть работающий вариант: union (real, 2 word), затем word раскладываем на 16 булевских переменных, и затем эти булевские переменные привязываем к битам QW - все работает!Цитата:
Сообщение от Евгений Кислов
В предыдущей версии программы было: union (real, 2 word), затем word привязываем к слову QW - читаются нули!
Понятно. Но, как видите, у меня работает и привязка WORD к QW - с той же Modscan. Чтобы локализовать проблему, нужны эксперименты именно с вашим проектом и версией утилиты. Если это вам интересно, пишите на мою почту.
Посмотрите так надо увеличивать количество входов и выходов
Отправил ссылку на проект по почтеЦитата:
Сообщение от ALEXSP
Да, в таком стиле. Хочу заметить, у вас порядок выполнения блоков вообще не соблюдается - так быть не должно.Цитата:
Сообщение от Эдуард_Н
Спасибо, завтра займусь экспериментами. Скриншоты настроек Modscan тоже отправьте, пожалуйста (если этого не сделали) - все, которые посчитаете нужными. Версия утилиты тоже интересует. У вас 32bit или 64?Цитата:
Сообщение от ALEXSP
Да я так, спеша накидал.Цитата:
Сообщение от Евгений Кислов
Я думаю дело не в Modscan, у нас Modscan32 скриншот примерно такой же. Когда мы привязываем в СПК регистры по битам, то все работает - читается 4-й функцией и в Modscan и в Master Scada. Но в отличие от Вашего скрина (где значение 123) у нас в онлайне значения переменных на этой вкладке не отображались, мы могли посмотреть значения только на других вкладках. У меня 2 версии этого - 1) В новой версии Codesys это исправлено (это хорошо); 2) В Вашем примере привязка начинается с слова, а в нашем с битов, а слова идут дальше (а это уже могло остаться и в новой версии, что очень плохо)Цитата:
Сообщение от Евгений Кислов
Вы попробовали рекомендацию из моего письма? (Всегда обновлять переменные: Вкл. 2 (в задаче цикла шины))Цитата:
Сообщение от ALEXSP
Евгений! К сожалению у нас СПК на объекте и мы не можем это попробовать (у нас стоит наследовать от родительского устройства), если у Вас есть возможность проверить - будем очень признательны.Цитата:
Сообщение от Евгений Кислов
Дело в том, что эта настройка всегда должно быть в состоянии Вкл. 2 (всегда в задаче цикла шины), это неоднократно упомянуто в документе. С такой настройкой я без проблем считывал значения из привязанных вордов без дополнительных манипуляций с помощью Modscan (и не только ее). Без этой настройки у меня вообще не получилось считать данные, даже при привязке отдельных битов.Цитата:
Сообщение от ALEXSP
У нас биты (привязанные) заработали как только мы поняли что такое QW и IW, но все же если есть возможность проверьте: привяжите в Outputs[0..1] несколько бит, а дальше несколько слов.Цитата:
Сообщение от Евгений Кислов
Привязал - работает нормально.Цитата:
Сообщение от ALEXSP
Ещё один вопрос:
В КДС3 в Modbus_Master_COM_Port какие лучше в моём случае поставить значения параметров "Таймаут отклика(мс)" и "Время между фреймами(мс)"
Едва ли можно составить какую-то формулу расчета оптимальных значений этих настроек. В целом, если проблем со связью нет, то лучше оставить значения по умолчанию.Цитата:
Сообщение от Эдуард_Н
Да, наверное Вы правы. Второй день проблем со связью не наблюдаю. Посмотрим, что будет дальше.:)Цитата:
Сообщение от Евгений Кислов
Как записать выходы с 9 по 16? Первые 8 работают.Код:abyMY110_16R_buffer[1].0:=xMV110_16D_input1;
abyMY110_16R_buffer[1].4:=TRUE;
abyMY110_16R_buffer[2].0:=TRUE;// следующие строки - правильные?
abyMY110_16R_buffer[2].1:=TRUE;
abyMY110_16R_buffer[2].2:=FALSE;
abyMY110_16R_buffer[2].3:=TRUE;
abyMY110_16R_buffer[2].4:=FALSE;
abyMY110_16R_buffer[2].5:=TRUE;
abyMY110_16R_buffer[2].6:=FALSE;
abyMY110_16R_buffer[2].7:=TRUE;
// [3.1.2] запускаем ФБ опроса модуля МУ110-16Р
MY110_16R
(
Enable:=COM_SERVICE_COM3.Ready,
Mode:=MB_RTU,
DevAddr:=48,
FirstAddr:=50,
Quantity:=1,
ComHandle:=COM_SERVICE_COM3.handle,
TimeOut:=T#500MS,
Buffer:=abyMY110_16R_buffer
);
sss := MY110_16R.RegCnt;
zzz := MY110_16R.Exception;