Алексей писал(а):
Ну я, например, после Sysmac Studio с радостью вернулся к Cx-Programmer. Более человечной среды не встречал еще.
"А если еще проникнетесь всей мощью PIDAT c настройкой за 5 минут" - опыт показал практическую бесполезность данной функции.
Про опыт поподробней можно... А то ведь он разный бывает. У меня программисты в конторе 15 лет что то писали на Cx-Programmer. Я вообще программированием не занимался.
Не по своей воле пришлось доделывать то что профессионалы не смогли. Погрузился ... изучил и... запустил. Врят ли есть альтернатива PIDAT (это двойной ПИД, запатентованный Омрон, который может очень быстро реагировать на задание и не реагировать на возмущения со стороны системы, если уж совсем просто...Этим он и отличается собственно). Понятно что при изменении свойств механической или гидравлической системы, нужно перестраивать на лету коэффициенты, диапазоны регулирования и т.д. В итоге сложный испытательный стенд (испытываем шину на разрыв на 300км/час) отлично отрабатывает заданную нагрузку в очень широком диапазоне регулирования с точностью до 0,015%...Держу простым распределителем, нагрузка гидроцилиндр с низким трением. Видел зарубежные аналоги... Сервогидравлики наперто столько что страшно. А нужно всего лишь разобраться с PIDAT(20стр текста, или сейчас уже посмотреть видео) У моих бывших программистов с большим опытом не получилось...В том числе и на предыдущих таких работах...Сейчас тоже хают на новый контроллер небось))). И на плохого руководителя. Но каждому свое. "Кто не хочет - ищет причины, кто хочет - возможности.
После одной такой доделки за профессионалами стало очень быстро понятно что так писать программы нельзя. Задумался...а как пишут программы там где нет возможности исправлять. К примеру стратегические объекты. Теперь все по классике парадигмы автоматного программирования. Пишу модель объекта, потом автомат управления, все отлаживается, согласовываются алгоритмы с технологами и главное софт не мертвый!!! Потом задача с моделью отключается и подключается живой объект управления. И программа вся верифицирована. И я могу это доказать!! Мне до сих пор все говорят что только на объекте можно доказать работоспособность софта... Но ведь уже все давно придумано. Но профессионалы есть профессионалы...А самое интересное, что любая программа на 20% состоит из правильной работы оборудования и остальное возможные аварийные ситуации, т.е. все!!! Должен быть однозначный детерминизм если так можно выразиться...Вот поэтому приходиться имитировать все возможные ситуации. Но в ТЗ конечно этого нет и типа это зона ответственности не разработчика...А если еще и программист уволится, который писал без определения всех состояний объекта, то это уже мертвый софт... Проще заново написать. И это было бы смешно если бы не было так грустно...Короче итог: Детерминированный структурный автомат Мура второго рода наше все (для ST, для LD тип не имеет значения))) И если это сложное наречие перевести в простое понимание с примером, то все скажут: Боже это же так просто!!!
Так что с опытом нужно аккуратненько))).
Теперь понятны аварии на объектах, прошедшие и будущие... Явно на Саяно-Шушенской ГРЭС разработчик уж "точно описал" состояние аварии при возникновении аварийного уровня вибрации турбины, когда один болт крепления основания (изготовленный не из той стали) вырвался и пошло разрушение. Просто в ТЗ проектировщик этого не предусмотрел. Это же ведь невозможная ситуация высокооборотистого зверя. До верификации программного кода дело так и не дошло. А при чем тут программист???. Проектировщики предполагают что эти умные (программеры) все сделают, у них ведь опыт, а программеры что им написали, то и положили в свой (простите за выражение) го-код. Так и движемся к концу света. Со своим уверенным опытом предыдущих разработок.
А вообще CX-programmer, Sysmac Studio или любая другая IDE не важно - важно качество софта и его открытость, поддерживаемость, верификация и безопасная работа людей.
На сем и откланяюсь.