Здесь дело не в этом. Я имел ввиду совершенно другое - в LabVIEW принято (ну исторически так сложилось), что у инструментов входы располагаются слева, а выходы - справа, и поток данных идёт слева направо. Так рекомендуется делать. Конечно, никто не запрещает перевернуть всё с ног на голову, что в тулките и было сделано (и по другому там и не получилось бы).Jakob Brontfeyn писал(а): Я вообще то, считал синтез контактных планов, помимо логических диаграмм, своим большим достижением...
Приведу для лучшего понимания примеров, принципиальные схемы, чисто электротехнические,
управления пускателями обычным и реверсивным (с простой и более сложной блокировкой)
Если они тоже не понятны и приводят в ступор, ну тогда это точно проблемы работы на стыке областей,
я априори считал, что даже не подготовленный LV-программист, это все таки, как то подготовленый:
электрик, электроник, другой специалист, почему должны быть проблемы с восприятием не сложной электрической схемы
Однако элементы типа Hi|Lo, где выходы сделаны направо и налево - они просто идут в разрез с идеологией LabVIEW. Это как бы "притягивание за уши", что ли. Хотя выглядит, конечно, забавно (мы даже в одном из топиков электрическую схему для снятия ВАХ диода набрасывали).
Вы, кстати, не первый, кто так делает. Лет пять назад из недр NI Labs вышел проект под названием "Ladder Editor". Он был сделан для версии 8.6, после чего тихо скончался. Так вот там можно было создавать диаграммы в соответствии со стандартом EN 61131, но идеология была чуть другая - там не ставилась задача привести блок-диаграмму в визуальное соотвествие с контакным планом. Вместо этого был использован Picture Control, на котором собственно и происходило создание Ladder-диаграммы. В результате этот редактор не вступал в конфликт с идеологией LabVIEW (хотя сложность этого редактора была на порядок выше, чем в ПЛК тулките), просто следовал стандарту, принятому для диаграмм такого рода. Сложно сказать, почему проект закрыли. Один из аргументов, насколько я помню, заключался в том, что в традиционном ПЛК я могу менять код, не останавливая контроллер, чего я сделать не могу в случае лабвьюшной симуляции. Ну и Picture Control - довольно тормознутая штука для такого рода интерфейсов.
Что касается конструктивных усовершенствований, то первое, что там напрашивается - сделать систему тэгов для входов/выходов. В том виде, в каком оно есть сейчас, программист должен помнить, за что отвечает каждый выход и снабжать диаграмму соответствующими комментариями. Вместо этого надо дать возможность обращаться к точкам доступа по именам (собственно так в любом ПЛК сделано - будь то Siemens или GE Fanuc). Если точек доступа будет несколько десятков - то работа с этим инструментом превратится в ад.
Также можно предусмотреть мостики к реальному железу. Конечно, ничего специфического добавлять там не нужно, но хотя бы добавление поддержки OPC через DataSocket и ModBus уже даст возможность использовать тулкит на реальном железе.
Ну и состояние гонки пофиксить, конечно - ибо в таком виде пользоваться тулкитом вообще нельзя.