Переменные в Modus Slave - это действительно слабое место, в них можно запутаться (хотя мы сделали так, что они скрыты в коде и трогать их нет никакой необходимости). А вот переменные, по названию которых понятно какой вход/выход какого прибора за ними стоит - это удобно. Удобно в проектах, описанных мной в посте, т.е. однотипных.
У нас почти сотня объектов (а на очереди ещё две), которые отличаются количеством датчиков, частотников, КЗРов, ..; и все они на каждом объекте подключаются к разным входам/выходам. Поэтому я написал программу, которая описывает максимальный набор всех устройств, и вывел код, отвечающий за соответствие входам/выходам этих устройств, в одно место. Т.е. я беру принципиальную электрическую схему шкафа управления, смотрю, что температура ГВС сидит этом входе, авария этого насоса на этом, открытие КЗР на этом выходе и т.д. и прописываю это в коде, а лишнее удаляю.
Практика показала, что подобные действия в конфигурации занимают на порядок больше времени и вызывают массу неудобств. Плюс к этому я везде использую массивы, структуры, и даже массивы структур, которые содержат массивы и структуры. Кстати, под структурами я понимаю ещё и функциональные блоки (к которым можно добавлять действия, т.е. делать инкапсуляцию, что превращает ФБ в почти-класс; в общем - советую). Так, что в моей программе без подобной конфигурации - никак. Хотя, возможно я слишком категоричен и где-то ошибаюсь...
Для одиночных проектов - создание промежуточных переменных действительно бывает излишним (если, конечно, нет необходимости создавать массивы или структуры входов/выходов). Иногда так и делаю, как делаете вы, Жекон.




. Кстати, под структурами я понимаю ещё и функциональные блоки (к которым можно добавлять действия, т.е. делать инкапсуляцию, что превращает ФБ в почти-класс; в общем - советую). Так, что в моей программе без подобной конфигурации - никак. Хотя, возможно я слишком категоричен и где-то ошибаюсь...
Ответить с цитированием