This is topic Octagon6030 по COM-3/4 c I-7000 in forum Микро Мониторы Реального Времени / Micro Real Time Monitors at Форум TRACE MODE: техническая поддержка.
Собрали систему, состоящую из компьютера, контроллера Octagon6030 (связь по M-Link COM-1) и модулей I-7000, подключенных к портам COM-2,3 данного контроллера. При наблюдении данных на компьютере, заметили, что каналы соответствующие модулям I-7000, подключенным к COM-3, часто выставляют признак аппаратной недостоверности (по COM-2 гораздо реже). Подключив COM-3 контроллера к компьютеру и запустив HiperTerminal наблюдали наряду с нормальными множество искаженных запросов по протоколу ADAM ASCII. Изменяя скорость передачи по COM-3 контроллера установили, что при увеличении скорости число ошибок снижается. Из этого сделали вывод, что контроллер просто не успевает передавать данные посылаемые в порт программой МикроМРВ. Отсюда два вопроса: 1) Оценивает ли МикроМРВ готовность порта при передаче каждого следующего байта? 2) Является ли недостоверность канала "In M-Link" признаком ошибки по M-Link либо это недостоверность канала-источника?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. Если Вы работаете через встроенный в контроллер конвертор RS-232/RS-485, то одной из причин неустойчивости обмена является очень жесткая аппаратная зависимость параметров управления приемо-передатчиком RS-485 у этих конверторов. Зависит и от скорости линии обмена, и от интенсивности запросов, и от количества подключенных устройств и пр. Все пользователи, работавшие с этой техникой, вынуждены были перейти на выносные конверторы I-7520 или ADAM-4520. 2. Микро МРВ обменивается с COM-портом блоками данных. Работа идет с поддержкой прерываний. 3. Недостоверность выставляется как в случае неполного, искаженного ответа или отсутствия его в течение заданного тайм-аута, так и в случае получения от устройства штатного сообщения об ошибке.
Posted by СВТ (Участник № / Member № 707) on :
Мы собрали следующую схему: 1. Контроллер Octagon-6030 c МикроМРВ (mrt86_n.exe), 2. Три модуля I-7520, подключенных к COM-2,3,4 контроллера 3. Еще один модуль I-7520, подключаемый попеременно к линиям RS-485 вышеозначенных модулей и по RS-232 к COM-порту компьютера с программой HiperTerminal
Узел МикроМРВ настроен на использование COM-2,3,4 на скорости 115Кбит. Созданы каналы обмена данными с модулями I-7017 и I-7052, по паре на каждый порт.
Эксперимент выявил следующее: 1. Если период пересчета узла равен 100мс (10-период, 0,01-разрешение), то запросы на порт COM-2 идут стабильно, на порты COM-3,4 вообще не идут. 2. Если период пересчета узла равен 1с (100-период, 0,01-разрешение), то запросы на порт COM-2 идут стабильно, на порты COM-3,4 идут с задержками, пропусками, наложениями следующих друг за другом запросов. 3. С дальнейшим увеличением периода ситуация на меняется. 4. При исключении порта COM-2 (обнулили настройки), COM-3 начинает работать стабильно, COM-4 по прежнему плохо. 5. При исключении порта COM-3, COM-4 начинает работать стабильно.
Таким образом, стабильно работает только младший из назначенных портов.
Почему так происходит?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Одно из основных требований работы СОМ-портов в режиме Мастер под Микро МРВ - это то, что они должны быть настроены на одно прерывание! Поэтому у Вас и не работали 3-й и 4-й СОМ-порты до тех пор, пока не Вы не отключили СОМ2.
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
При использовании платы расширения СOM-портов Octagon5554 запросы пошли по всем трем (необходимым нам) портам, однако только, если период пересчета базы = 1 сек. При периоде = 100мс обмен идет только по первому порту. (Промежуточные значения периода не проверялись) При этом реально работал только первый порт (на нем восемь модулей), а по двум другим лишь фиксировались запросы от контроллера. Всего модулей в системе 48, таймаут = 100мс.
Можете ли вы сказать, как в такой ситуации правильно выбрать период пересчета и как он влияет на обмен по последовательным портам?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Обмен по последовательным портам производится асинхронно относительно пересчета базы. Поэтому идеально - это подвести пересчет каналов под пропускную способность канала связи и характеристикам устройств. Т.е. - выровнять поток транзакций, которые генерирует сервер ТМ по количеству транзакций, которое может обработать канал связи. Последний параметр - зависит от типа протокола, скорости связи, а также от динамических характеристик опрашиваемых устройств. Необходимо также обратить внимание, что в ДОСе сервер также занят обработкой СОМ порта, что снижает его динамические характеристики по мере увеличения количества этих портов.
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
Не хотите ли вы сказать, что если повесить мои 48 модулей на один порт, то обмен будет происходить быстрее, чем если разнести их по трем портам?
И второй вопрос: отрабатывается ли канал RS-reinit под МикроМРВ? Дело в том, что при попытках его использовать, обмен по соответствующему порту прекращался на неопределенное (возможно ввиду моей нетерпеливости) время.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) Не исключено, попробуйте разнести их хотябы на два СОМ-порта. 2) Да - данный канал должен работать по Микро МРВ. Какое значение Вы посылаете в данный канал, и кааким номером порта Вы управляете?
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
Ну, честно говоря, уменьшать количество используемых портов мне не хочется, т.к. у меня три панели с I-7000, одна или две из которых будут работать на другой скорости, а во вторых у маня щас в контроллере 8 портов (4 на Octagon6030, с которыми TM не может нормально работать и 4 на плате 5554), и если из них я буду использовать лишь два, то это уж будет просто издевательством. В канал RS-reinit посылаю для COM1 - 1, для COM2 - 2 и так далее сроком на один период пересчета. Обмен по порту прекращается и не возобновляется в течение нескольких минут (больше ждать не стал, т.к. быстрее контроллер перегрузить). Вчера я собрал свою систему полностью. То, что я наблюдал было похоже на бред... Итак, 1. используются порты 2,3,4 платы 5554 (общее 6-е прерывание, адреса 0х108, 0х110, 0х118) в режиме RS-232 через I-7520; 2. все таймауты по умолчанию, период узла 1 сек. (реальное время пересчета 220-275 мс), скорость обмена по 2 и 3 = 115кбит, по 4 = 38кбит; 3. обмен по порту 2 идет стабильно, по 3-му на одном модуле проскакивает недостоверность, по 4-му стабильная недостоверность по 4-5 модулям; 4. физически отключаем порт 3 - обмен по порту 4 становится стабильным без недостоверностей; 5. если вместо 3-го отключить 4-й порт, то по третьему недостоверность перемещается на другой модуль (хотя проявляется реже) 6. эксперименты с таймаутами или периодами пересчета ситуацию не улучшают .
Прокомментируйте пожалуйста... Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Если честно, издевательство - это нагружать так платформу с 8 СОМ портов на процессорный модуль Octagon6030, который имеет CPU 386SX/25Мгц (он даже без сопроцессора)! И Вы еще нагружаете его скоростями на 115.2 Kbps. Вы чем руководствовались когда выбирали данное CPU для своей задачи в 48 модулей DCS? Вы можете себе представить какой поток прерываний надо обработать Микро МРВ помимо собственных задач? Ну не успевает он на этом процессоре все эту "арматуру" опросить.
Есть решения гораздо мощнее и дешевле, сравните для примера: 1) Octagon6030 - стоит примерно 600-700$ 2) Wafer4823 - стоит примерно 250-300$ Причем последний также имеет 4 встроенных СОМ-порта, процессор 486DX/75Мгц. Гораздо дешевле и мощнее, причем уже реально используется нашими пользователями в сочетании с DCS-модулями. На базе данного модуля, например, построен контроллер "Теконик" компании ТЕКОН. А вот пример конфигурации узла контроллера на нем: реально используется 4 СОМ-порта - на одном сидят 10 модулей типа DCS на скорости 115.2, на другом текстовый терминал DK8070 (тоже на 115.2), на третьем СОМ - GSM модем, на четвертом СОМ - связь с верхним уровнем по M-Link. База на 400 каналов, много FBD. И все это работает с реальным циклом в 150 мс. Как видим - задел по мощности гораздо больше и больше потенциал, при почти вдвое меньшей цене!
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
Выбор был обусловлен тем, что данный контроллер с таким же объемом переферии работает у моих коллег вполне успешно, используя собственные СОМ-порты с разными прерываниями, ведя обмен с компьютером по TCP/IP и укладываясь в одну секунду. Единственное отличие в программном обеспечении. Вы же утверждаете, что обмен по COM-портам идет асинхронно - так и пусть он идет своим чередом! Почему же он спотыкается то на последних портах? Я уже не говорю, что МикроМРВ должен все модули за один период опросить - пусть дольше, но ВСЕ и БЕЗ ошибок.
Я попробую снизить скорость, хотя в моем первом эксперименте это приводило к возрастанию числа ошибок.(но таперь же у меня отдельная плата с портами)
Кстати, Wafer4823 имеет только два COM-порта на прерываниях 3 и 4. (см. Руководство пользователя) И рабочая температура у него до 55 (у нас люди бывает при 50 работают, а уж про технику я молчу)
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Прошу прощения - ошибся, не 4823, а 4821. В том то все и дело, что у Ваших коллег в аналогичном решении собственное программное обеспечение наверняка только и занимается тем, что работает на эти порты и ничего больше. А Микро МРВ это не обработчик портов обмена, он ведь выполняет большое количество функций, таких как: пересчет базы каналов, первичную обработку данных, интерпретацию алгоритмов на FBD, обмен по внешним интерфейсам и прочие сервисные функции. Это же сложный универсальный комплекс, требующий определенных ресурсов.
Попробуйте снизить период пересчета узла, а также - будет полезно разнести каналы по разным фазам пересчета, это снизит нагрузку на сервер Микро МРВ.
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
Хочу искренне извиниться за вчерашний "наезд" - нестабильность работы двух СОМ-портов была вызвана исключительно моей невнимательностью. Случилось так, что эти порты оказались связанными по RS-485 и передавали в одну линию , да еще и с разной скоростью - естественно, тот что на 115кб работал стабильнее, чем другой на 38кб.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
![[А-а! / Eek!]](eek.gif)
![[Безумие / Mad]](mad.gif)
.![[Спокойствие / Cool]](cool.gif)
![[Улыбка / Smile]](smile.gif)
![[Вращающиеся глаза / Roll Eyes]](rolleyes.gif)