Средство для программирования контроллера: Си или МЭК 61131?
Да не LD они писали, а задачи автоматизации. У них уже были готовые заготовки для Вашей задачи. Сколько они на эти заготовки времени убили - никому не известно. Вот о чем разговор.
Вы уверены? :) Я вот знаю, что заготовок у них не было никаких, т.к. проект для них был новый по технологии. Были у них алгоритмы только.
Нет. Я поддерживаю язык.
Си ? :) А зачем его поддерживать, он и сам по себе неплохо живет :)
Или Вы про другой язык ;)
Программы пишет и сопровождает другой человек. А конфигурированием - третий (заказчик). И технологию пишет заказчик (технолог). Никто из обслуги даже и не знает, на чем ПО написано. Они просто кнопки давят на сенсорном экране. У них и без программирования своих забот хватает... им работать надо.
Говоря про обслугу я имел ввиду не технологов, а инженеров систем управления, которые работают на производстве и обслуживают систему, а не тех. процесс, производят в ней необходимые изменения- конфигурят, настраивают и пр.
Первоначально опубликовано Дмитрий Теркель
[...] .. умирать он будут еще лет тридцать, если не больше, и в ближайшее время его вряд ли что существенно сдвинет с того уникального места, которое он занимает. Все же на сегодня это единственный язык, на котором действительно можно сделать все (пусть иногда и коряво), и на котором реально пишется все системное ПО. [...]
небольшая ремарка.
Системное ПО пишется в основном на чистом Си. Си++ используется только для написания интерфейса... окошки, иконки и т.п. В M$, по крайней мере, это так.
Системное ПО пишется в основном на чистом Си. Си++ используется только для написания интерфейса... окошки, иконки и т.п. В M$, по крайней мере, это так.
Ремарка на ремарку :) .
В основном да, но есть исключения, причем довольно заметные.
Symbian OS (бывшая Epoc от Psion, для мобильных устройств, новые телефоны Nokia, например, все под ней работают)
написана на C++.
Честно говоря, меня, например, на чистом C порядочно ломает, когда вместо виртуальной функции приходится сооружать что-то вроде
typedef struct MyInterface{
...
PMyFuncType myfunc;
....
}MyInterface;
да еще правильно инициализировать эту чертову структуру, да еще доступаться к ней через что-то вроде
myObject->pMyInterface->myFunc()...
Брр-р-р.
С уважением,
Дмитрий Теркель
Первоначально опубликовано VSerg
Пожалуй соглашусь с вами по поводу SFC+ST, что эти двое могут заменить практически все на данный момент. Так как LD был необходим при переходе от релейных схем к контроллерам. Я не говорил вам, что покажу в форуме за 5 минут схему. Я сказал, что ее можно написать за 5 минут, на уровне закрыть/открыть клапан и не надо передергивать, естественно формат форума мало предназначен для отображения схем LD. Да и Вы всегда сможете сказать, что нарисованная схема не работает.
Что не работает не скажу, просто нужно же с чем-то сравнивать.
Но с форматом графики действительно нервотрепка не пообщаешься даже по-человечьи...
Первоначально опубликовано VSerg
Лучше найдите где-нибудь демо версию ISaGRAFA и посмотрите Project2 и Demo. Раз уж все равно в ваши обязанности входит изучение материалов по АСУ. Надеюсь это вас не затруднит. Забираю, свои слова о вас, как о теоретике обратно, возможно, что вы пока не посмотрите не поверите. Только найдите версию PRO 4.12 или PRO 4.20.
Постараюсь, не уверен, что скоро смогу...
Первоначально опубликовано VSerg
И я все же хотел бы увидеть кусок работы с клапаном на СИ-подобном языке, ведь вам ничто не должно мешать вывести его в форуме.
Ну, типа такого... Попросил у программиста
упрощенный вариант... комментарии вставил уже я,
для понимания... в стиле Си++... форматирование
съедет, но тут уж
/*=========================================*/
/*= =*/
/*= ОТКРЫТИЕ КЛАПАНА НАТЕКАНИЯ VE1 =*/
/*= 643.АЭ1610.10000 Д2.36 =*/
/*=========================================*/
ПРОЦ ОТКР_НАТ_АВД1_VE1{
ИЗ ПРОЦ Инициализация К_VE1, // ссылка на
Т_НА_СРАБАТЫВАНИЕ_УСТРОЙСТВ_ГВС, // описание глобальных
У_VE1; // переменных, привязку к UNIO и т.п.
// (все это в неком процессе "Инициализация")
// У_VE1 - выходной сигнал Управления клапаном,
// К_VE1 - входной сигнал Контроля срабатывания клапана
СОСТ Начало {
У_VE1 = ОТКР; // выдаем сигнал на открытие (UNIO) и переходим
В СОСТ КонтрольСрабатывания; // в состояние контроля открытия
}
СОСТ КонтрольСрабатывания {
ЕСЛИ (К_VE1 == ОТКР) { // если сработал клапан - посылаем сообщение в UI и останавливаемся
SendMsgPIVCode(ПК_ПИВ_КЛАПАН_VE1_В_НОРМЕ);
СТОП;
}
ТАЙМАУТ Т_НА_СРАБАТЫВАНИЕ_УСТРОЙСТВ_ГВС { //если прошло много времени, а клапан не открылся,
SendMsgPIVCode(ПК_ПИВ_ОТКАЗ_ОТКР_VE1); //то посылаем сообщение оператору (UI) и ошибка
ОШИБКА;
}
}
} /* конец ПРОЦ ОТКР_НАТ_АВД1_VE1 */
Системное ПО пишется в основном на чистом Си. Си++ используется только для написания интерфейса... окошки, иконки и т.п. В M$, по крайней мере, это так.
Ремарка на ремарку :) .
В основном да, но есть исключения, причем довольно заметные.
Symbian OS (бывшая Epoc от Psion, для мобильных устройств, новые телефоны Nokia, например, все под ней работают)
написана на C++.
Честно говоря, меня, например, на чистом C порядочно ломает, когда вместо виртуальной функции приходится сооружать что-то вроде
typedef struct MyInterface{
...
PMyFuncType myfunc;
....
}MyInterface;
да еще правильно инициализировать эту чертову структуру, да еще доступаться к ней через что-то вроде
myObject->pMyInterface->myFunc()...
Брр-р-р.
Да. Си++ в определенных классах задач весьма облегчает жизнь...
Ну, типа такого... Попросил у программиста упрощенный вариант... комментарии вставил уже я, для понимания... в стиле Си++... форматирование съедет, но тут уж
Эээ, а где контроль закрытия клапана (у Вас же только на открытие он работает) ? А где возврат состояния при очистке блокировок? А это вообще клапан нормально открытый или нормально закрытый? А инверсия сигналов ? А где контроль процента открытия?
Какой-то у Вас пример уж слишком уж студенческий, не катит даже для самого наипростецкого нашего стандартного темплейта :)
Первоначально опубликовано Дмитрий Милосер
Да не LD они писали, а задачи автоматизации. У них уже
были готовые заготовки для Вашей задачи. Сколько они на эти заготовки времени убили - никому не известно.
Вот о чем разговор.
Вы уверены? :) Я вот знаю, что заготовок у них не было никаких, т.к. проект для них был новый по технологии. Были у них алгоритмы только.
Хорошо. Беру свои слова обратно.
У нас действительно беспредметный разговор получается...
"в 80-х годах кто-то реализовал что-то за 2 месяца..."
критиковать тут что-то бессмысленно, все тонкости
проекта неизвестны, квалификация исполнителей - туман...
Как, впрочем, и преимущества LD подхода этим фактом не
докажешь... ахинея какая-то в общем.
По себе скажу, что составление алгоритмов занимает у наших программистов 90% времени... в графике, кстати,
в блок-схемах... по большей части просто карандашом в журнале...
Последний проект - модификация алгоритмов выращивания
кремния в алгоримты выращивания корунда заняли, смешно
сказать, две недели... писал один человек... и
конфигурация тех. средств новая и набор модулей и
алгоритмы... Опять же, ничего не доказывает, портянки
алгоритмов же здесь не приведешь... да и кто будет в них
разбираться, в месяц не управишься... по структуре -
конфетка, в любой момент можно перекроить сверху-
донизу... :-)
Первоначально опубликовано Дмитрий Милосер
Нет. Я поддерживаю язык.
Си ? :) А зачем его поддерживать, он и сам по себе неплохо живет :)
Или Вы про другой язык ;)
Другой, конечно. Сижу вот в конфе его поддерживаю... :-)
Сегодня занимался составлением инструкции по инсталляции
системы... весь день коту под хвост. Десять
страниц борьбы с Виндовз и драйверами, что вставать не
желают... Сколько раз говорил своим умникам, что под
Linux валить надо...
Первоначально опубликовано Дмитрий Милосер
Программы пишет и сопровождает
другой человек. А конфигурированием - третий (заказчик).
И технологию пишет заказчик (технолог). Никто из обслуги
даже и не знает, на чем ПО написано. Они просто кнопки
давят на сенсорном экране. У них и без программирования
своих забот хватает... им работать надо.
Говоря про обслугу я имел ввиду не технологов, а инженеров систем управления, которые работают на производстве и обслуживают систему, а не тех. процесс, производят в ней необходимые изменения- конфигурят, настраивают и пр.
А я говоря про обслугу, имел ввиду и технологов, и
техников КИПовцев... у нас по штату инженеров систем
управления не предполагается... дорого слишком.
Ну, типа такого... Попросил у программиста
упрощенный вариант... комментарии вставил уже я,
для понимания... в стиле Си++... форматирование
съедет, но тут уж
Эээ, а где контроль закрытия клапана (у Вас же только на открытие он работает) ?
На закрытие - это другой процесс.
Первоначально опубликовано Дмитрий Милосер
А где возврат состояния при очистке блокировок?
Уточните вопрос. Какого состояния и каких блокировок?
Разумеется, рассматриваемого насоса касаются еще несколько процессов, но что именно имеете ввиду мне неясно...
Первоначально опубликовано Дмитрий Милосер
А это вообще клапан нормально открытый или нормально закрытый?
Это нормально закрытый клапан.
Первоначально опубликовано Дмитрий Милосер
А инверсия сигналов ?
Уточните вопрос.
Первоначально опубликовано Дмитрий Милосер
А где контроль процента открытия?
Это не запорно регулирующий клапан.
Этот клапан либо полностью открыт, либо полностью закрыт... Впрочем, на используемых типах запорно-регулирующих клапанах тоже нет процента открытия.
Ввести можно и несложно, только оператору это
не нужно, т.к. ЗР клапаном управляет автомат - регулятор давления... а давление заданное, текущее и
предупреждения о недопустимом рассогласовании -
выдается... оператору это интересно.
Первоначально опубликовано Дмитрий Милосер
Какой-то у Вас пример уж слишком уж студенческий, не катит даже для самого наипростецкого нашего стандартного темплейта :)
Я знал, что Вы простоту оцените... На самом деле он даже
еще проще, т.к. комментариев в исходном тексте нет... :-)
Владимир, по моему Вас немного заносит и Вы переходите на личности. Вы же не верите никому на слово, почему же ожидаете этого от других? Если не помните где видели упоминаемые Вами экспериментальные данные, так и скажите. Это вполне нормальная ситуация.
И я не вижу связи между критическим настроем кого нибудь к Вашим высказываниям и умственными способностями этого кого-то. Иначе придется признать что почти все участники этой дискуссии страдают умственной неполноценностью, так как в той или иной степени были несогласны с Вами по тем или иным вопросам.
С Уважением,
Сергей Сорокин
Первоначально опубликовано Владимир Е. Зюбин
Первоначально опубликовано Доктор Q
Вас в очередной раз поймали на явной глупости, вы же пытаетесь - как обычно - увести разговор в сторону. Если у вас есть упомянутая информация - представьте ее, и я возьму свои слова назад (т.е. переведу это ваше утвержждение из разряда безответственного трепа в разряд полезной информации).
Пока на глупостьи ловили только Вас...
Вот основные Ваши проблемы:
1. Вы постоянно демонстрируете завидную тупость в отстаивании своего невежества.
2. Вы не обладаете умением логически мыслить.
3. Вы не в состоянии соблюдать простейшие правила ведения дискуссий.
Первоначально опубликовано Доктор Q
<SPAN class=bold>Владимир Е. Зюбин </SPAN>Только вот адепты FBD того же самого, да и LD, в частности, скорее всего не знают, что экспериментальные данные (подчеркиваю, строгие экспериментальные данные) говорят о том, что существуют достаточно распространенный класс случаев, когда читаемость графических языков оказывается гораздо ниже, чем текстовых.
Ссылочку. Приведете ссылку на достоверный источник - прочитаем - будем знать. Пока же это утверждение положим в "отстойник", т.к. на слово вам верить не приходится, как источник информации вы не заслуживаете доверия. Подозреваю, что и в данном случае вы "слышали звон", но при пересказе, как обычно, сильно передергиваете.
Я знаком с результатами других исследований, которые выясняли, сколько времени оператор тратит на восприятие информации с измерительного прибора. Показания цифровых приборов воспринимались медленнее всего, показания шкальных приборов - быстрее всего.
Вероятно, это не попадает в "достаточно распространенный класс случаев" (с)? Впрочем, как знать, что подразумевается под эти "классом". Шизофрения ведь тоже "достаточно распространена"...
Вы определенно глупы: разговор идет не о приборах, а о языках спецификаций.
Чтобы поймнеть и обнаружить ссылки на упоминаемые мной факты - STFW... ну, или ждите, когда моя статья на эту тему появится... :-)
Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме