SIEMENS, DF&PD

Предыдущее посещение: Чт июн 09, 2016 1:37 Текущее время: Чт июн 09, 2016 1:37

Часовой пояс: UTC + 3 часа




 [ Сообщений: 110 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.

На каком языке программирования в STEP7 Вы предпочитаете программировать контроллеры:
STL 24%  24%  [ 51 ]
LAD 33%  33%  [ 71 ]
FBD 17%  17%  [ 36 ]
SCL 18%  18%  [ 38 ]
Graph 0%  0%  [ 1 ]
HiGraph 0%  0%  [ 2 ]
CFC 5%  5%  [ 12 ]
Всего голосов : 211
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 23, 2007 9:16 
Не в сети
Известный Писатель

Зарегистрирован: Пн май 16, 2005 9:10
Сообщения: 126
FBD + STL


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 23, 2007 11:39 
Не в сети
Возможно это нечеловек

Зарегистрирован: Ср апр 19, 2006 20:58
Сообщения: 2390
Одни и те же факты каждый объясняет по своему:
Андрей Глыбянский писал(а):
Все остальные языки входят в профессиональну версию, которая на 1000 евро дороже...

Многие платят эту тыщу не за дополнительные языки, а за PLCSIM.

Андрей Глыбянский писал(а):
А вообще лидерство этих трех языков, я могу объяснить преимущественным истользованием стандартного пакета STEP7.

Это зависит от уровня развития программистов:
- первые 3 языка - языки низкого уровня,
- SCL - язык Паскаль высокого уровня.
Я использую для управления автоматикой языки низкого уровня, потому что они ближе к железно-электрической контактной логике управления, легко отлаживаются и менее ресурсоёмки.
Использовать SCL функции для установки одного выхода нерационально с точки зрения использования машинных ресурсов и малой и дорогой памяти контроллеров.
Когда в результате написания программы на LAD/FDB/SCL оказывается, что в контроллере вдруг не хватает памяти, то спецы переползают в "STL вид" и чистят программу от "пустых" команд.
Кто то просто боится ассемблерно-схемных языков и скрывает свой страх и нежелание познания выпячиванием SCL / С.
Как Писатель на языках низко/высокого уровня для ПиСюков могу сказать, что иногда хочется иметь и для РС в пакетах программирования наглядные инструменты подобные LAD/FDB - особенно при игре с битами.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 23, 2007 12:03 
Не в сети
Известный Писатель

Зарегистрирован: Чт дек 15, 2005 18:57
Сообщения: 308
Откуда: Одесса, Украина
>Кто то просто боится ассемблерно-схемных языков и скрывает свой страх и нежелание познания выпячиванием SCL / С

Зря вы так. Простой пример. На SCL в разы удобнее работать с массивами данных. Это конечно же можно сделать и на STL - но мой опыт таков - код простого перебора 100 структур в датаблоке, например из 5-10 составляющих будет вообще нечитаем, даже если вы напихаете туда комментариев. Так что все зависит от навыков, опыта и необходимости. А экономить пару килобайт чтобы потомки повесились - это плохо.
ИМХО, разумеется.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 23, 2007 12:52 
Не в сети
Возможно это нечеловек

Зарегистрирован: Ср апр 19, 2006 20:58
Сообщения: 2390
Andrey писал(а):
Простой пример...

Дело не в "простых примерах" - я знаю автоматчиков (от СИ/РС программирования), которые просто боятся STL/LAD или FDB (как и электросхем) и которым трудно нажать F1, чтобы разобраться в простоте этих языков.
Я с самого начала пытаюсь показать, что сам опрос является абстрактным в отрыве от конкретно решаемых задач и уровня приложений - то что позволительно для старших 400-х, не позволительно для младших 300-х.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 23, 2007 13:29 
Не в сети
Начинающий писатель

Зарегистрирован: Пт фев 09, 2007 14:18
Сообщения: 75
Откуда: Украина, Харьков
Цитата:
иногда хочется иметь и для РС в пакетах программирования наглядные инструменты подобные LAD/FDB

Используй Trace Mode. Там поддерживаются все МЭК языки.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 23, 2007 14:48 
Не в сети
Известный Писатель

Зарегистрирован: Вт янв 04, 2005 13:09
Сообщения: 194
Откуда: Петрозаводск/Petroskoi
Каждому овощу - своё время, в смысле, каждому языку - своя ниша.
И спор о том, что лучше в принципе - бесполезен. Сколь не был бы велик и гибок STL, писать на нем много плавучих вычислений, или сложные ветвления - убивство. Для этого придуман SCL.
Проголосовал за SCL, бо львиная доля моих проектов состоит из формульных вычислений. А машины состояний легко реализуются через свищ.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 23, 2007 15:20 
Не в сети
Возможно это нечеловек

Зарегистрирован: Ср апр 19, 2006 20:58
Сообщения: 2390
Андрей Глыбянский писал(а):
Цитата:
иногда хочется иметь и для РС в пакетах программирования наглядные инструменты подобные LAD/FDB

Используй Trace Mode. Там поддерживаются все МЭК языки.

В Trace Mode я могу написать офисное приложение под Окна (никоим образом не связанное с автоматикой) для обработки каких то данных и обширных дисковых операций и Оконным интерфейсом меню ?
Цитата:
Каждому овощу - своё время, в смысле, каждому языку - своя ниша.
И спор о том, что лучше в принципе - бесполезен.

И я о том же пишу - нельзя говорить что лучше (больше) в отрыве от реализуемой задачи.
Цитата:
Сколь не был бы велик и гибок STL, писать на нем много плавучих вычислений, или сложные ветвления - убивство.

Тоже самое говорят и про ассемблер х86 - однако и на нём приходится писать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 23, 2007 16:17 
Не в сети
Известный Писатель

Зарегистрирован: Вт фев 08, 2005 19:13
Сообщения: 127
Откуда: A/S "Biotehniskais centrs", Рига
OPN DB ["fc50TmpDBNum"]
A DBX ["pAlarmUDT"]
JCN warn
OPN DB ["fc50GroupDB"]
L "fc50pGroupDBString"
L "pAlarmMask"
+D
T "fc50pGroupDBString"
L DBD ["fc50pGroupDBString"]
OPN DB ["fc50TaskCardDB"]
L DBD ["pActivateFlags"]
AD
T DBD ["pActivateFlags"]
S DBX ["pCardDevAlarm"]
L "fc50DBNum"
T DBW ["pAlarmDeviceLine"]
L "fc50DevNum"
T DBW ["pAlarmDeviceNum"]

Извините, если показалось, что много лишнего и непонятного. Но этот кусочек STL - код для реализации всех взаимных блокировок по аларму для цеха с примерно сотней исполнительных устройств. И многими сотнями вариантов взаимно пересекающихся маршрутов перемещения и смешивания. Я хотел бы взглянуть на того, кто стал бы прописывать эти взаимные блокировки как обычно принято - в лоб да на LAD. А такое, как приведено в примере, можно сделать только в STL.
STL код оптимальнее, исходник гораздо нагляднее по сравнению с тем же FBD, если надо смотреть не один нетворк, а держать в поле зрения несколько. Набирать текст ручонками тоже быстрее, чем тыкать мышкой и выбирать операции из списка. К тому же никто ведь не мешает писать так, чтобы битовые цепочки конвертировались в LAD/FBD. В общем, из этой трицы лично я за STL.
Что касается PCS7. SFC вроде как удобны, но жутко тормозят. И еще не хватает возможности сделать еще что-то помимо операций простого присваивания. CFC чарты зачастую нечитаемы. Но от них, увы, никуда не денешься. Лучше уж все, что можно, упаковать в свои самописные блоки. SCL - да, вещь в принципе неплохая. Во многих случаях может заменить STL.
В общем, я голосовал однозначно за STL.:)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Ср авг 29, 2007 8:20 
Не в сети
Новый писатель

Зарегистрирован: Ср апр 05, 2006 7:27
Сообщения: 12
Откуда: Balkash
STL + FBD


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Ср авг 29, 2007 11:26 
Не в сети
Писатель со стажем

Зарегистрирован: Вт янв 11, 2005 8:43
Сообщения: 527
Откуда: Россия, г.Самара, ООО НВФ "СМС"
Сложная логика - SCL (алгоритмы технологического управления). Все остальное - STL. Просто он больше позволяет чем LAD/FBD в плане программирования, не оставляет мусора в кода типа BLD и абсолютных локальных переменных. Плюс, если руки не кривые, читается он столь же легко, как и графические языки.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Ср авг 29, 2007 11:49 
Не в сети
Возможно это нечеловек

Зарегистрирован: Ср апр 19, 2006 20:58
Сообщения: 2390
Артем Сидоров писал(а):
Плюс, если руки не кривые, читается он столь же легко, как и графические языки.

Наверное имелось ввиду "кривой взгляд" ?

Изображение


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Ср авг 29, 2007 12:29 
Не в сети
Написал больше чем Вы читали

Зарегистрирован: Вс фев 26, 2006 21:44
Сообщения: 1688
Откуда: Липецк, ОАО "НЛМК"
Пора бы уже признать LAD/FBD/STL вопросом религии и не спорить "что круче".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Ср авг 29, 2007 14:31 
Не в сети
Это точно не человек

Зарегистрирован: Вт май 03, 2005 17:11
Сообщения: 3547
Спорить о пользе языков бесполезно: все определяется решаемыми задачами и сопровождением.

Мне привычнее текстовые языки. Однако поскольку мозг уже старый, то предпочитаю SCL, хотя в свое время немало пописал на Макроассемблере для СМ-4образных машин. STL, в моем понимании, для определенных трюков, особенно когда нужно что-то крупно съэкономить,хотя иногда не хватает и нескольких байт или нет средств в SCL. Да и на 400м экономить пока смешо, тем более, что ресурсы проца ростут. Когда пишутся вычисления или логика все же SCL удобнее, и не надо забывать такую вещь, как охват программы взглядом. Согласитесь смотреть на программу из нескольких листов крайне неудобно, а это свойствво ассемлерной программы. (хотя "настоящий программист нисколько не смущаясь напишет цикл DO на 7-ми страницах :-)".

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

LAD как-то сильно непривычен - совершенно им не пользуемся


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Ср авг 29, 2007 20:57 
Не в сети
Новый писатель

Зарегистрирован: Пн фев 05, 2007 19:18
Сообщения: 46
Откуда: Юж. Урал
STL однозначно, SCL в блоках, где STL плохо читается (обработка многомерных массивов)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 30, 2007 15:11 
Не в сети
Возможно это нечеловек

Зарегистрирован: Пн окт 30, 2006 16:27
Сообщения: 2246
Откуда: Украина, Днепродзержинск
Добрый день.
Действительно занятная тема.
Я предпочитаю STL (не важно 300 или 400 - при отладке программы очень удобно видеть построчно где, что и как, если что-то не идёт) это если логика или, вообщем если это только не какая-нибудь навёрнутая математика.
Совсем недавно начал писать на FBD, мне показалось, что время создания программы дольше. Лично моё субъективное мнение.
Если математика или работа с массивами, то SCL, однозначно. По-моему удобней, чем на STL.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 30, 2007 17:19 
Не в сети
Новый писатель

Зарегистрирован: Чт мар 15, 2007 17:31
Сообщения: 34
День добрый!
Вполне согласен с Cerberus о выборе языков.
Если работать с чем нибудь простым, т.е. логикой то разницы нет LD, STL, FBD. Здесь уж, что кому нравится. Я начинал с LD, а потом безболезненно перешел на STL. С FBD как то работать ненравится, хотя ничего страшного в нем нет.
Если же приходится работать со сложной математикой, а не с Булевой алгеброй, то выгоднее как мне кажется SCL. Хотя и на STL можно сделать расчеты, а также и на LD и на FBD. Правда читать такую программу будет сложновато. Придется много коментариев применять для нормального чтения.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт авг 31, 2007 16:49 
Не в сети
Известный Писатель

Зарегистрирован: Вт авг 09, 2005 15:49
Сообщения: 172
Откуда: Минск, SIMATEK
Язык выбирается в зависимости от задачи.
    Управление оконечными выходными механизмами - LAD.
    Небольшой блочёк, которому в качестве входной переменной передаётся указатель - STL (по другому нельзя).
    Блок с адресацией i-го элемента массива SCL (чтобы не возиться с косвенной адресацией)ъ
    Последовательное управление - GRAPH.

А вообще жду объектно-ориентрованных языков в контроллере.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вс сен 02, 2007 16:00 
Не в сети
Это точно не человек

Зарегистрирован: Вт май 03, 2005 17:11
Сообщения: 3547
Крайне отрицательно отношусь к объектно - ориентированным языка в системах промышленной автоматизации. Одна из причин - надежность компилятора - еше не слышал ни об одногм компиляторе с ООП- язвка, в котором не было бы ошибок. Другая причина - неконтролируемая работа со стеком. По этому не считаю такие программы надежными.

ООП было создано для превращения программирование в ремесло, для гонок с конкурентами. Как мне сказал представитель Микрософт - Мы могли бы сделать качественный продукт, но на это потребовалось бы 10 лет, а так - два года.

Некоторое отступление: недавно достал с полки комп Р-90 c 16Мб и стал ставить на него win95. Установка заняла времени столько же или может меньше, чем на ХР на Xeon 3Ггц с 2Мб Ultrascsi 320. Сравнивать эти системы конечно в лоб нельзя, но для конечного пользователя разница не столь существенна - текст набирается, печатается, в инет ходит. Можно спомнить еще СМ-4 со 128Мб и 1мкс процем, которая очень лихо тянуло 4 терминала. А во вногом вся эта деградация ОС благодаря ООП


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн сен 03, 2007 13:18 
Не в сети
Известный Писатель

Зарегистрирован: Вт авг 09, 2005 15:49
Сообщения: 172
Откуда: Минск, SIMATEK
Насколько я знаю, объектно-ориентированное программирование базируется на серьёзном математическом аппарате по абстракции данных, который разрабатывался в 60-70 годах прошлого века.
И компанию Микрософт никак нельзя уличить в том, что она разработала объектно-ориентированный С++, на котором написано очень много (думаю, что и большая часть Линукс)
Что касается надёжности компиляторов, то в сфере промышленной автоматизации никто не гонит никого взашей и новый компилятор можно "вылизывать" хоть 10 лет. А может быть это вообще будет интерпретатор?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн сен 03, 2007 15:34 
Не в сети
Это точно не человек

Зарегистрирован: Вт май 03, 2005 17:11
Сообщения: 3547
речь идет не о том, чтобы уличить микрософт или расхвалить ...Nix- подобные системы, а речь о том, что:
1. Компиляторы языков для ООП занчительно сложнее верифицировать, особенно Run-Time среду;
2. С ООП-програмой Вы можете нарушить границы стека,особенно для систем реального времени, а не настольных систем, поэтому нужно управление стеком (его границами)
3. примение ООП нарушило тщательность прорвботки решений: бери объект и приделывай к нему метод. И больше начинаешь изощряться как прицепить какой-то объект, не задумываясь о последствиях - внутренняя то суть скрыта в объекте.

Вообще все хорошо написано у Янга "алгоритмические языки систем реального времени" - точное название не помню. Хоть мне противно писать кучу описаний переменных - оно есть правильно. И вообще обучение программированию надо начинать с Алгола, жаль сейчас нет с него компилятора - весьма дисциплинирует ум.

А язык для систем реального времени должен быть,
а) сильно типизированным;
б) иметь минимум операторов - в основном присваивание, сравнение, перехода и как элемент оптимизации циклы. Это примерно и есть SCL


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
 [ Сообщений: 110 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 5


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения

Перейти:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group