Просмотр полной версии : вопрос специалистам
есть объект с относительно большим количеством сигналов ввода/вывода (более 500, в основном дискретные и несколько десятков аналоговых). посоветуйте, какой контроллер в сочетании с какими модулями ввода-вывода лучше использовать для автоматизации этого объекта. особого быстродействия не требуется. период опроса всех дискретных датчиков может быть 1...2 секунды. аналоговых еще больше.
самому изучать всю документацию для принятия решения затруднительно, поскольку на это просто нет времени - ответ нужен срочно.
всем спасибо.
1. сколько вы можете истратить денег на эту автоматизацию.
2. нужно четкое техническое задание.
3. желательно, чтобы вы для себя, прежде всего представляли , что вы хотите.
1. сколько вы можете истратить денег на эту автоматизацию.
2. нужно четкое техническое задание.
3. желательно, чтобы вы для себя, прежде всего представляли , что вы хотите.
так я вроде не об этом спрашивал. деньги пока не имеют значения, чёткого техзадания пока тоже нет. я буду представлять для себя, когда это будет представлять заказчик. а заказчику сейчас нужна предварительная смета и вообще вопросов ещё много, в том числе и этот вопрос. овен хотелось бы использовать, потому что уже есть приличный опыт автоматизации, но менее крупных объектов. пока остановился на плк-110 и модулях ввода-вывода мх-110. хотелось бы услышать советы/рекомендации. может у кого уже есть опыт. насколько стабильно будет работать такая конфигурация и т.п.
ну хотя бы опишите словесно предполагаемое физическое размещение ваших источников дискретных и аналоговых сигналов. электро-магнитную обстановку.
по какой сети и каким протоколом будете опрашивать дискретные и аналоговые сигналы ?
Николаев Андрей
21.12.2010, 11:16
на первом этапе разумным кажется разнести территориально плк и модули.
причем ставить на "удаленном узле" плк и подключать к нему модули, и уже с него вести данные к центральному плк.
так вы и управление детерминируете, и скоростей можно больших добиться.
оборудование:
плк110-60 (2 Rs485).
мх110. стоит подумать об использовании новых модулей мв110-32 и му110-32
по какой сети и каким протоколом будете опрашивать дискретные и аналоговые сигналы ?
Скорее всего, это будет RS-485 и Modbus
Что касается электромагнитной обстановки, то пока тоже сложно сказать. Но, скорее всего, будет не очень хорошо - много электродвигателей и магнитных пускателей. Всего на объекте несколько относительно автономных участков. Участки разнесены на несколько десятков метров. Но участки не полностью автономные, поэтому хотелось бы использовать только один контроллер, так как в одной программе проще всё-таки управлять взаимодействием оборудования. С источниками тоже пока не ясно. Дискретными, скорее всего, будут контакты пускателей, коммутирующие входы. Аналоговые - трансформаторы тока и термопреобразователи. Есть ещё датчики уровня, но что у них на выходе, пока не знаю. Скорее всего какой-то стандартный сигнал.
на первом этапе разумным кажется разнести территориально плк и модули.
причем ставить на "удаленном узле" плк и подключать к нему модули, и уже с него вести данные к центральному плк.
так вы и управление детерминируете, и скоростей можно больших добиться.
оборудование:
плк110-60 (2 Rs485).
мх110. стоит подумать об использовании новых модулей мв110-32 и му110-32
Спасибо за совет. Ещё вопрос: ПЛК между собой лучше по какой шине соединять и по какому протоколу. У меня пока опыта совместной работы ПЛК нет.
Николаев Андрей
21.12.2010, 11:42
2 варианта - можно черз Ethernet можно по RS485.
Обусловленно расстояниями и наличием уже готовых комуникаций.
Ethernet быстрее, но без использования сети - сегмент всего 100м. Дальше нужны свичи, хабы, ну или если есть производственная сеть Ethernet - тогда вообще отлично.
RS485 - до 100 метров. Медленнее. С точки зрения помех защищеннее. Имеет ограничение в 32 модуля на один порт.
Так все в двух словах не скажешь...
Модули по любому по RS.
Если не будете дополнительные контроллеры ставить - стоит подумать о ПЛК308, у которого много последовательных портов...
согласен с андреем николаевым.
но вы все же сначала разберитесь со своими источниками сигналов, тяжело что-то советовать, когда вы пишете - (с источниками то же пока не ясно и есть ещё датчики уровня, но что у них на выходе, пока не знаю. скорее всего какой-то стандартный сигнал.)
просто потом замучаетесь согласовывать.
согласен с андреем николаевым.
но вы все же сначала разберитесь со своими источниками сигналов, тяжело что-то советовать, когда вы пишете - (с источниками то же пока не ясно и есть ещё датчики уровня, но что у них на выходе, пока не знаю. скорее всего какой-то стандартный сигнал.)
просто потом замучаетесь согласовывать.
объект новый. только строится, поэтому информации пока маловато. да и заказчик ещё толком не знает, чего хочет. но тем не менее спасибо всем за советы. кое-какую полезную информацию почерпнул. дальше, надеюсь, разберусь с помощью документации и службы поддержки )))))
RS-485 - 32 модуля на один порт.
Филоненко Владислав
21.12.2010, 13:49
Не так. 32 без усилителей
Не так. 32 без усилителей
Естественно без АС-5.
Через syslibcom - 32 ?
32 устройства - это физический уровень 485 протокола. То есть амплитуды сигналов, затухание и т.д. и т.п.
Алексей Дмитриев
21.12.2010, 21:31
На такой немаленький объект, рекомендовал-бы Вам все таки посмотреть какие нибудь известные бренды, например Beckhoff, Siemens, Allen-Bradley. Как показывает практика цена вопроса на средства автоматизации в процентном отношении к цене оборудования при таких масштабах ничтожна, а геморрой с отечественными (китайскими) контроллерами можете нажить такой, что мало не покажется.
На такой немаленький объект, рекомендовал-бы Вам все таки посмотреть какие нибудь известные бренды, например Beckhoff, Siemens, Allen-Bradley. Как показывает практика цена вопроса на средства автоматизации в процентном отношении к цене оборудования при таких масштабах ничтожна, а геморрой с отечественными (китайскими) контроллерами можете нажить такой, что мало не покажется.
С этими контроллерами работать не приходилось. Отсюда вопрос: средства разработки для этих контроллеров насколько совершенны? Просто программа будет очень сложной и совсем не хотелось бы писать её на LD или IL, да ещё без нормальной отладки. Честно говоря, ОВЕН выбран по большей части из-за CoDeSys. Хотя на небольших объектах у нас контроллеры ОВЕН используются и вроде как без особых проблем.
Александр Приходько
22.12.2010, 09:41
С этими контроллерами работать не приходилось. Отсюда вопрос: средства разработки для этих контроллеров насколько совершенны? Просто программа будет очень сложной и совсем не хотелось бы писать её на LD или IL, да ещё без нормальной отладки. Честно говоря, ОВЕН выбран по большей части из-за CoDeSys. Хотя на небольших объектах у нас контроллеры ОВЕН используются и вроде как без особых проблем.
Тогда пишите прграмму на ST - это самый гибкий ззык, либо CFC, но если в программе много условий и циклов, то он будет не удобен.
Алексей Дмитриев
22.12.2010, 09:50
У бекхофа стоит кодесис, только называют как-то по своему, не помню.
Степ 7 - любимая среда многих программистов контроллеров, не скажу что самая лучшая, но...
Аллен-Бредли вообще законодатель в ПЛК, так что комментировать нечего.
Чем Вас, собственно не устраивают стандартные контроллерные языки? На них можно написать все что угодно.;) Тот же кодесис - стандартная МЭКовская среда разработки, не более. Возможности у всех идентичны.
Если хотите контроллер с кодесисом, дабы не изучать ничего нового, посмотрите на сайте кодесиса какие бренды его поддерживают, список немаленький.
По поводу сетевой периферии посоветовал-бы профибас или на худой конец CanBus. На профибас найдете практически любое устройство, конфигурится очень просто и понятно, не сбоит ничего, скорости до 12 Мбод.
Чем Вас, собственно не устраивают стандартные контроллерные языки? На них можно написать все что угодно.;)
Спору нет. Однако ST - язык высокого уровня, и этим всё сказано. Попробуйте, например, создать сложную конструкцию CASE на ST и на LD - разницу почувствуете. К сожалению, не все средства разработки для контроллеров поддерживают язык ST.
К тому же "корни" мои растут из прикладного программирования и Паскаля. И хотя программированием контроллеров занимаюсь уже не мало, предпочтения остались.
Кроме того "буржуйской" техникой без крайней необходимости стараюсь не пользоваться. Кроме плюсов есть и минусы, такие как сроки поставки. Иногда приходилось по 5-6 месяцев ждать.
А вообще спасибо за советы. Есть над чем подумать.
Для тех кто нормально LD поддерживает (омрон например) конструкция подобная CASE реализуеся очень просто, точнее она там вообще не к месту, проще и гибче всё. ST там разве что для блоков с кучей расчётов.
Если LD видели только в средах похожих на кодесис, значит многое пропустили.
Алексей Дмитриев
22.12.2010, 22:07
Добавлю и я свои 5 копеек, чего сложного в CASE? Все диалекты LD, в том числе и кодесисовский его поддерживают элементарно. Писать управляющую программу на паскале - полный бред. Для того чтобы обеспечить многозадачность нужна операционная система реального времени. Все цепочки в LD работают одновременно, попробуйте-ка на паскале реализовать скажем параллельно выполняющиеся 300 булевских выражений. В управлении, как правило не нужно много вычислений, там много булевой алгебры, что и реализуется при помощи LD или IL. Классическое программирование, чему учат всех программистов здесь не катит. Можно, конечно извратиться, и написать на паскале или С программу управления, но это будет на порядок дольше и следовательно дороже чем на LD. Какие-то вещи, например обработку массивов, сложные вычисления проще писать на языках высокого уровня, они для этого и предназначены, но во всех серьезных контроллерах это можно организовать в виде функций и языки эти поддерживаются.:)
Писать управляющую программу на паскале - полный бред. Для того чтобы обеспечить многозадачность нужна операционная система реального времени. Все цепочки в LD работают одновременно, попробуйте-ка на паскале реализовать скажем параллельно выполняющиеся 300 булевских выражений.
Я бы на вашем месте не был так категоричен, ведь суть моей задачи вы не знаете. Иногда как раз таки и не надо, чтобы программные блоки выполнялись одновременно. И тогда придётся извращаться уже в LD. Конечно, быстродействие и т.п. - тут вы правы. Но никто меня не убедит, что некоторые сложные задачи проще решать в LD. Повторюсь - не все, а некоторые задачи.
А многозадачность в CoDeSys (впрочем, как и в других современных средах) обеспечивается элементарно - просто создаёте столько задач, сколько нужно. И на каком языке писать эти задачи - это уже не важно.
С Омроном я работал. И мне не понравилось (я имею ввиду среду разработки). Возможно, что это пережитки моего программистского прошлого, но всё-таки (если нет особых требований к быстродействию), я предпочитаю ST. Конечно, если логика программы относительно проста, то LD проще и понятнее. Однако мы не ищем простых путей)))))) (и не пишем простых программ).
В общем, по этому поводу можно долго рассуждать, и всё равно каждый останется при своём мнении)))))
Дмитрий Артюховский
23.12.2010, 10:06
Для того чтобы обеспечить многозадачность нужна операционная система реального времени. Все цепочки в LD работают одновременно,
смешно ))))
...мало систем можно вспомнить, где время рулиться так жестоко, как в контроллерах....
... системы реального времени - суть системы в которых разработчик гарантированно знает чем система занимается в каждый произвольно взятый квант времени....
а про одновременную работу цепочек где прочитали, в святом писании про 7 дней ???
... если вы правда это не значете, то "одновременность" работы заключается в "одновременном" считывании мартицы входов и "одновременной" же записью сгенерированной матрицы выходов... на каком языке происходит реализация функции обработки по барабану, (ну конечно за исключением случаев, когда на каком-либо языке можно желаемую функцию выразить лаконичнее)
кстати, про классическое пограммирование... если вы имеете ввиду однозадачное, времен 70 годов, то да не катит, а современные модели с классами и "событийной ориентированностью выполнения" очень хорошо ложиться на цикл контроллера
Николаев Андрей
23.12.2010, 11:03
Господа - давайте спокойнее.
1.МЭК - он по тому и содержит 5 языков, чтобы каждый специалист мог писать на удобном ему исторически.
И спорить тут бесполезно - это как спорить про цвет машины...
2.Системы реального времени, как правильно замечено - сложная и дорогая система, требующая и специализированной ОС и кучу еще чего. Напомню - Real Time - это не скорость выполнения, а отсутствие задержек.
3.Ни в одном контроллере, даже Real Time времени в LD все ветки параллельно не выполняются. Выполняется первая строчка слева на право, потом вторая, потом третья... потом последняя. Записали образ выходов, считали образ входов, и начинаем с первой строчки.
Процессоры то все-таки не многоядерные используются...
Алексей Дмитриев
23.12.2010, 21:34
:D Ну я посмотрю на Вас, когда надо будет одновременно обслужить систему из 1000 входов и 500 выходов. Причем управлять будете из программы на паскале или бейсике под управлением окошек в качестве ОС.
Здесь речь идет именно о программировании логических контроллеров, которые пришли на смену релейных систем управления и жесткой логики.
Ваше FOR TO DO катит только для обработки массива. Задача из учебника по программированию для 5-го класса средней школы.
Мне глубоко по барабану как там контроллер обрабатывает свои LD цепочки, так как с точки зрения программирования это выглядит и выполняется точно также как релейная схема.:)
lara197a
23.12.2010, 23:06
Уважаемые коллеги не горячитесь. Я сам в предпочитаю ST, это очень удобно. остальные языки использую по необходимости.
Имею дело с заводом по производству газосиликатных блоков(стороили немцы) и сендвич панелей(итальянцы).
Заводы полностью автоматизированы. используются многоконтроллерные системы. семен семеныч естественно. так вот ПО также написано в основном на LD и ST. Кстати и немцы и итальянцы больше стараются писать на LD - легче обслуживать, нагляднее режим ОНлайн.
А несколько контроллеров для того и ставят, что бы не обрабатывать одновременно 500-1000выходов.
Алексей Дмитриев
24.12.2010, 00:07
К тому же "корни" мои растут из прикладного программирования и Паскаля. И хотя программированием контроллеров занимаюсь уже не мало, предпочтения остались.
Кроме того "буржуйской" техникой без крайней необходимости стараюсь не пользоваться. Кроме плюсов есть и минусы, такие как сроки поставки. Иногда приходилось по 5-6 месяцев ждать.
А вообще спасибо за советы. Есть над чем подумать.
Кстати по теме - У Вас какое образование? Имею в виду, что "классические программисты" обычно очень тяжело привыкают программировать на МЭКовских языках, а инженеры по автоматизации делают это очень легко (если не дураки, конечно:D ). В программировании контроллеров очень важно знать теорию автоматического управления. Все эти МЭКовские языки изначально создавались для инженеров-электриков, которые привыкли к релейным схемам, отсюда и представление кода такое.:rolleyes:
Сроки поставки буржуйской техники это что-то, согласен, но надежность и предсказуемость поведения системы окупают это неудобство. Советую брать все от одного производителя, будете делать все действия с системой из одного проекта и программного пакета, и шнурки не надо дергать - то в контроллер, то в привод, то панель оператора!
to Алексей Дмитриев
Вы спросили как можно обработать на паскале 300 булей - я Вам показал.:) Но удивительным образом так же это делается на ST.
И причем здесь окошки ?
:.Ваше FOR TO DO катит только для обработки массива.
Ну да - это самый простейший обработчик для массивов. А это Вы к чему ?
Для всего - свой инструмент. А плк это не только релейные схемы. К счастью.
PS
И вообще-то, я всего-лишь показал, что обработать 1000di и 500do - можно и на 1 плк.Причем не на каком языке, а на каком оборудовании.
И опять про мифических классических программистов.:)
Кстати по теме - У Вас какое образование? Имею в виду, что "классические программисты" обычно очень тяжело привыкают программировать на МЭКовских языках, а инженеры по автоматизации делают это очень легко (если не дураки, конечно:D ). В программировании контроллеров очень важно знать теорию автоматического управления.
Образование у меня самое что ни на есть правильное)))) - Автоматизация технологических процессов и производств в машиностроении. Но это было уже потом, а в начале я самостоятельно осваивал программирование (начиная с Паскаля). С МЭКовскими языками проблем нет - работал практически со всеми. Просто предпочтение отдаю ST, поскольку мне это более привычно. Остальные использую по мере необходимости. Что касается ТАУ, то не для всех задач это так уж необходимо. Когда требуется регулирование, то да. Но мне обычно приходится решать чисто логические задачи.
Алексей Дмитриев
24.12.2010, 15:20
Я, собственно не ТАУ имел в виду, а Булеву алгебру. Все чисто логические задачи решаются с помощью ее, однако...;)
Я вообще начинал с приемников прямого усиления, программировал аналоговые вычислительные машины и т. д.
Алексей Дмитриев
24.12.2010, 15:29
И опять про мифических классических программистов.:)
Дались Вам эти классические программисты,если не знаете, отвечу - во многих ВУЗах есть специальность "Прикладная математика". Вот те, кто там учился - оне и есть!:D
Из жизни - приходит к нам на работу устраиваться "классический программист", спрашиваю
- Булеву алгебру знаешь?
- Да, конечно!
- Сколько будет 1+1?
- Два!
- До свидания.
Как еще объяснить, не знаю.
Я, собственно не ТАУ имел в виду, а Булеву алгебру. Все чисто логические задачи решаются с помощью ее, однако...;)
Я вообще начинал с приемников прямого усиления, программировал аналоговые вычислительные машины и т. д.
ТАУ и булева алгебра - это немного разные вещи. "Чисто логические" задачи - здесь каждый, наверно, по своему поймёт. А вообще я не пишу простых программ, типа "сработал датчик BQ1, выключить двигатель M1". Поэтому ни булевой алгеброй, ни дискретной математикой, ни ТАУ в моём случае не обойтись. Хотя всё это используется при необходимости. Вы же понимаете, что в более менее сложных проектах технологические процессы не являются тривиальными. Поэтому тут нужен творческий подход. И я считаю, что знание таких вещей, как, например, объектно-ориентированное программирование, очень сильно помогает. Отчасти этим и объясняется выбор языка ST как основного.
Алексей Дмитриев
28.12.2010, 01:04
С помощью булевой алгебры можно описать любой сложности логический алгоритм. Если нужно обслужить какой нить хитрый девайс, или массивы обработать, че-нить хитрое посчитать, типа тригонометрии, то конечно проще на ST написать.:p
Александр Приходько
28.12.2010, 10:11
Споров о том какой из языков удобнее очень много. По большому счету каждому программисту удобнее использовать то, на чем он умеет писать.
Из своего опыта могу сказать, что наиболее гибким языком является ST, т.к. в нем можно писать сложные условия сравнений, циклы, удобно реализовывать сложные математические вычисления. Но к сожалению у многих программистов с данным языком бывают затруднения, и тяжело читаем код, особенно если он не содержит комментариев.
На втором месте язык CFC. Он нагляден, не требует особых знаний синтаксиса, упрощает вызов ФБ. Если задача представляет собой булеву алгебру, то данный язык для такой задачи идеален. Минус в том, что очень сложно и неудобно реализовывать условия и переходы. Зачастую если программа сильно разрастается, то замена одного элемента схемы может превратится в головную боль.
Еще одним интересным языком может выступать SFC. Если задача легко бьется на этапы, то структура самой программы легко организуется на этом языке, а вот каждый из этапов уже можно описать на каком либо другом языке.
Все остальные языки менее популярны.
Наименее гибким является язык релейной логики, т.к. позволяет легко реализовывать "Электрические цепи" но крайне неудобен для вычислений.
Александр Приходько
29.12.2010, 10:24
Чаще всего тяжелое чтение связано со способом написания и неумеренное использование IF' ов c c вложением в несколько уровней.Убил того, кто крикнул - "ПРОГРАММИРУЕМ БЕЗ ГОТО!"
А что касается комментариев, то иногда лучше б их совсем небыло:
i:=i+1; (* увеличиваем i на единицу *)
IF A>B (*Если А больше Б*) AND C < D (* С меньше D*) THEN
MOTOR:=TRUE; (*Включаем мотор*)
ELSE
MOTOR:=FALSE;(*Выключаем мотор*)
END_IF
В принципе, код можно писать вообще без комментариев. Говорящие названия используемых объектов c использованием стиля "Весь поу на одном экране" практически полностью решают проблемму комментов.
Всего лишь пояснить назначение поу, и все. А иногда и этого не надо.
Что касается комментариев и оформления кода. Существуют правила оформления кода. Например: http://live.nsk.ru/2008/03/25/standats/
Если их хоть немного соблюдать, а комментарии делать смысловые, а не расшифровку операции, то тогда код будет очень понятным.
Убил того, кто крикнул - "ПРОГРАММИРУЕМ БЕЗ ГОТО!"
Я бы ещё крикнул - "ПРОГРАММИРУЕМ БЕЗ ЦИКЛОВ!"
потому как, теоретически, все задачи (даже обработку массива) можно сделать одним рабочим циклом)))
Я своё знакомство с ПЛК начинал с изучения STEP 7. И для меня, для человека никогда до этого не имевшего дела ни с каким программированием, это было настоящим стрессом. Прочитал всё, и GettingStarted и PRO1, PRO2 и Bergera. Полная каша в голове, никакой системы знаний. Синтаксис на языке IL вообще не описывается. Какой-то непонятный аккумулятор...(с аккумулятором уже потом разобрался). Худо, бедно ещё как -то LD понятен был, да и то куча вопросов. Примеров вроде много, а последовательность их создания никак не описывалось. Создавалось впечатление, что вся эта литература для уже продвинутых специалистов или тех, у кого IQ зашкаливает.
Я не могу похвастаться высоким IQ (у меня он 90), поэтому, когда мне попался CoDESys в руки, для меня это было настоящим открытием. Я за месяц его изучения продвинулся гораздо дальше , чем за полгода изучения STEPа, и на многие вопросы появились ответы. Начинал его изучать с LD, как действительно более наглядного. А теперь мне почему-то понравился ST. Поэтому, сейчас, я всем рекомендую изучать CODESYS...
CoDeSys и ПЛК изучаю самостоятельно используя интернет и, конечно форум, не скажу, что легко, было сложно пока не заработали примеры в симуляции с использованием визуализации а потом и с ПЛК. Начинал с LD, так как уже был опыт программирования ZELIO на LD. Теперь, после программирования на ST, CFC, SFS, возвращаться к LD или FBD и нет желания. Пробую сейчас изучать STEP-7 и SIMATIC PCS7. С МЕК-языками еще более менее понятно, но системный подход совсем другой, и думаю а нужно ли? А не проще переубедить заказчика, что кроме Сименса есть еще и другие ПЛК, а как это сделать? Или искать другого заказчика, хотя в кризисный период это не просто.
Николаев Андрей
12.01.2011, 10:40
Скажу сейчас крамольную вещь, но кроме ОВЕН еще очень много ПЛК, программируемых CoDeSys
Спасибо за самокритичность, но ИМХО ОВЕН за счет открытости займет достойное место в индустрии автоматики!
Другие контроллеры я также расматриваю, но SIMATIC CPS7 как мне кажется достойный ответ на СоDeSys?
Николаев Андрей
13.01.2011, 10:30
Достойный. Кто бы спорил.
Но есть открытые системы, типа CoDeSys, как Вы сами сказали - за ними будующее...
А есть Simatic для одной, уважаемой мной компании, и еще группы "рядом живущих".
Попробуйте договорится, чтобы Ваши контроллеры программировались из их среды... :)
Алексей Дмитриев
17.01.2011, 23:00
Вообще в степе 7, на самом деле ничего сложного нет, просто отвратительная документация, она у симатика вся такая, не только на контроллеры.
Со степой начал работать раньше, чем с кодесисом, но чем понравился кодесис - не пришлось вообще читать мануал, насколько все просто и адекватно. Встроенного хелпа более чем достаточно.
lara197a
18.01.2011, 00:32
Степ 7 -это мать прородитель, на него все равняются.
Конечно из-за древности есть неудобства, но скажите, где еще такая система диагностики?
А хардвер степ 7!\ смотрел я КДС3.4, для ПЛК 304 - неудобно.
А так в КДС 2.3 интерфес более дружественный.
Алексей Дмитриев
19.01.2011, 22:12
По поводу матери это Вы сгоряча завернули. Отэц этой техники это конечно Allen Bradley. Есть свои прелести, конечно, но проблемы их затмевают. Особенно прикалывает рудиментарный STL с его неудобочитаемым синтаксисом, оставшийся еще со времен CP-M. Пока пишешь, помнишь что и зачем, через неделю уже нет. Еще надо помнить какой ОБ для чего, много рудиментов от 5-ого.
Николаев Андрей
20.01.2011, 11:55
И че спорим???
Один - мать, второй - отец :)
:D
Зря спорите: папой было подразделение General Motors Hydra-matic, а мамой господин Robert Morley с компанией Modicon.
http://www.plcdev.com/plc_timeline#comment-390
Powered by vBulletin® Version 4.2.3 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot