Возможно ли создать каналы связи с модулями DCS-2000 используя автопостроение каналов для узла типа "АДЕМ-9000" напрямую через СОМ-порт операторской станции и преобразователь I-7520? Неясно какие настройки параметров обмена по последовательному порту в этом случае задавать. В инструкциях на модули DCS-2000 указан только верхний предел скорости обмена.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Самый простой вариант построения узла МРВ с каналами для обмена с модулями DCS-2000 состоит в следующем. Создайте узел контроллера ADEM9000, набейте его нужными модулями, настройте каналы и последовательный порт, а затем измените тип узла (есть такая вкладка в "Свойствах узла") на МРВ нужной информационной мощности. Или можно воспользоваться опцией экспорта/импорта объектов из узла контроллера в узел МРВ. Можно и вручную создать и настроить каналы MODBUS для обмена с нужным модулем, если Вы точно знаете функции и адреса регистров, используемые в конкретном модуле. Параметры настройки последовательного порта должны точно соответствовать тем настройкам, которые Вы задаете в модулях DCS-2000. МРВ будет поддерживать любые настройки, которые поддерживают модули УСО DCS-2000.
Posted by HELLA (Участник № / Member № 104) on :
Добрый день! У НАС ВОЗНИКЛИ ПРОБЛЕМЫ при работе связки ПЭВМ - СОМ-порт -I-7520-модули DCS2000 при использовании встроенного протокола MODBUS RTU. При работе в сети 1-2 модулей количество ошибочных транзакций приемлемо -1-2% от общего количества. (настройки обмена 38.4 кбод,8-1-е,таймаут 1000, период пересчета 2х0.055).При количестве модулей больше двух количество ошибочных транзакций возрастает до 30-50% (таймаут 300,период пересчета 6х0.055 как оптимальные). Идут сообщения типа: OUT :06 03 00 01 00 03 55<U> bc ERR IN0: RS:COM2 check error (AI12_6_CHANN2) Ошибки равномерно распределены по всем модулям и каналам.Такое впечатление ,что часть ответов на запросы вообще не доходит. Кстати подобное наблюдалось при работе по протоколу MODBUS RTU трех и более частотных преобразователей фирмы LG. Хотелось бы знать как с этим бороться и причина ли в: 1.неверных настройках обмена по посл.порту 2.поддержке протокола в самих модулях 3.работе адаптера I-7520 (может быть нужен другого типа с управл.сигналом) 4.ошибках в обработке коллизий во встроенном протоколе MODBUS RTU. С нетерпением ждем ответа!
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) Скорости настроены для всех модулей одинаково? 2) А Вы разве задавали управление приемопередатчиком для I7520? Он ведь автоматический и ничего не нужно для него задавать. 3) Попробуйте протестировать обмен только с одним модулем - как быстро он может обмениваться данными.
Не исключены также внешние помехи на линию связи, а также качество самой линии связи. Какова длинна самой линии связи?
Posted by HELLA (Участник № / Member № 104) on :
Уточнения: 1.скорость для всех модулей одинакова -38.4 кбод 2.I-7520 работал в режиме без управления приемопередатчиком. 3.Для одного (любого)модуля - все нормально. 4.линия связи минимальна -1метр.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Есть подозрение, что виноваты сами устройства. Попробуйте реализовать ту же систему опроса модулей, но не в ТМ, а каком-нибудь ModBus клиенте, например в KEPware OPC Server. По крайней мере это позволит точно выяснить в какой части ошибка: в ТМ или в модулях.
Posted by Kuznetsov (Участник № / Member № 360) on :
Скорее всего проблема в карте адресов модулей DCS-2000. Если модуль не имеет в своей карте адрес, запрашиваемый Трейс Моуд, модуль выдаст (должен) ошибку или вообще не ответит.
Та же ситуация возникнет и при групповых запросах к DCS-2000.
Удачи!
Posted by HELLA (Участник № / Member № 104) on :
Добрый день! Мы реализовали систему опроса тех же модулей через ОРС-сервер Lectus Modbus OPC 2.5 сервер (www.lectussoft.com)с частотой опроса 0.5с для аналоговых входов и 1с для дискретных входов-выходов.После установления связи(1-5с)количество безошибочных транзакций было близко к 100%. Сервер выполнен очень качественно и имеется полнофункциональная демо-версия на сайте. Напрашивается вывод о екачественной работе встроенного протокола MODBUS RTU TRACE MODE 5.15. Тем более те же проблемы наблюдались при работе с 3 и более частотниками с теми же симптомами. Может быть есть другие версии modbus.dll , modbus.dld?
Posted by Kuznetsov (Участник № / Member № 360) on :
Вы можете попробовать сравнить запросы Трейс Моуд и OPC-сервера программой "Portmon", которая может вести лог обмена данными по порту. Думаю, по представлению этого обмена, АдАстре будет легче разобраться с проблемой или выяснить, что таковой не существует.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Вы из МикроМРВ с ними работаете или из МРВ?
Posted by HELLA (Участник № / Member № 104) on :
Пробовали из МРВ и МикроМРВ ситуация одинакова...
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Какие-то неравноправные тесты Вы производили в ТМ у Вас цик пересчета от 100 до 300 мс испытавался, а в ОРС-сервере 500мс и 1000мс. Попробуйте в ТМ такие-же циклы выставить или в ОРС быстрее скорость опроса выставить. Насчет реализации в ModBus ТМ5 - предположение спортное, потому как многие наши пользователи его используют и таких ошибок у них не возникало. Может провести критические тесты с эмулятором ModBus, чтобы исключить данное предположение?
Posted by HELLA (Участник № / Member № 104) on :
Добрый день! Что касается циклов опроса то конечно же работа протокола оценивалась и при 500мс и 1000мс. Результат прискорбно однообразен.Следует отметить что по каналу ДИАГНОСТИКА MODBUS выдавался код 108 нех (потеря байта).Вообще то работа более менее нормальна при количестве модулей до двух. Что касается "провести критические тесты с эмулятором ModBus" ,то что имеется в виду?
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
У меня тоже возникали серьезные проблемы при обмене по ModBus c защитными реле фирмы Alstom MiCOM P12x и измерительными центрами MiCOM M220. Скорость 9600, периоды опроса изменял от 100 мс до 5 сек, изменял различные таймауты в настройках узла относящиеся к RS, но ситуация неизменно оставалась следующей: по истечение некоторого времени (от 1 до нескольких мин, в зависимости от частоты опроса) обмен просто прекращался. Не помню была ли при этом недостоверность каналов. Проект был тестовый, поэтому значения не придали и забыли.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Какие номера функций ModBus использовали для обмена?
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
Rin Word(4) Rout Word(3)
Posted by HELLA (Участник № / Member № 104) on :
Добрый день! Продолжая эксперименты с модулями DCS-2000,в частности с модулем DIO-11 установили следующее: при работе в сети больше трех модулей данного типа и количестве ошибочных транзакций больше 25% наблюдается эффект сбрасывания выходных значений физических каналов (Out,H,CH=000b,Wword(6))модуля DIO-11 через 5-20секунд после отработки выходных каналов TRACE MODE. Причем после изменения в дальнейшем любого из четырех каналов группы правильное значение остальных каналов кратковременно восстанавливается на 5-20с а затем снова обнуляется. Что существенно,при работе одиночного модуля этот эффект отсутствует,но остановка работы МРВ также приводит к обнулению выходных каналов модуля,вне зависимости от состояния в котором они до этого находились,что СОВЕРШЕННО НЕДОПУСТИМО!
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Сброс выходов никак не связан с ТМ, скорее всего это аппаратная особенностью данного модуля УСО. Похоже, что ему необходимо постоянно посылать команду на выходы. Похожая ситуация была у одного из наших пользователей с модулем I8057 (дискретные выходы). Он сбрасывал свои выходы, если с ним не было обмена от ТМ, и для того, чтобы он держал их постоянно на него было необходимо выдавать команду состояния выходов постоянно, даже, если она не менялась. В ТМ каналы Output выдают команду на внешний интерфейс только в случае изменения значения канала, поэтому - их необходимо объединять в таком случае в группу и выдавать по ним принудительную выдачу команд с определенным интервалом, тогда значение выходов на модуле УСО не будет сбрасываться. В любом случае - данный вопрос Вам необходимо задать специалистам ЭМИКОНа. На данный момент у нас имеется один модуль DIO11 и мы попытаемся провести с ним тесты по обмену в ТМ.
Posted by HELLA (Участник № / Member № 104) on :
Добрый день! В продолжение темы: Действительно,по истечение 2с, при отсутствии обращения к модулю,его выходы принудительно сбрасываются.Экспериментально установлено,что модули дискретного ввода-вывода работают нормально (не сбрасываются в процессе работы) при количестве ошибочных транзакций не более 3-4%. Такой процент достигался нами лишь при количестве модулей DIO-11 в сети не более 4-х и при отсутствии модулей других типов.При этом приходилось уменьшать интервал опроса до 20 мс и использовать фазовый сдвиг (F1-F4)при опросе. Вообще, использование модулей данного типа дает повышенный процент ошибочных транзакций. Если при использовании Lectus OPC 2.5 сервера нам удавалось при наличии в сети пяти модулей AI-12 , трех модулей AI-10 и одного DI-11 ДОСТИГАТЬ 100% успешных транзакций,то при введении дополнительно восьми DIO-11 количество ошибочных транзакций стало около 50%,а состояние дискретных выходов - неуправляемым.Что касается встроенного протокола MODBUS TRACE MODE 5.15, то даже при использовании только AI-12, AI-10, DI-11 количество ошибочных транзакций не удавалось снизить меньше 25%.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) Что задано в параметре ADDR? 2) Какой тип преобразователя RS485 используете?
Сейчас работает проект с одним модулем по 300 транзакций в секунду на 115Кбод - пока ни единой ошибки или сбоя не зафиксировано...
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Вот результаты испытания: RS:COM4 TRANSACTION=622793 ERROR=0 TIME=2512.04 TOTAL_BYTE=9598507 AVR_RESPONSE=0.00260833 MAX_RESPONSE=0.453
Ни одной ошибки на 622793 транзакций.
Posted by HELLA (Участник № / Member № 104) on :
Бесспорно,что при работе с одним модулем все обстоит прекрасно!(см.выше).Дело в том, что все фокусы начинаются с количества модулей более 2-х.Тут уж важно,как протокол обрабатывает многоадресные запросы. В параметре ADDR задается адрес блока в сети MODBUS в шестнадцатеричном виде (0d,0e,0f,10, 11-14)-8 модулей. Преобразователь I-7520,проверялось и на CI-02 от ЭМИКОНа. Для 4-х модулей удалось получить количество ошибочных транзакций около 0,5% но некорректным методом используя фазовый сдвиг (F1-F4). Но дальнейшее увеличение количества модулей пока проблематично....
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Лог-файл работы проекта, пожалуйста, скиньте на наш E-mail. Необходимо посмотреть характер ошибок...
Posted by HELLA (Участник № / Member № 104) on :
Скинул лог-файл на hotline1@adastra.ru. Если нужна более глубокая запись или сам проект - сообщите.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Судя по логу - ТМ нормально выдает команды модулям, а вот в ответ от УСО ничего не приходит! Можно на сам проект посмотреть?
Posted by HELLA (Участник № / Member № 104) on :
Добрый день! Проект отправлен на hotline1@adastra.ru
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Ваш проект работает под релизом 5.10, а последний релиз 5.15 - за посление 3 релиза в ModBus много чего поменяли и исправили. Рекомендую провести все те же тесты, но на релизе 5.15!
Posted by HELLA (Участник № / Member № 104) on :
Добрый день! Проверяли ранее и проверили дополнительно сейчас. Полная аналогия ситуации. Версии библиотеки modbus.dll ТМ5.10 -48К от 27.12.04 ТМ5.15 -60К от 11.05.04 Смущает более ранняя дата библиотеки ТМ5.15, она устанавливалась через обновление с сайта. Если есть несоответствие,просьба прислать последнюю версию modbus.dll,modbus.dld.
Posted by HELLA (Участник № / Member № 104) on :
Еще раз обновил версию до 5.15 Базовая. Версия modbus.dll 60K от 27.12.04. Тот же отрицательный результат.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
#### И у меня на том же modbus.dll проверка производилась. Без модулей провести тест невозможно - у нас он только один. Будем заказывать в Эмиконе.
Posted by HELLA (Участник № / Member № 104) on :
Добрый день! Срок поставки модулей в ЭМИКОНЕ до 8 недель. Мы можем предоставить свои модули во временное пользование.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Это было бы замечательно!
Posted by HELLA (Участник № / Member № 104) on :
Посмотрите сообщение на hotline1@adastra.ru .
Posted by HELLA (Участник № / Member № 104) on :
Добрый день! Удалось ли воспроизвести ситуацию на стенде с 8-ю модулями DCS-2000?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Ситуацию воспроизвести удалось. Похоже, что модули очень критично относятся к длительной непрерывной загрузке шины MODBUS. Методический вопрос мы будем решать с ЭМИКОНОМ. А Вам направим практические рекомендации, которые, мы надеемся, Вам помогут.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Мы послали Вам письмо (4.02.05) с рекомендациями и надеждой на встречу. А ответа нет.
Posted by HELLA (Участник № / Member № 104) on :
Добрый день! Письмо к Нам не пришло. Пришлите на E-mail:gdan@bochvar.ru Спасибо!
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
OK.
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
Мне тоже интересно почитать рекомендации! И, наверное, не только мне...
Posted by ilya (Участник № / Member № 469) on :
Прочитал топик. Здесь звучат высказывания о том, что при использовании Lectus Modbus OPC сервера удавалось достичь более качественного обмена, нежели чем при связи по Modbus RTU непосредственно из TM. Или виноваты исключительно модули DCS-2000? Хотелось бы услышать ответ, а то мы собираемся использовать Modbus RTU для связи с контроллером.
Posted by HELLA (Участник № / Member № 104) on :
Добрый день!
Модули DCS-2000 критичны к увеличению суммарного трафика в шине Modbus. Превышение числа каналов для обмена более 5-10 начинает приводить к ошибкам даже при работе с одним модулем. Эффект связан с тем, что модули EMICON серии DCS-2000 обладают инерционностью в обработке операций коммуникаций. Причём инерционность модулей тем выше, чем выше суммарный трафик в шине Modbus. Данное обстоятельство приводит к тому, что перед повторным обращением к модулю необходимо выдерживать некоторую паузу, длительность которой, в свою очередь, напрямую зависит от общего трафика. Нужно экспериментально подбирать минимально значение таймаута RS-передача (3-4мс)до получения удовлетворительного режима обмена. Такое разрешение таймера можно получить только в МикроМРВ(ДОС). Использовании Lectus Modbus OPC сервера имело смысл лишь для модулей аналогового ввода AI-10(-12)в количестве 6-10 шт. Для модулей дискретного вывода DIO-11 Lectus Modbus OPC сервер вообще малопригоден из-за специфики модуля DIO-11 - инерционность и пр.(реинициализация модуля при отсутствии обращения к модулю более 2 с приводит к сбросу выходных сигналов в нуль). Вообще поведение встроенного драйвера протокола Modbus RTU в ТМ5.хх зависит от конкретной его реализации в оборудовании фирмы-производителя и от количества приборов в сети. Несколько раз натыкались на подводные камни. Нужно проверять на конкретном оборудовании.
Posted by ilya (Участник № / Member № 469) on :
![[Улыбка / Smile]](smile.gif)