У меня странная ситуация, год назад создал проект для мониторинга процессов на предпрятии, RTM и NLL. NLL соотвественно привязан к RTM. Так как прогресс на предприятии не стоит на месте, возникла необходимость расширить число опрашиваемых каналов. Все как бы получилось, в МРВ добисал/добавил новые атрибуты, тоже самое в консоли. Запускаю, и вот оно: МРВ все корректно показывает, поключаемая консоль показывает не все. Привязки в проекте все одиновые, обращаются в одно место. В консоли "Дествия"->"Привязки экрана" вижу что не все необходимые аргументы имеют привязку!
Пробовал создавать новый экран в консоли, заного привязывая все аргументы, не помогло. Пробовал использовать 1 шаблон, не помогло.
Возможно в CALL необходимо какой параметр забить?! Или есть ограничения по опрашиваемым атрибутам из МРВ?! Хотя добавлял новые каналы и атрибуты, они корректно отображаются, а какие необходимо нет!
Кто сталкивался с проблемой данного характера, подскажите пожалуйста, а то уже... Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Присылайте Ваш проект на hotline@adastra.ru со ссылками на наблюдаемые параметры, которые "не привязываются". Укажите при этом, в каком релизе разрабатывался проект и в каком релизе он модифицируется.
Posted by Shahmatist (Участник № / Member № 5388) on :
Отправил, за ранее спасибо!
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Из документации “Распределенные АСУ/Конфигурирование межкомпонентного взаимодействия/Связь через аргументы”: “Связь ’аргумент – аргумент’ В ОДНОМ узле разрешена привязка аргументов канала CALL к аргументам другого канала CALL, ...”
Связь “аргумент-аргумент” между узлами не декларирована!
В качестве неявной компенсации такого ОШИБОЧНОГО решения в проекте в некоторых случаях включается подмена связи “аргумент-аргумент” между узлами на связь “аргумент-атрибут” с номерами атрибутов, начиная с 140. Однако эта поддержка весьма ограничена.
В Вашем конкретном варианте целесообразно заменить бинарные сигналы из программы передачей соответствующих упакованных сигналов в каналы HEX32 и передачей на экраны упакованных сигналов с последующей сигнализацией при помощи индикации типа “Arg & Конст.”.
Кроме ухода от описанного ограничения Вы при этом получите существенное сокращение трафика между узлами, поскольку вместо нескольких десятков запросов битовых сигналов Вы будете иметь 2-3 запроса значений каналов HEX32 или HEX16.
Posted by Shahmatist (Участник № / Member № 5388) on :
Спасибо за помощь, пошел учиться и переделывать!
Posted by Shahmatist (Участник № / Member № 5388) on :
Доброго дня всем!
Если можно вот еще вопрос.
Допустим я хочу считать с контроллера (ОМРОН CPU65, по Ethernet)примерно 500 слов по 16 бит, при этом каждый бит несет свою уникальную информацию, т.е. я буду показывать на экране состояние каждого бита. 1. Как рациональнее это сделать, в плане быстродействия? (1 цикл программы в контроллере не более 5 м/сек) 2. Есть ли возможность не испольховать все 500 каналов, в плане экономии?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. Оценка необходимого быстродействия определяется не циклом программы в контроллере, а реальными длительностями контролируемых сигналов в каждом из считываемых слов, реактивностью контроллера при ответах на запросы. Если контролируемые сигналы короткие, видимо, следует стремиться к возможному уменьшению цикла обработки базы каналов. Очевидно, что при всех условиях гарантировать мониторинг и отображение сигналов, которые имеют длительность меньше 10-11 мс (для Windows XP и Windows 7) нельзя. Цикл опроса сигналов контроллера в принципе нельзя сделать меньше. Короткие сигналы отображать на экране тем более невозможно. Можно только пытаться их архивировать для последущего просмотра, обработки и/или документирования. Фиксация временных меток в любом случае будет осуществляться с периодом обработки базы каналов узла.
2. Если все 500*16 дискретных сигналов независимы, то сэкономить на количестве каналов, опрашивающих контроллер, нельзя. Можно только пытаться интегрировать/обрабатывать информацию в контроллере с тем, чтобы была возможность сократить объем информации, подлежащей мониторингу на верхнем уровне.
Posted by Shahmatist (Участник № / Member № 5388) on :
![[cry / плачь]](graemlins/cry.gif)