Сурово...
А вот приезжайте в мае на конференцию, поговорите с Дитером, а потом всем форумчанам и расскажите.
Причем на сколько я понимаю Игорь приглашает всех желающих присоединиться.
Сурово...
А вот приезжайте в мае на конференцию, поговорите с Дитером, а потом всем форумчанам и расскажите.
Причем на сколько я понимаю Игорь приглашает всех желающих присоединиться.
Полностью согласен с pike
перенос кода на мой взгляд это ерунда.
разные контроллеры на то они и разные, в каждом могут быть реализованы свои аппаратные фичи, реализованы по разному, Ограничивать производителей рамками готовой среды?
Смотрел недавно Фестовские контроллеры, очень сомневаюсь что можно проект полностью перенести на Овен. впечатление что невозможно, кое чего не хватает у Овена.
На мой взгляд: хочешь использовать другой контроллер, сначала нужно изучить его матчасть(железо), а чем он программируется, уже большого значения не имеет, те кто работает с контроллерами, как правило умеют писать на разном, в том числе и для компов, скад, панелей.
Эаказчики, не сидящие плотненько на каком-то бренде, как правило это единичные небольшие заказы, не настаивают на оборудовании того-или иного производителя, Ну а если хочешь работать с постоянным клиентом, тут два варианта, или учи то что он использует, или обладая репутацией переводи его на те бренды которые используешь, поверте, переходят.
Когда производители делают конвертеры с одного бренда на другой, делают только под свой бренд, что-бы покапателя легче переманить.
Усё есть, и даже молоденькая серияСообщение от Николаев Андрей
SIEMENS S7/1200 (Ethernet)
SIEMENS S7/200
SIEMENS S7/200 (Ethernet)
SIEMENS S7/300
SIEMENS S7/300 (Ethernet)
SIEMENS S7/300 MPI
SIEMENS S7/400 Ethernet
SIMATIC TI505
совместимость интерфейсов переходниками производителя панелек.
И при чём здесь входа выхода, любая переменная запрашивается по адресу, в том числе и системные.
Отстали с такой сеткой очень сильно, сравните с омроном, там уже очень давно можно подключившись к одному контроллеру программировать другой, и даже настраивать частотник, сервак, терморегулятор. через несколько сетей и контроллеров, кое что пользовал, удобно однако сидя в кипе или другом городе не перется в цех из-за проблем с частотником. Если речь идёт об обмене контроллера с контроллером, то то-же проблем нет.
Про сеть и адреса. Наваял программист программу на контроллер, скаду пишет другой, причём скада ужасно большая и требует пару тысяч переменных с контроллера, причём скад висит несколько, у оператора, технолога и допустим резервная.
как оптимизировать время опроса, что-бы летало а не тормозило? Естественно собрать переменные в пакеты, как это сделать в кодесисе для его родного протокола?(без модбаса, настроить его в кодесисе на пару тысяч переменных, офигеть можно) Я не знаю как работает кодесисовский протокол без адресов, и было-бы интересно возможно ли в нём передача за раз нескольких десятков переменных?
а с адресами всё просто, программист контроллера решает свою задачу, потом выясняет с программистом скады компоновку пакетов для связи и просто меняет адреса у нужных переменных так что-бы они располагались подряд, причём в омроне это делается очень быстро через эксель и копипасту, всё переменные лежат в памяти подряд и их можно забирать по связи пакетами.
Последний раз редактировалось BETEP; 16.02.2011 в 12:31.
Да, только Дитер обычно отвечает более разумно и обоснованно
Пользователь: Доколе в CoDeSys LD будет представлен в противозачаточном варианте начала 80-х. Где нормальная работа с фронтами сигналов? Где нормальные компараторы? Где...? Доколе едиственным рабочим языком в КДС будет ST, а остальные для галочки?
Дитер: Ну, дак есть ведь стандарт и все дела. Мы вам ООП подготовили.
...
- Дальше подходит группа людей и говорит: Сколько можно терпеть это безобразие? Когда ж наконец вы выбросите это убожество, именуемое LD и IL вместе с ним целиком? Дайте нам полноценный оператор New. Когда будут человеческий интерфейс для QNX? Без этого вообще работать никак. И др. и пр.
Не все так однозначно. Приходится обсуждать, расставлять приоритеты. Для этого и конференция.
Про фронты я согласен, что штука была удобная в старых системах. В МЭКе придумали блочки-детекторы фронтов, которых может быть неограниченное число и вставлять их можно где угодно, совершенно одинаковым образом. В плюс имеем единообразие подхода – вставлять можно любые блоки, а не только ограниченный набор узко избранных операций (детекторы и компараторы). Сверх того, программа легко преобразуется на любой язык. В V3 вообще можно на ходу переключать отображение. Удобно. Стоит ли возвращаться к домэковскому варианту? Эту тему уже обсуждали на конференции. Спросите где результат? В CoDeSys V2.3.9 появилась кнопочка на панели инструментов редактора LD для вставки детектора фронта одним кликом.
У меня вопросик созрел.
Внутри омроновского ФБ можно вызвать другой фб и так несколько уровней.
естественно изменение фб одного из уровней изменит всё.
Это и есть ООП?
Нет. Это обычные вызываемые процедуры.
Не уверен,
Сам омронвский фб по определению класс.
из которого потом и создаются фактически объекты, при компиляции.
Разный подход...мне удобнее иметь бесплатную среду программировани, поскольку за ПЛК платит заказчик. А я выбираю ПЛК под задачу и не готов платить за каждую установку ПО (в том числе маятся с аппаратным ключём защиты), всё дело в затратах....мне лишние не нужны....
Однако, за непереносимость идет частая критика. С другой стороны изготовители ПЛК умышленно стараются сделать вкусности – свои ноу-хау которые на других платформах работать не будут.
Переносимость своего ПО бывает крайне нужна. Например, есть одна очень известная фирма, которая оснащает целые заводы и линии под ключ. Весь прикладной софт написан в CoDeSys, программы огромадные. В разных странах они ставят разные ПЛК, с учетом местных цен, опыта и пожеланий заказников. Выгода уже измеряется шестью нулями (в Евро).
Возможность должна быть. В CoDeSys можно постараться и написать переносимую программу. Ест-но, про это надо думать сразу и не применять всякие специфичные штуки. В V3 вместо системных появились СAA биб-ки, предкомпиляция кода, интерфейсы и управления версиями. Эти усилия предприняты именно для переносимости.
Хорошо! Свободно, без компромиссов выбираю оборудование десятка любимых фирм (включая ОВЕН), строю дюжину уровней на разных сетях и все это в Омрновской среде программирую. Так? Либо я вынужден везде применять Омроновские продукты, с их пятизначными ценниками?
Нет.
Намек - полиморфизм.
В этом месте я целиком и полностью согласен: это убожество надо убрать, что бы не вводить людей в заблуждение и честно писать, что в КДС есть полтора полноценных языка программирования ST+SFC.
Это придумали до МЭК и к 93 году уже начали (с ростом производительности плк) вводить другие "формы" обработки сигналов по фронту, которые делали представление программы более компактной и "читаемой".
К какому доМЭковскому варианту? Стандарт в плане LD устарел в момент выхода, а сейчас уж тем более. Вам намекают на то, что пора бы начать догонять.
А в целом разговор выглядит, как я представил выше: программера с инженером, один про структуры и внутренее единообразие, другой про болты и гайки.
Ваши права
Ответить с цитированием