Регистрация | Последние сообщения | Персональный список | Поиск | Настройка конференции | Личные данные | Правила конференции | Список участников | Top 64 | Статистика раздела | faq | Что нового v.2.3 | Чат
Skunk Forum - Техника, Наука, Общество » АСУТП »
Тормоза из за сети !?

Версия для печати (настроить)

Новая тема | Написать ответ

Подписаться

Автор Тема:   Тормоза из за сети !?
Мимый
unregistered
написано 28 Января 2007 22:15  ПравкаОтветитьIP

Сам в АСУТП очень недавно, и попал я на это поле из АСУП (так уж получилось...). Есть кусок хозяйства портящий всю нашу малину... Имеется 7 штук DL450 работающих на один АРМ. 1500 тэгов. Проблема в общем то такая: очень большое время исполнения/отклика. Если работает один ПЛК - вроде все нормально, 2,3 - уже тормозит, все 7 - полная ж..а. Зависимость не линейная, но что-то похожее. Сеть 422. На АРМе стоит плата, как я понял 422->232 c одним каналом (портом? не, наверное все-таки каналом). Рядом с АРМ распаечная коробка в которой кабели от всех контроллеров соединяются (как я понял) по принципу Т-коннекторов, т.е. устройство пассивное. Я так понимаю АРМ ведет связь сразу со всеми ПЛК одновременно ну и... Есть ли какие маршрутизаторы, хабы, свичи или что-то похожее для 422? Или я в корне заблуждаюсь и проблема в другом?

MuadDib_guest
unregistered
написано 01 Февраля 2007 10:21  ПравкаОтветитьIP

422, я так понимаю - это RS422. То есть на АРМ у Вас 1 последовательный порт, через который, собственно, вся коммуникация и идет. Скорость обмена информацией через обычный последовательный порт, как правило, ограничена 115200 бит/с. При этом никто не отменял тормоза, связанные с временем отклика устройств. Обмен идет с каждым устройством по очереди. Отсюда и низкая скорость обмена.
Выхода три:
1) Увеличить скорость обмена на имеющемся оборудовании (возможно используется что-нибудь типа 9600, и оборудование нижнего уровня позволяет увеличить скорость).

2) Приобрести промышленную плату последоваетельного интерфейса с несколькими портами. Тогда можно раскидать устройства по портам платы и, возможно, увеличить скорость.

3) Приобрести модули типа serial device gateway (например, ADAM 4577 или ICP DAS 7188EX). Последовательные порты устройств нижнего уровня подключаются к модулю, сам модуль включается в Ethernet, таких модулей может быть много. ICP DAS имеет в комплекте виндовый драйвер, позволяющий создавать виртуальные COM-порты (т.е. модуль становится как бы удаленным последовательным портом АРМ), но в исходной комплектации 7188 RS422 отсутствует, надо докупать мезонинный модуль и проверять работу системы с ним. Мы 422й не применяли.

Вообще, не совсем понятно, зачем в Вашем случае нужен RS422. Раз все устройства висят на одном порту, не проще было бы использовать 485й интерфейс? И как вообще реализована связь с несколькими устройствами на RS422? Ведь по этому интерфейсу связь возможна только в режиме "точка-точка", ни о каких Т-коннекторах и речи быть не может. Возможно, у Вас все-таки RS485?

Павел Мощицкий
Member

Сообщений: 1808
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 01 Февраля 2007 19:13ИнфоПравкаОтветитьIP

MuadDib_guest
Со всем согласился бы, кроме замены 422 на 485. 422 - полнодуплексный, а 485 - полудуплексный (в классическом варианте). RS-422 быстрее.

pw
Junior Member

Сообщений: 18
Регистрация: Январь 2007

написано 01 Февраля 2007 20:52ИнфоПравкаОтветитьIP

Э.э.э.. А какова скорость обмена? Извините меня, то 1500 тегов по сети типа подобной чтобы нормально обмениваться, то какая скорость нужна? Режим обмена пакетный или по одной позиции гребет? Подозреваю, что пакеты очень дробленые. Заголовок пакета, тело, контрольная сумма.. Бр.р.. Кроме того, многие проги лево ошибки связи обрабатывают, зависая после каждого сбоя на десятки секунд.. Какова топология сети? Нельза ли её оптимизировать?

Добавление от 01 Февраля 2007 20:55:

По любому обмен таким количеством параметров по сети rs422 или 485 достаточно затруднен при большой распределенности контроллеров, так как высокой скорости связи достигнуть при сложной топологии невозможно. Какова скорость обмена, еще раз, извините, спрашиваю?

MuadDib_guest
unregistered
написано 02 Февраля 2007 05:38  ПравкаОтветитьIP

Павел Мощицкий
Согласен, 422й полнодуплексный, но у АРМ один СОМ-порт, а устройств нижнего уровня - 7 штук. Даже если RS422 можно заставить работать в таких условиях какими-то схемотехническими ухищрениями, выигрыш в скорости вряд ли оправдает риск возможных проблем. Другое дело, если на каждое устройство будет выделен отдельный RS422-порт. Тогда можно будет говорить о выигрыше в скорости по сравнению с 485м. И то не за счет полного дуплекса, а благодаря обмену с разными устройствами по отдельным портам. Т.е. в режиме "одно устройство - один порт" скорость 422го и 485го будет практически одинаковой.
С другой стороны, преимущество RS485 - простота в расширении и архитектуре системы. Схема связи в виде "звезды" из 7 лучей не всегда оптимальна и осуществима на практике. Кроме того, если в будущем придется добавить устройство нижнего уровня к существующей системе, с 485м будет гораздо проще.

Valera
Member

Сообщений: 574
Откуда: novosibirsk
Регистрация: Май 2004

написано 02 Февраля 2007 06:23ИнфоПравкаОтветитьIP

MuadDib_guest
но у АРМ один СОМ-порт
Надо полагать, что с 1 портом АРМ и может работать, в смысле 'одновременно'.

MuadDib_guest
unregistered
написано 02 Февраля 2007 08:12  ПравкаОтветитьIP

Valera

Пока автор ветки не "расколется" на предмет того, какие у него параметры железа, остается только предполагать.

pw
Junior Member

Сообщений: 25
Регистрация: Январь 2007

написано 02 Февраля 2007 18:50ИнфоПравкаОтветитьIP

Фигня все, если топология сложная типа "дерево", то сделать вообще ниче низя. Тока если проложить новые кабеля, что никто делать не будет. Самое верное решение следующее. Поскольку с железом сделать ниче низя (все уже сделано по самой дешовой схеме, а переделать жутко дорого), то надо менять ПО. То есть ставить ПО не слишком чувствительное к ошибкам. Иногда это называется "ПО корректно обрабатывающее ошибки связи".

bessonov2
Member

Сообщений: 66
Регистрация: Май 2006

написано 02 Февраля 2007 19:16ИнфоПравкаОтветитьIP

2Мимый
Посмотрите и подумайте насчёт MOXA NPort.

pw
Member

Сообщений: 33
Регистрация: Январь 2007

написано 02 Февраля 2007 21:26ИнфоПравкаОтветитьIP

Ниче не поможет. Ошибки надо просто маскировать и сразу опрашивать следующий узел.. Мозги не компосировать. Подумаешь. По отдельным узлам обновится не раз в секунду, а раз в 3 сек.. делов то. Это тот вариант, когда грамотное ПО может скомпесировать недостатки железа, я думаю.

Павел Мощицкий
Member

Сообщений: 1810
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 03 Февраля 2007 19:13ИнфоПравкаОтветитьIP

MuadDib_guest
Даже если RS422 можно заставить работать в таких условиях какими-то схемотехническими ухищрениями
А смысл. Тут нужно заставить быстро работать в одной сети.
если в будущем придется добавить устройство нижнего уровня к существующей системе, с 485м будет гораздо проще
А вот с этим соглашусь. И технически и финансово RS485 тянуть легче и дешевле.

pw
ставить ПО не слишком чувствительное к ошибкам
А как тогда диагносцировать постоянную ошибку?

pw
Member

Сообщений: 39
Регистрация: Январь 2007

написано 07 Февраля 2007 20:41ИнфоПравкаОтветитьIP

"pw
ставить ПО не слишком чувствительное к ошибкам
А как тогда диагносцировать постоянную ошибку?"
Просто мне кажется, что в таких случаях тайм-ауты должны определяться отдельно чуть-ли не для каждого прибора и не по каждому параметру связи. Ведь реально качество связи в сложных топологиях для отдельных узлов может быть разное, это факт. Оптимально настраивать обработку ошибок для каждого узла в отдельности, но такое малореально. Приходилось видеть, как стандартное ПО, наткнувшись на ошибку связи с отдельным узлом, делало продолжительный тайм-аут (не делая ничего), затем делало повторный запрос.. Наткнувшись на повторную ошибку делало повторный продолжительный тайм-аут и так далее. Хотя во время этих тайм -аутов можно было уже круг сделать по всем нормально работающим приборам. Такое ПО легко вычисляется по тому, что при одном неработающем приборе опрос всех приборов в сети резко замедляется, хотя при нормальном ПО этого недолжно быть. А теперь представьте, что приборы таки работают, просто ошибки часто? Представляете, как замедлится обмен ужасно? Я бы не возмущался, если бы такое ПО регулярно не встречалось. А вдруг у спрашивающего именно такое нехорошее ПО?

Павел Мощицкий
Member

Сообщений: 1818
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 08 Февраля 2007 18:53ИнфоПравкаОтветитьIP

pw
А вдруг у спрашивающего именно такое нехорошее ПО?
С этим соглашусь. Почти любой монитор сбора технологической иноформации (не путать с МРВ или АРМ-ом оператора) или технологическая SCADA, грешат этим.

pw
Member

Сообщений: 52
Регистрация: Январь 2007

написано 10 Февраля 2007 22:15ИнфоПравкаОтветитьIP

Собственно по сабжекту: полная попа. Афтор, ты влип.

bessonov2
Member

Сообщений: 84
Регистрация: Май 2006

написано 11 Февраля 2007 01:31ИнфоПравкаОтветитьIP

pw
То есть ставить ПО не слишком чувствительное к ошибкам.
Это интересный термин, особенно если вдуматься в его содержание Наверно это гиперинтеллектуальное ПО, которое может "придумавать" само для себя значение сигнала с датчиков?

Иногда это называется "ПО корректно обрабатывающее ошибки связи".
Т.е., ПО которое не может "придумать" само для себя корректное значение датчика можно назвать как "ПО корректно обрабатывающее ошибки связи"?

Добавление от 11 Февраля 2007 01:33:

pw
Приходилось видеть, как стандартное ПО, наткнувшись на ошибку связи с отдельным узлом, делало продолжительный тайм-аут (не делая ничего), затем делало повторный запрос..
Где же вы сумели найти такое ПО? Не очередные дешёвые платы от Tricon?

pw
Member

Сообщений: 76
Регистрация: Январь 2007

написано 05 Марта 2007 20:24ИнфоПравкаОтветитьIP

pw
Приходилось видеть, как стандартное ПО, наткнувшись на ошибку связи с отдельным узлом, делало продолжительный тайм-аут (не делая ничего), затем делало повторный запрос..
Где же вы сумели найти такое ПО? Не очередные дешёвые платы от Tricon?
К сожалению такое ПО производит в основном российский производитель. Я специально не уточнял, а вы зря про это спросили. Почти все российское ПО именно так и написано. Его пишут полушкольники едва научившие толком применять и скачивать с Инета компоненты Дельфи. Лажа, халява и дерьмо. Как патриоту мне это противно.

Иногда это называется "ПО корректно обрабатывающее ошибки связи".
Т.е., ПО которое не может "придумать" само для себя корректное значение датчика можно назвать как "ПО корректно обрабатывающее ошибки связи"?

Если бы вы дали себе труд хоть раз написать корректную программу, работающую с железом, то не задавали бы таких глупых вопросов. Имеется ввиду драйвер или чо-то подобное. Очень важно обрабатывать ошибки адекватно. Большинство прохих программ именно потому и плохие, что ошибки и сбои железа нормально не обрабатывают. Это истина. Писать обработку ошибок очень тяжело и это занимает 80% программы. Халявщики этим пренебрегают. В программе-оболочке очень важно обработать все ошипки пользователя, в программе, работающей с железом, очень важно обработать все ошипки железа адекватно. Просто формальный обмен по протоколу не проходит. Увы... Надо таки знать, как транзистор работает, если пишешь драйвер.

[Это сообщение изменил pw (изменение 05 Марта 2007 20:42).]

Ваш ответ:

Коды форума
Смайлики


Ник:    Пароль       
Отключить смайлики

Все время MSK

Склеить | Разбить | Закрыть | Переместить | Удалить

Новая тема | Написать ответ
Последние сообщения         
Перейти к:

Свяжитесь с нами | skunksworks.net

Copyright © skunksworks.net, 2000-2018

Разработка и техническая поддержка: skunksworks.net


Рейтинг@Mail.ru Яндекс.Метрика