К сожалению по созданию контроллеров нет ни одной книги...
Тема закрытая и только тыком и предыдущим опытом.
Есть общие практики программирования, но всему свое место - если есть продукт то придерживаясь стандартов вы можете сделать его стабильнее или удобнее для поддержки, но если вы даже не знаете с какой стороны подойти все намного сложнее.

Все мы в какой-то степени самоучки, другие здесь не ходят, но не на этом акцент. Просто есть вещи, которые уже пройдены до (и лучше?) нас. Может просто "прочитать инструкцию"? Меня в свое время этот букварь так нормально перестроил.

Вы все-же преувеличиваете.
Вот, с полки взял: О.И.Николайчук, Системы малой автоматизации, 2003.

Конечно, найти книгу где было бы все по созданию контроллера, от и до трудно, но по отдельности вся необходимая информация определенно в книгах есть.

Что значит создать контроллер? Надеюсь вы не имеете ввиду создать сам микроконтроллер - сердце почти любого электронного устройства. Этим занимаются мировые гиганты электроники не один десяток лет. Все что вы можете, это выбрать микроконтроллер исходя из цены и необходимых характеристик. Дальше берете среду программирования для выбранного контроллера и пишите почти с нуля программу. Поверьте, каждый полупук придется создавать самому. Примеров почти нет. Вернее они есть, но это в основном или намеки или откровенный мусор.

Есть ГОСТы 19-й серии, есть госты по программированию ПЛК, есть ГОСТы по функциональной безопасности. Не скжу, что там прямо всё рассказано, но знать и хотя бы некоторые требования выполнять надо. Если Вы этого не знали, то не являетесь специалистом в области программирования, по моему ИМХУ. Впрочем, таких горе-автоматчиков полно.

Тогда уж горе-программистов.)

Честно говоря от вас, kosmos440o, не ожидал такое услышать, думал вы имеете к программированию непосредственное отношение. Тогда должны понимать, что чтение гостов лохматых годов ни на миллиграмм не поможет разобраться в том как эти самые микроконтроллеры программировать.

Написать рантайм это еще только треть (в лучшем случае) пути - надо же еще написать либо программу для PC чтобы все это запрограммировать и сделать несколько приложений для контроллера чтобы понять как это улучшить , а дальше следующая итерация. Ну и еще написать некоторое количество документации не говоря о тысячах часов тестирования.
В чем то конечно параметрические контроллеры проще - возможно не надо прогу для PC, но зато требования к встроенным приложениям жестче.

Мы пошли другим путем - есть встроенные программы которые можно выбрать с пульта или web интерфейса или можно написать прогу и загрузить самому, если что то не устраивает

Различайте стратегию и тактику. То, что Вы должны набросать квадратиков по полю программы и соединить их особым образом - это тактика. А то, что после себя надо оставить инструкцию по эксплуатации - это стратегия.

и комменты в тексте проги. Которых порой должно быть больше, чем кода. Иначе через месяц не подойдешь, а через полгода легче будет новую написать

Не могу не согласиться. Фактически инструкция должна писаться параллельно с разработкой устройства, а частично и вперед как часть ТЗ. Ибо как задумаешься как некоторые вещи понятно объяснить в инструкции, так понимаешь, что проще в программе это поправить, чтобы более логично и понятно расписать в инструкции. Естественно это в первую очередь относится к интерфейсу пользователя. Здесь, конечно, рулят графические дисплеи. Только с их помощью можно практически без использования текста на интуитивном уровне донести до пользователя всю информацию.




Без комментов программа почти не имеет смысла. Можно сразу в бинарник перевести а исходник выбросить)

Дак вот это в гостах и написано, просто на другом уровне подаётся. Более того, инструкция - это индикатор того, что программист сам понимает, как работает программа.

Рассмотрим ещё один случай.
Открываю программу, вношу вредоносный код случайно или намеренно, компилирую, прошиваю, закрываю программу.
Вопрос: Какова вероятность возможности этого случая?
Ответ: 100%
Вопрос: Как с этим бороться?
Ответ: Нужен комплексный подход, рекомендация необходимых (но возможно, недостаточных действий):
1. Полное тестирование программы при всём диапазоне всех входных переменных. (код, реагирующий на время "через год", не будет найден при этом)
2. Открытый исходный код. Пользователь должен иметь возможность просмотреть листинг программы. (Здесь подразумевается конечный пользователь).

Вопрос: Кто несёт ответственность за некачественную программу в ПЛК?
Ответ: В местечковых системах, как правило, никто. Крупные производители рискуют репутацией (ответственность за ущерб, как правило, декларативно снимают). Мелким производителям потеря репутации не так страшна, так как они работают с адресным клиентом и найти очередного лоха для них не такая проблема.

Правильные рекомендации к вышеописанному есть в гостах.

Кому деньги платили, тот и несет.

Даже спросить стесняюсь, а программист может не понимать, как работает программа? И что это за программист, если не секрет? И кто тогда истинно понимаетт?

Контроллер все понимает.


Что-то у вас пробелы в области статистики и теории вероятностей.


То-то я и смотрю - ко всем параметрическим контроллерам производители выкладывают листинги программ.

Одно вытекает из другого. Только имея исходный код можно внести изменения в программу. В бинарник почти невозможно внести какие либо изменения. Разве что одну надпись на другую поменять.

Никто не будет выкладывать исходники, на которые потрачены месяцы, а то и годы упорного труда. Все что выложено это или мусор или намек на то как надо делать.

Хм... Вот незадача... А я то думал, что программист, прежде чем писать программу, должен понимать контроллер, для которого пишет. Не? Вот и думаю, а не муйней ли я занимаюсь всю жизнь, пишучи программы для всего, что ни попадя.

Фишка в том, что хороший технолог и хороший программист это не всегда одно и то же лицо. Это идеальное сочетание встречается довольно редко, чаще всего процесс распределяется между двумя авторами. Тут собака и порылась, программист, воплотив чужие идеи, считает себя автором. Это правильно?

Это абсолютно правильно. И пока я не вникну в детали процесса, как правило гораздо лучше, чем некий технолог, я программу делать не буду.

И совсем непонятно почему инженерам навязывают программирование. Ну не найден продходящий спрограммированный контроллер. Берем простейший СПК, программируем Не на С++, а на ФБД, языке понятном любому инженеру. С полным пониманием управления процессов еще на стадии рисования эл.схем. И вообще, о чем базар? Можешь программировать - программируй. Постоишь, поналаживаешь программу в неотапливаемом помещении, где-нибудь на выезде, сам поймешь что лучше.

Вы тут понапишете, а они все как кинутся программировать, за уши не оттащишь

Точно-точно. Мы же знаем, что программист приходит на объект, с важным видом включает ноутбук. На экране появляется огромная кнопка "ПУСК". Нажимает ее и вуаля - все работает. Делов-то.)))

Должен ли программист знать алгоритм управления объектом или ему это должен дать технолог ?

Скорее всего, после вопроса технологу получите встречный вопрос - "Ты это сейчас с кем разговаривал"?

В таком случае , кто должен знать алгоритм управления объектом ?

Ой ли? Смотря какой процесс Для начала "Свойства жидкостей и газов " Р. Рида почитай. И т.д. и т.п.

Даст технолог "ему", или не даст, но программист знать должен. И это априори от желаний технолога не зависит. Иначе никакой вразумительной программы не получится.
А что касается вопроса коллеги libra - Ой ли? Ответ: ой ли!

Должен. Сегодня слышал "битву экстрасенсов" по удалению дымовых газов.

Если технолог не знает, то откуда может знать программист.

Большинство толковых КИПовцев, АСУТПшников и программистов знают алгоритмы управления объектом и последствия отклонения от них лучше, чем технологи. И, после увольнения технолога, часто устраиваются работать на его место, если там платят больше (а там платят больше). Ещё бывают бестолковые вышеназванные работники, но они на производстве обычно долго не задерживаются, до второй-третьей аварии по их вине.

p.S. Толковый программист 1С обычно знает бухгалтерию на порядок лучше главбуха и аудиторов. Но бухгалтером работать не станет.

Это , если программисту известен объект управления, а если неизвестен.

Если технолог не знает процесса, которым управляет, такого "технолога" смело можно удавить. Во-первых, кому нужен такой технолог, а во-вторых - какую программу можно написать, не зная процесса? Может подскажете пример таких удачных программ, а то я не знаю.

Alexander_I, утверждая, что программист должен разбираться в технологии лучше технолога Вы принципиально ошибаетесь. Если следовать Вашей логике, то тогда и технолог должен в совершенстве знать, например, теорию конечного автомата ну или матричное исчисление. Технолог должен уметь алгоритмизировать процесс, проще говоря - объяснить, что он хочет. Вот с этим и есть проблема. А пытаться самому сесть на 2 стула - результат понятен. Повторюсь, хорошо, если технолог как любитель сможет запрограммировать что-то там, но еще лучше, если он остановиться в своих дерзания (на FBD) и займется своим делом. А математику оставит для дома, для семьи, ну или займется ею с прицелом на будущее. Знаете, что такое Т-специализация?

Программист может математику не знать, не придумает же он математическую формулу, которой описывается управление объектом. Появляется еще один специалист - математик.

Если вместо программиста тупой кодировщик, который переводит в строчки программы алгоритмы, предоставленные ему кем-то, то так и есть. Однако, в последние лет 15 не видел ни в одной организации (разработчике систем управления) ни разу ни неких алгоритмистов, ни кодировщиков, ни прочей хлебояди. В советское время - видил, и было их, как говорил Матроскин, ну просто завались.

Ну откуда программисту знать алгоритмы управления, например летательным аппаратом, если их не знает (!!!) , специалист авиаконструктор

Понятно. Значит за программиста программу пишет "технолог летательных аппаратов". Результат широко известен.

Авиаконструктор не знает как управлять, а программист знает. Оч. оригинально.

А мысль не приходит в голову, что авиаконструктор знает еще много чего, кроме как управлять, а программист просто обязан знать, как управлять, и должен знать еще много чего, что не знает авиаконструктор? И тогда что-то получится. Не?

Программист не имеет специального образования по летательным аппаратам, т.е. если что-то и знает, то на уровне дилетанта. Причем его знания в аэродинамике никто не проверял.
Т.е. управлять летательным аппаратом у вас будет дилетант.

Программисту, который не имеет специального образования по летательным аппаратам, нельзя доверять написание программы управления летательным аппаратом. Для него есть должность кодировщика, а программист и тестировщик потом вместе проверят, чего он накодировал.
Для того, чтобы стать программистом АСУТП, я на первом курсе изучал языки программирования, а на четвёртом курсе среди прочих предметов теорию автоматического управления и машины и аппараты химических производств.

хотьпоржал.
Я Вас уверяю, коллеги, программирующий технолог это человек, который на данный момент еще не определился со своей профессией. В одной из них он любитель. Ну или от нищеты конторы. Тем более не убедите меня в том, что написанная хорошим технологом с задатками программиста хорошо работающая программа уже является программным продуктом, за который можно брать деньги. Стопятьсот раз предлагалось резать аппендицит самому, чет желающих немного.. А давайте еще всех программистов обучим всему, чтоб во всем разбирались, чтоб и бухгалтерию, и траекторию, и... да все могли! Прям так и хочется Лаврова процитировать. Да пустой это разговор, ежу понятно, что попытки скрестить его с ужом бессмысленны. Технологи! делом займитесь и научитесь четко формулировать свои идеи. Можете даже на FBD, если свербит. Извините, если кого обидел, не хотел.

Авторитет программиста , понимающего в технологии много выше, чем не понимающего.
Осталось преобразовать авторитет в репутацию мегамозга и зарплату, что с успехом и делается.
Главное побольше таинсвенности и значимости нагнать, чтобы технолог даже пикнуть не мог, без учета мнения программиста или например киповца,
смотря по обстоятельствам.

Если мне предложат на выбор две программы, одну написанную профессиональным технологом, но программистом-дилетантом, а вторую профессиональным программистом не знающим технологии, я выберу первую. У неё будет много недостатков по сравнению со второй, но будет и одно достоинство - она будет работать. Мысль, кстати, не моя, я её позаимствовал у замечательного электронщика, программиста и технического писателя Юрия Ревича. Всем рекомендую его книги по программированию и электронике.

чудак Вы, WRybkin. Вы и всерьез считаете, что программист без технолога полезет писать управление процессом? Ну-ну..

вы все ошибаетесь.
между технологом и программистом находится человек, который называется системным аналитиком.
он получает данные от технолога, проктолога, невролога и прочих сведущих людей и ставит/пишет задачу для программиста.
но! системным аналитиком может быть и технолог и программист, при наличии у них соответствующих навыков и умений.
у русских/советских людей так повелось что функции системного анализа в большинстве случаев выполняет программист.
но это скорее исключение чем правило для всего остального мира

Жестко !
Но участники дискуссии не дилетанты,
поэтому скорее всего мы все находимся в ситуации "слепые ощупывают слона"
и каждый его описывает по-своему.

Но, ИМХО, можно и нужно опираться на две аксиомы:
1. программист переводит алгоритм управления системой, заданный технологом,
на язык, понятный микроконтроллеру, контроллеру, компьютеру
для автоматизации процесса управления системой.
Грубо говоря, программист автоматизирует процессы, которые технолог делает вручную,
например, при повышении температуры на таком-то термометре выше заданного значения -
закрывать такой-то вентиль, до тех пор, пока температура на этом термометре не достигнет значения такого-то.

2. В нашем АВОКе (в отличие от общего АСУТП) большая часть процессов одинакова от объекта к объекту.
Например, управление водяным калорифером, или поддержание давления в воздуховоде или сблокированная работа
приточки и вытяжки. Поэтому через некоторое время опыта программист может обходиться без описания процесса
от технолога, потому что процессы одинаковые и решения уже есть. Таким программистам описания нужны только в случае
сложных процессов поддержания температуры, влажности, давления, блокировок систем.
А в общем АСУТП процессы каждый день отличаются - сегодня плавка стали, завтра крекинг нефти, послезавтра
растворный узел и т.д. Поэтому здесь программисту без технолога, умеющего описать весь процесс "в ручном режиме"
не обойтись.

Как-то так.

Программист должен знать, что в случае "навязывания" своего решения он "крайний". Технолог при любом "косяке" будет переводить стрелки. Вам оно надо?


Должен знать как управлять летательным аппаратом? А еще и уметь Иначе не почувствует нюансов.


В этом то и суть. Сегодня органическая химия, завтра неорганическая. Потом криогенная техника и АВОК. Где набрать столько вундеркиндов. Хотя похоже один тут "есть"

Бывает, что не понимает. До отладки практически всегда так. Думаешь одно, а на самом деле хрень полная. Слепая уверенность в том, что твоя программа рабочая - не показатель.




Мы тут с напарником недавно проектанту ОВ-шнику вдалбливали, как надо ставить трёхходовые клапана на нагрев и как на охлаждение. А он долбит своё "мне из Салдо так прислали...". Вроде чувак уже пяток лет на проектах отработал...

Не бывает у хороших программистов слепой уверенности в том, что его программа работает, пока он не обкатает ее 10 раз для начала на столе, а затем на объекте автоматизации.