|
|
Средство для программирования контроллера: Си или МЭК 61131? |
Это уже несколько другая область - синхронизаций и IPC (Inter Process Communication) ... вообще-то, успешное (ну, совершенно корректное) решение здесь зависит, по-моему, от того, насколько инструмент: язык, библиотеки, OS ... позволяют описывать много потоковые вычисления (не в смысле thread конкретно, а независимо от механизма: потоки, процессы, нити, ветви...). Даже на самом убогом оборудовании, допускающем только строго "линейное" выполнение... впрочем, об этом очень много написано (Хоар, Дэёкстра, Р.Янг...). В универсальные языки, к сожалению, эти механизмы входят редко, только в самые последние: Modula-2, ADA, Oberon - кажется... Чаще - это реализуется библиотечными средствами: С, С++, ... К счастью, независимо от реализации - общая структура таких механизмов в "необходимой и достаточной" степени отлично стандартизована: POSIX 1003c, 1003b. Эти механизмы достаточно обширны и сложны. Я так подозреваю, что "целевые" средства разработки могут включать только простейшие средства. Но этого и достаточно - для более изощрённых случаев нужно использовать и более изощрённые механизмы (те-же библиотеки С/С++). |
|||||
 |
|||||
Насколько я знаю, то исаграф работает под следующими ОС: информаця c сайта www.fiord.com. ISaGRAF Runtime Target может исполняться в любой операционной системе: Embedded NT, NT RTX, VxWorks, Phar Lap, OS-9/9000, Windows CE, Linux, pSOSystem, Windows NT, LynxOS, QNX, MS-DOS, US Software, NT INtime, VRTX... Можно также портировать isagraf на железо без ос. естественно понадобятся драйвера. |
|||||
|
Каждой вещи свое место.
С уважением, VSerg. |
|||||
|
|||||
Да - негодно названа тема - отсюда и последствия. Т.е. - не всё так плохо: всё это полезно и интерсно было бы почитать ... но в 10-ти ;-) темах, не сваливая в одну. Слишком широко "захватили", даже если это "алгоритмы для техпроцессов": - что такое техпроцесс? Одному это - управление производством жевательной резинки (тут кто-то писал ;-)). Актуально? Безусловно. Другому - управление раскруткой турбины (я этот предмет просто знаю)... Тех. процесс это? А как же! Чем отличается от предыдущего? ... те-же датчики, контакты, вентили... Практически ничем, кроме того, что реакцию по времени проаустить нельзя - вырвется эта дура из подшипников, и пойдёт "гулять по территориям", как гироскоп стабилизируясь - говорят до 5-6 часов "гуляет" здания круша... А у меня, чаще, техпроцесс: получать огромный зашумленный поток данных от радарного приёмника, обсчитать, обнаружить, выделить координаты, дать целеуказание и "влупить"... Техпроцесс? Ещё какой. Но здесь - 95% по объёму и кода и времени - цифровая обработка сигнала... Не может быть единых правил даже для этих 3-х техпроцессов! - что такое контроллер? (который программировать собираемся). 2 шкафа набитых И-НЕ логикой - контроллер? А то как же! Только программировать его не нужно - там всё паяльником "запрограммировали". PIC простейший на ретрансляции данных - контроллер? Или ещё вот: контроллер - это только то, что на низовом уровне? А если там PC-104+ Celeron 650 с OS QNX - контроллер? А на верхнем уровне? Не контроллер? А если там такой же PC-104+ Celeron 650 с OS QNX? А если и нет уже нижнего-верхнего уровня, если они (PC-104 модули) в сети и отличаются "нижний-верхний" только по выполняемому сегодня ПО, т.е. функционально? А завтра "верхний" вынут и унесут на профилактику, а "нижний" станет выполняться как "верхний"? (А я не придумал эти ситуации - недавно делали, сейчас макетно эксплуатируется). |
|||||
|
|||||
И, совершенно естественно, что под каждой из OS он будет поддерживать то коммуникационное оборудование, протоколы транспортного уровня и т.п. - которые поддержтвает каждая конкретная OS. |
|||||
|
|||||
|
очень много здесь зависит от OS и её tools поддержки обменов Дмитрий Теркель В сущности, Вы сейчас мимоходом озвучили единственный СЕРЬЕЗНЫЙ недостаток примененения C++ в рассматриваемой области Если бы единственный... К серьезным надо бы еще (как минимум) отнести плохую читаемость, небезопасность и низкоуровневость. Предлагать архаичные С/С++ в качестве образца для подражания и пути для развития - совершенно несерьезно. У этих языков нет будущего. Их не зря сравнивают с Фортраном, поскольку С/С++ уготована та же судьба. Можно было бы еще понять если бы кто-то пытался агитировать за более современные Java или C#, в которых устранены многие недостатки устаревших C/C++. Но даже при этом "С-подобный" синкаксис делает их малопригодными для создания и сопровожения надежных программ. На мой взгляд, более не стоит тратить время на споры с пропонентами С. Интереснее было бы обсудить языки Эйфель и Эрланг. |
|||||
|
|||||
|
что такое техпроцесс? Одному это - управление производством жевательной резинки (тут кто-то писал ;-)). Актуально? Безусловно. Другому - управление раскруткой турбины (я этот предмет просто знаю)... Тех. процесс это? А как же! Чем отличается от предыдущего? ... те-же датчики, контакты, вентили... Практически ничем, кроме того, что реакцию по времени проаустить нельзя - вырвется эта дура из подшипников, и пойдёт "гулять по территориям", как гироскоп стабилизируясь - говорят до 5-6 часов "гуляет" здания круша... Ну, не мне рассказывать всем какие бывают процессы :) Основные: -непрерывный (нефтянка, химия, металлургия и т.п ) - дискретный(еще называют прерывистый) (автопром, изготовление штучных деталей, станки, роботы с ЧПУ и т.п.) - гибкие - batch (периодические )- управление процссами смещения и пр.) ну и производные уже от них...смешанные процессы. А у меня, чаще, техпроцесс: получать огромный зашумленный поток данных от радарного приёмника, обсчитать, обнаружить, выделить координаты, дать целеуказание и "влупить"... Техпроцесс? Ещё какой. Но здесь - 95% по объёму и кода и времени - цифровая обработка сигнала... Не может быть единых правил даже для этих 3-х техпроцессов! Эээээ, нет, батенька :) Вы меня с толку не собьете, я говорил о ТЕХНОЛОГИЧЕСКИХ процессах :) Жаль, сократил. Но я надеялся, что все знают аббревиатуру АСУ ТП... :( По поводу контроллеров...ладно, приведу живой пример (живее некуда :) В конце 80-х нефтяникам немцы (ГДР) поставляли комплексные ЦПУ. Кто не знает- центральный пункт перекачки нефти. Автоматизировали они ЦПУ в последние годы на супертехнике как всем тогда казалось- ПЛК с "сердцем" на небезызвестном камне Z80. Язык- асмоподобный. Круто, да? Куда круче Си и быстрее главное! :) Ну так вот, когда меня посадили на обслугу этого "пряника", я 3!!! месяца предже чем начать доработку, только срисовывал с листинга асма алгоритм работы печей (тоже какбы взрывоопасная штука-то). Примерно в то же время у нас начался гораздо больший проект по автоматизации НПЗ. Там уже купили РСУ примерно тех же годов разработки (конец 80-х). И контроллер ПАЗ, алгоритмы на LD были. Ну так вот, пуск всего завода занял 2 месяца, а с обслугой и изменениями мы почти и не парились- все было довольно просто на те времена. Вот вам и трудозатраты и удобство и пр. Так что мня не переубедить, что МЭК хуже для (повторю) создания алгоритмов управления технологическими процессами. Даже не старайтесь :) Я эту разницу через собсвенные ручки прочувствовал. Только не говорите что они кривые :) Проекты-то живут до сих пор и после того еще очень много было разных.
|
|||||
|
|||||
Мне кажется, Вы просто увлеклись глубокосодержательным спором про big endian и не потрудились понять, что я имел в виду ;) ПОэтому я пропускаю мимо ушей слова о "моем" (???) мэке и опасности чьей-то (чьей, интересно?) святой веры. Речь идет не о реализации сетевого слоя, не о транспортных протоколах, на которых эта реализация основывается, и, тем более, не о железе. Я говорю об АБСТРАКЦИИ сети, которая должна быть предоставлена этим слоем для прикладных программ. И о том, что эта сама эта абстракция (а не ее реализация) не должна зависеть от Ос, платформы и т.п. Мэк позволяет ОПИСАТЬ распределенную систему (мэковское описание довольно плохое, но это тема другого разговора) неким стандартным образом. ПРи программировании на C++ нет этой стандартной абстракции сети (имеется ввиду абстракции прикладного уровня, я, конечно, не сокеты имею в виду). А нет этой абстракции не потому, что С++ не позволяет ее создать, а потому, что разработчики систем автоматизации, пишущие на С++, не удосужились ее создать, то есть написать совместно некий файл вроде asutp.h, и делать ему #include в своих прикладных программах. А при необходимости, реализовывать некоторые понятия из этого файла для N-й платформы, K-го транспортного протокола или 78965-го сетевого адаптера. И это относится не только к сети. |
|||||
|
С уважением,
Дмитрий Теркель |
|||||
|
|||||
Голубчик, "читаемость" - это всегда прямая функция "грамотности" ... безотносительно к языкам программирования: "вот в России 1913-го года..."(с) ;-).
... пользуясь термином - огласите, пожалуйста, какие суровые опасности и испытания нас подстарегают в С++... откройте общественности глаза!
Ещё бы! Особенно применительно АСУТП ;-)... Господа - подымите руки, кому было бы любопытно обсудить языки Эйфель и Эрланг (... может ещё "матерный" заодно?). ... Вы слышите меня, стены ... (с). |
|||||
|
|||||
|
Olej какие суровые опасности и испытания нас подстарегают в С++... откройте общественности глаза! Уважаемый общественник, если умеете читать по-английски - читайте http://burks.brighton.ac.uk/burks/pcinfo/progdocs/cppcrit/index.htm
|
|||||
|
|||||
Да я вас с толку сбивать и в мыслях не держал... Я только не пойму: почему управляемый процесс доменной печи вы считаете "технологическим", а тем же, скажем, радиолокационным комплексом - "не технологическим"? Или системы бортовых АСУ тепловоза, метрополитена (то, что мне знакомо) ... или это не "процессы"? Можно и так квалифицировать. Только тогда нужно строго сказать: мы здесь будем рассматривать применимость целевых языков (МЭК) для описания тех процессов, которые мы называем "технологическими", а это значит: а)... б)... в)... |
|||||
|
|||||
Ответить 
|
Страница <1 3940414243 53> |
| Переход на форум | Права доступа на форуме  Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме |
