Регистрация | Последние сообщения | Персональный список | Поиск | Настройка конференции | Личные данные | Правила конференции | Список участников | Top 64 | Статистика раздела | faq | Что нового v.2.3 | Чат
Skunk Forum - Техника, Наука, Общество » АСУТП »
Кто работал(ет) с контроллерами Bekhoff? (страница 2)

Версия для печати (настроить)
Страницы: 1 2 3 4

Новая тема | Написать ответ

Подписаться

Автор Тема:   Кто работал(ет) с контроллерами Bekhoff?
Dmitry M. Gaidash
Member

Сообщений: 120
Регистрация: Сентябрь 2005

написано 17 Января 2007 12:27ИнфоПравкаОтветитьIP

Другое дело в помехозащищенности и расстояниях
Вопрос на раз-два решается оптикой.

IP
Member

Сообщений: 44
Откуда: Russia
Регистрация: Июнь 2006

написано 17 Января 2007 15:01ИнфоПравкаОтветитьIP

ИМХО про разный уровень техники:
Немцы действительно делают очень качественное железо и отличное инструментальное ПО. Это кстати сложнее. Если посмотреть на оригинальные контроллеры (в данном случае VIPA), которые передрали китайцы, то к монтажу придраться практически нельзя, литье корпуса похуже, содрать же ПО не удалось вовсе...
Есть миф, что немцы аккуратные и педантичные, поэтому делают хорошую технику. Это полная ерунда, разгильдяев у них больше чем у нас, наши инженеры делают меньше ляпов. Передовая техника разрабатывается ими по другим причинам, гораздо более прозаичным. Они вынуждены это делать, вынуждены бросать все силы на автоматизацию, поскольку иначе местное производство не выдерживает конкуренции с дешевым импортом. В странах, где есть богатые природные и людские ресурсы нет объективных причин развивать технологии и никакие правительственные программы тут не помогут.
Т.е. на немецкие контроллеры и ПО можно делать ставку, они будут продолжать идти впереди других в ближайшие годы, выбора у них нет, потенциал же есть.

Из 1200 компаний участвовавших в выставке SPS/IPC/DRIVES 2006 слов 'RS485' и 'Modbus' на стендах не было ни у кого. Да использовали массово, но это было лет 10 назад… Ethernet повсеместно, к PC стыкуется в лоб, никаких хитрых переходников покупать не надо все, что надо для монтажа есть в любой ближайшей компьютерной лавке, стоит копейки…

ПО Beckhoff есть смысл изучать, даже если не использовать их контроллеры. CoDeSys штатно поддерживают большинство западных изготовителей ПЛК (кроме Шнайдера и Сименса). Сейчас Beckhoff и Wago переходят на CoDeSys 3.0, а это уже серьезный шаг вперед в сравнении с устаревающим стандартом МЭК 61131-3.

Кстати Beckhoff на выставке ПТА в Москве показывали очень интересный опыт. Загруженная сеть EtherCAT из нескольких десятков ПЛК. К одному из них на 2 обычных аналоговых входа подключили выход стерео проигрывателя. К другому ПЛК на аналоговые выходы – активный динамики. Качество звука очень даже приличное!
EtherCAT соединяется короткими сегментами, расстояние не проблема, можно делать кольцо, резервирование работает автоматом, без каких-либо усилий со стороны программиста, рвать/соединять можно на ходу.

Глюки в ПО конечно есть, но радует что они не от застоя а, наоборот. В каждом новом патче найденные исправляются, новые естественно добавляются. Поэтому есть смысл не брать самую свежую версию, а взять предшествующую к которой уже есть таблица известных глюков.
Кстати в настоящее время Beckhoff так и делает. Патчи TwinCAT несколько отстают от CoDeSys по причине дополнительного тестирования.

Павел Мощицкий
Member

Сообщений: 1776
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 17 Января 2007 15:15ИнфоПравкаОтветитьIP

GSM
Не согласен.
Вы говорите про конечную цену, а я про себестоимость. В угоду конкуренции производителям приходится уменьшать моржу.
Другое дело в помехозащищенности и расстояниях.
Тоже цена. Нужно ставить промышленные хабы и тащить в идеале, оптоволокно. Хотя, кто будет?

Dmitry M. Gaidash
Member

Сообщений: 121
Регистрация: Сентябрь 2005

написано 17 Января 2007 17:34ИнфоПравкаОтветитьIP

Павел Мощицкий
Хотя, кто будет?
Кому важен результат, тот и будет этим заниматься.

bessonov2
Member

Сообщений: 56
Регистрация: Май 2006

написано 17 Января 2007 21:09ИнфоПравкаОтветитьIP

GSM
Может быть ламерство, но IMHO в компьютерах данный буфер тоже 16 байт. Если имеется в виду буфер FIFO. Во всяком случае если залезть в настройки винды, то там его можно только уменьшить. Или здесь речь идет о чем то другом?
Жа нет, всё о том же. Стандарт да, 16 байт. Но проц icpdas-8000 медленный. Поэтому если с пентиума сотого послать 250 байт на скорости 115200, то icpdas-8000 захлебнётся, получит только первые 16 байт, не успеет их извлеч как остальные уже пролетят.

Для уменьшения нагрузки на проц, чтобы пореже дёргать его прерывания буфер FIFO делаю больше, пример:
ссылка
ссылка


Когда начинали работать с данными контроллерами, то ModBus ASCII протокола еще не было.
Я имел ввиду не Modbus ASCII, а их собственный, который предназначен для их модулей ввода/вывода.

GSM
Member

Сообщений: 36
Откуда: Россия, Челяб. обл, г Миасс
Регистрация: Ноябрь 2006

написано 18 Января 2007 13:04ИнфоПравкаОтветитьIP

Павел Мощицкий
Вы говорите про конечную цену, а я про себестоимость. В угоду конкуренции производителям приходится уменьшать моржу.
Тут согласен. Но меня как разработчика систем интересует именно конечная цена изделия.

Builder
Junior Member

Сообщений: 10
Откуда: Минск
Регистрация: Июль 2006

написано 18 Января 2007 13:26ИнфоПравкаОтветитьIP

Жа нет, всё о том же. Стандарт да, 16 байт. Но проц icpdas-8000 медленный. Поэтому если с пентиума сотого послать 250 байт на скорости 115200, то icpdas-8000 захлебнётся, получит только первые 16 байт, не успеет их извлеч как остальные уже пролетят.

IMHO. Никаких обективных причин для данного не вижу, особенно учитывая, что там операционока - типа DOS. Т.к. обеспечить время реакции на аппаратное прерывание ~100мкс в DOS подобных системах не проблема. И то что там проц 40МГц - не помеха для этого.

Для уменьшения нагрузки на проц, чтобы пореже дёргать его прерывания буфер FIFO делаю больше, пример:
Согласен, большой буфер - что-бы уменьшить количество прерываний. Но это не значит, что описанный вами эффект с 16-ю быйтами должен быть в icpdas-8000. Проблема если и есть, то из-за реализации программы, а не используемого процессора.

bessonov2
Member

Сообщений: 57
Регистрация: Май 2006

написано 18 Января 2007 22:39ИнфоПравкаОтветитьIP

Builder
Проблема если и есть, то из-за реализации программы, а не используемого процессора.
Тогда почему на 9600 по RS-485 всё нормально, а на 115200 нет?

Builder
Junior Member

Сообщений: 11
Откуда: Минск
Регистрация: Июль 2006

написано 19 Января 2007 00:38ИнфоПравкаОтветитьIP

bessonov2
Тогда почему на 9600 по RS-485 всё нормально, а на 115200 нет?
А кто-ж его знает. Я не знаю ни условий сбоя, ни того, как сделан софт в контроллере.
Я лишь утверждаю, что принципиально, принять 250 байт на скорости 115200 на этом проце - не проблема.
Могу только предположить. Например если закачивать в контроллер большой объём данных, то контроллер "захлебнётся", переполнятся програмные буфера.
Или может там програмный буфер не большой, скажем 128 байт. Вы зашлёте 250 байт, проц не успеет всё обработать - получим сбой.

Я согласен с Вами в том, что более скоростной проц сможет обрабатывать больший поток данных.
Сам я лишь утверждаю, что и не крутой проц может обмениваться данными на достаточно большой скорости, но объёмы этих данных будут не большими.

А вообще, ICP DAS не плохо реагирует на запросы по проблемам, стоило-бы им сделать запрос - пусть ответя, почему в Вашей ситуации на 115200 что-то не так как Вы хотите.

Павел Мощицкий
Member

Сообщений: 1780
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 19 Января 2007 01:16ИнфоПравкаОтветитьIP

bessonov2
Тогда почему на 9600 по RS-485 всё нормально, а на 115200 нет?
ПО каждого контроллера должно обрабатывать собственные нужды и чем меньше времени тратится на периферию, тем больше остаётся на себя. Главное, чтобы не было окошка нечуствительности.

GSM
Member

Сообщений: 37
Откуда: Россия, Челяб. обл, г Миасс
Регистрация: Ноябрь 2006

написано 19 Января 2007 07:02ИнфоПравкаОтветитьIP

Builder
А вообще, ICP DAS не плохо реагирует на запросы по проблемам, стоило-бы им сделать запрос - пусть ответя, почему в Вашей ситуации на 115200 что-то не так как Вы хотите.
Они неплохо реагируют если проблема явная. Т.е. например функциональный блок не работает или работает не так как надо. Делаешь тестовую прогу - отправляешь ее с коментариями - ну и в срок до 2-х недель обычно устраняют.
А вот если ситуация плавающая..... У меня, например было такое. Сеть по 485, мастер и 7 контроллеров. И в какой-то момент один из контроллеров почему-то переставал отвечать на запросы от мастера. Прололжалось это где-то 3-5 мин, затем связь восстанавливалась. Пробовал анализировать трафик - запрос на данный контроллер приходит корректно. Ответа нет. Почему? Написал в ICP DAS. Выслал тексты программ и сетевой трафик. Поначалу посоветовали подкорректировать программу на мастере(использовал самописный модбас протокол). Подкорректировал в соответствии с рекомендациями. Эффект не исчез. Снова пишу. Ответа нет. Раза 2-3 писал, ответа нет. Да и на проблему, которую я описывал в соседней ветке тоже не хотят отвечать. Причем данная проблема, как я пообщался здесь в форуме, не только у меня.

bessonov2
Member

Сообщений: 58
Регистрация: Май 2006

написано 19 Января 2007 21:51ИнфоПравкаОтветитьIP

Builder
Сам я лишь утверждаю, что и не крутой проц может обмениваться данными на достаточно большой скорости, но объёмы этих данных будут не большими.
Если 250 байт разбивать на пакеты по 16 байт и посылать пакеты на icpcon-8000 с задержкой(подобрана эксперементально), то в конечном счёте 250 байт приходят, но зато увеличивается время передачи данных.

А вообще, ICP DAS не плохо реагирует на запросы по проблемам, стоило-бы им сделать запрос - пусть ответя, почему в Вашей ситуации на 115200 что-то не так как Вы хотите.
К счастью эта проблема для меня уже не актуальна. Вообще по хорошему, проблемы с временами и задержками должны быть изначально решены производителем на низовом уровне, как с Profibus у Сименса.

Сам я лишь утверждаю, что и не крутой проц может обмениваться данными на достаточно большой скорости, но объёмы этих данных будут не большими.
Зависит от того, как проработана железка и софт. Насколько я понимаю в этом плане выгодно отличается MOXA.

И в какой-то момент один из контроллеров почему-то переставал отвечать на запросы от мастера. Прололжалось это где-то 3-5 мин, затем связь восстанавливалась.
Может железо контроллера подгючивает. Попробовать поменять контроллер, посмотреть как чего будет. Может контакт на 485 плохой.

bessonov2
Member

Сообщений: 60
Регистрация: Май 2006

написано 20 Января 2007 02:02ИнфоПравкаОтветитьIP

IP
Передовая техника разрабатывается ими по другим причинам, гораздо более прозаичным.
Не согласен. Есть мнение (не моё), что после второй мировой войны Япония и Германия могли обращать внимание только на свою экономику, а в плане оборонки финансовых затрат у них не было. Дополнительный катализатор развития промышленной автоматики - культура Японии и Германии. Любят они делать всякое такое интересное.

Они вынуждены это делать, вынуждены бросать все силы на автоматизацию, поскольку иначе местное производство не выдерживает конкуренции с дешевым импортом.
Эта проблема появилась сравнительно не давно. Сейчас Китай всех заваливает своей продукцией.

В странах, где есть богатые природные и людские ресурсы нет объективных причин развивать технологии и никакие правительственные программы тут не помогут.
Не согласен. Если бы так было, у нас бы жилось не хуже чем в Германии и Японии, т.е. необходимость в автоматизации есть. Тем более ресурсы наши не бесконечны. Стоимость добычи нефти в Сибири последние несколько лет постоянно растёт. Запасы нефти становится всё больше трудноизвлекаемые, при том что там -55 по цельсию легко, в отличии от стран Персидского залива. Сейчас уже цены на бензин у нас такие же как в США. Т.е. проблема не в ресурсах, а в чёмто другом...

Т.е. на немецкие контроллеры и ПО можно делать ставку, они будут продолжать идти впереди других в ближайшие годы, выбора у них нет, потенциал же есть.
По технологиям различные немецкие контроллеры пока держат планку, однако азия тоже не плохо копирует их идеи. Некоторые изделия делает по крайней мере удобней. А в плане сложного софта азия пока вроде не прославилась.

IP
Member

Сообщений: 45
Откуда: Russia
Регистрация: Июнь 2006

написано 23 Января 2007 12:08ИнфоПравкаОтветитьIP

Если бы так было, у нас бы жилось не хуже чем в Германии и Японии, т.е. необходимость в автоматизации есть. Тем более ресурсы наши не бесконечны. Стоимость добычи нефти в Сибири последние несколько лет постоянно растёт...

Если нефть будет легко добываться и дорого продаваться, то мне станет хорошо?
Как это? В смысле, что компании, имеющие с этого прибыль, вдруг сойдут с ума и станут делиться со всеми желающими? Либо государство все приберет к рукам (верю) и станет все средства вкладывать в соц. программы и дороги как Норвегия (не верю)? Какое мне дело до цен на нефть? Ох, ах беда - нефть упала => нефтяники пострадали => бензин подорожал, ой нефть растет => бензин естественно дорожает. Вот и все развлечение. Увеличили цены на газ для Украины, возможно у кого-то из олигархов повысилась зарплата, мне от этого стало значительно хуже - таможня гайки закручивает, отношение людей плохое, в родной Крым не съездить, Украинской компании сейчас реально проще заказать работу в Германии, чем в России. Теперь и с Белоруссией такая же ерунда. К нам заказчик просто не смог доехать, таможня (наша!) потребовала оформлять временный ввоз личного автомобиля!

Ближе к теме, Beckhoff покупать вполне можно. Личной выгоды в этом нет, даже напротив, я бы поддержал введение зверских пошлин на импортные контроллеры. Своих надо поддерживать -

Dmitry M. Gaidash
Member

Сообщений: 124
Регистрация: Сентябрь 2005

написано 23 Января 2007 23:08ИнфоПравкаОтветитьIP

IP
Насчет нефти Вы не правы Достаточно вспомнить почему СССР развалился

IP
Member

Сообщений: 46
Откуда: Russia
Регистрация: Июнь 2006

написано 26 Января 2007 11:12ИнфоПравкаОтветитьIP

Приезжайте к нам 22,23 мая на ежегодную конференцию по CoDeSys. Будем обсуждать идеи развития МЭК систем (расширения языков, добавление ООП, распределенного программирования и др.) непосредственно с руководством компании 3S. Любые позитивные мысли, что нужно включить в CoDeSys 3.0. приветствуются, критика тем более. Посмотрим на новинки изготовителей ПЛК. Представитель Beckhoff Automation GmbH уже приглашен. Есть вопросы, которые хотелось бы задать, они разрабатывают несколько пионерских вещей информация, по которым пока вообще недоступна.
Вечером проведем симпозиум по выше обозначенным вопросам (Насчет нефти...) -
Регистрация участников на сайте www.codesys.ru с 1 марта.

Dmitry M. Gaidash
Member

Сообщений: 126
Регистрация: Сентябрь 2005

написано 26 Января 2007 13:47ИнфоПравкаОтветитьIP

IP
К сожалению, с CoDeSys мы вряд ли будем работать в обозримом будущем - полноценная поддержка SIMATIC'а в нем не планируется, насколько мне известно, а значит в круг моих профессиональных интересов это не попадает. Хотя, я был бы очень рад наличию альтернативы сименсовских средств разработки... Но это уже чисто по-человечески, между нами

Chupakabra
Junior Member

Сообщений: 6
Регистрация: Февраль 2007

написано 01 Апреля 2007 11:54ИнфоПравкаОтветитьIP

А кто-нибудь работал с CX-ми ихними, особенно интересует CX9000.

znp
unregistered
написано 06 Апреля 2007 16:27  ПравкаОтветитьIP

"А кто-нибудь работал с CX-ми ихними, особенно интересует CX9000."

А какие у Вас вопросы - по ПО или по аппаратной части?

Chupakabra
Junior Member

Сообщений: 8
Регистрация: Февраль 2007

написано 06 Апреля 2007 22:05ИнфоПравкаОтветитьIP

По стабильности работы в качестве ПЛК без визуализации. Ведь на нем WinCE. Сколько загружается?

Dmitry M. Gaidash
Member

Сообщений: 194
Регистрация: Сентябрь 2005

написано 07 Апреля 2007 13:58ИнфоПравкаОтветитьIP

Chupakabra
WinCE - это весьма надежная ОСРВ, на уровне QNX и уж куда надежнее модификаций DOS-а, который частенько пихают в PC-совместимые (и не только) контроллеры.

Ваш ответ:

Коды форума
Смайлики


Ник:    Пароль       
Отключить смайлики
Страницы: 1 2 3 4

Все время MSK

Склеить | Разбить | Закрыть | Переместить | Удалить

Новая тема | Написать ответ
Последние сообщения         
Перейти к:

Свяжитесь с нами | skunksworks.net

Copyright © skunksworks.net, 2000-2018

Разработка и техническая поддержка: skunksworks.net


Рейтинг@Mail.ru Яндекс.Метрика