Можно скрипт написать свой, либо спросите у техподдержки.
Можно скрипт написать свой, либо спросите у техподдержки.
Не вытерплю, выскажусь.
ИМХО
Можно работать и с DWORD. Распаковывая по 32 бита.
Можно и с отдельными битами. Со всеми 639 сразу.
Можно, но не нужно.
Во первых, будет очень не удобно просматривать на мониторе иерархию. Разве что там монитор метр на два.
При связывании сигналов надо будет постоянно скролить. Очень неудобно и отнимает кучу времени.
Проект становится трудно читабельным.
Во вторых, лично мне, удобнее когда адресация регистров идет по порядку, а не через один. Спасает от ошибок.И при наладке проще.
В третьих, обычно регистры привязываю к оборудованию. К примеру есть установка № 1 с 26 дискретными сигналами. И установка № 2 с 12 дискретными сигналами. Соответственно для установки № 1 - 2 регистра. Для установки № 2 - 1 регистр.
Соответственно в скада два объекта с названием "Установка №1" и "Установка №2". Куда соответствующие регистры и распаковываются.
Отсюда и вывод, работа с переменными WORD оптимальна.
И вопрос к OverGrow , почему выбор пал на MasterScada4D?
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда. (Закон Линуса)
Тоже не утерпел )) Почему WORD ? Оптимально STRING(1000) (ниже)Сообщение от smk1635
Зачем это кроилово - тут 1, тут 2 ? Если объекты можно обобщить, но одному нужен будет бит №100 - да не вопрос. Всем объектам по 8 регистров. Даже тем кому нужен только один и его №0. Верхний уровень по TCP ж ? Какая проблема прочитать 125 регистров за раз ?
Не понимаю глубинного смысла в типах для слейва. Это просто область памяти. Был бы стринг, сразу забил бы туда стринг(1000). Какие-то регистры, индексы. Зачем ? Объявил с двух сторон эквивалентные структуры, натянул структуру на стринг и вперед. Да и перетащить проект на другую платформу - секунды.
Как-то давно в слейве подержал контрол-V секунд 10, наколотил в слейв несколько сотен "4 byte", экспортировал и забыл. Только импортирую в каждый новый проект и не парюсь.
Прочитать ни каких проблем.
Дело в Scada. Иерархия построения объектов древовидная. Очень тяжело читается большой объем одинаковых сигналов. По этому чем меньше, тем лучше.
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда. (Закон Линуса)
Если OPC Codesys, то и конфигуратор не нужен. Вообще Slave лучше через библиотеку делать, конфигуратор не удобен при большом кол-ве переменных.
Ваши права
Ответить с цитированием