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

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

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

Подписаться

Автор Тема:   Какое железо выбрать?
Dmitry M. Gaidash
Member

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

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

IP
Зачем Вы их пишете? Почему возникает такая необходимость?
Потому что есть целый зоопарк оборудования с доморощенными протоколами, с которым необходимо стыковаться на объектах. Также есть куча железок с MODBUS'ом - там скорее не написание драйвера, а конфигурирование, но тоже на SCL все делается при необъодимости.

Т.е. я могу разработать и спаять свой модуль
Можете Но при этом надо будет соблюдать определенные правила, конечно. Терминология используется совсем другая (никаких векторов прерываний и прямого доступа к памяти нет), но это не мешает состыковаться практически с любой железкой по интерфейсу RS232/422/485. А с использованием преобразователей интерфейсов возможностей еще больше - в ближайшей перспективе будем прикручивать к Siemens'у CAN/DeviceNet.

Simaticov
Member

Сообщений: 53
Откуда: Russia
Регистрация: Январь 2007

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

цитата:
IP писал:
2)Т.е. я могу разработать и спаять свой модуль (например, специализированный счетчик импульсов) ввода/вывода, подцепить к процессору контроллера, написать на языке SCL полноценный драйвер, который будет захватывать соответствующий вектор аппаратного прерывания, открывать канал прямого доступа к памяти, копировать данные и т.п.? Другими словами, с помощью SCL мне доступны все возможности процессора или для драйверов придуман некий усеченный интерфейс в который я должен вписаться при разработке железа?

Судя по вопросу не очень то разбираешься в закрытой архитектуре промышленных неРС контроллеров.
Каким образом ты собираешься получить прямой доступ к памяти при использовании внутренней последовательной шины обмена процессора с внешними модулями и отсутствии
соответствующих разъёмов на контроллере?

"Подцеплять к процессору контроллера" как то не принято в нашей области.
Видима путаница с открытой РС архитектурой.
Для интерфейсных целей существуют специальные интерфейсные мелкосхемы - одна сторона общается с процессором по внутренней шине (у простых систем последовательной SPI образной, есть и параллельные как у Vipa Speed7), а с другой вешай свою периферию.
Для внешних модулей на RS485 всё ещё проще - пиши текстовый файл описаний ГСД для подсовывания в каталог железа компилятора.
По такому принципу многие железячные конторы делают совместимые с различными брэндами изделия.

IP
Member

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

написано 16 Июня 2007 13:59ИнфоПравкаОтветитьIP

цитата:
Simaticov писал:
Судя по вопросу не очень то разбираешься в закрытой архитектуре промышленных не РС контроллеров.

Наверняка я знаю не все. Их довольно много и очень разные.
Вы имеете в виду одну свою конкретную архитектуру. Причем функции нижнего уровня уже поддержаны в системном ПО. Далее все действительно просто.

Честно сказать, для меня смысл участия в подобных форумах – это сбор и отработка идей по совершенствованию CoDeSys. Цель примитивно проста: сделать его лучшим в мире, а не одним из… Спасибо за любую помощь в этом деле

цитата:
Dmitry M. Gaidash писал:
...(никаких векторов прерываний и прямого доступа к памяти нет), но это не мешает состыковаться практически с любой железкой по интерфейсу RS232/422/485. А с использованием преобразователей интерфейсов возможностей еще больше...

В CoDeSys есть так называемые системные библиотеки. Это простые низкоуровневые функции, реализация которых выполнена изготовителем оборудования. В их числе функции приема/передачи по RS232/485, сокеты и др. (всего 24 биб-ки). Далее, используя их, я могу писать на языке ST модули, которые оказываются аппаратно независимыми. Например, именно так сделана поддержка CANopen. Изготовитель железа должен написать простейшие функции начальной инициализации микросхемы CAN, прием и передачу блока данных. Далее он подключает биб-ку CANopen написанную на ST. Когда захочет он может поменять микросхему, поправить свои 3 низкоуровневых функции, в прикладной программе ничего не поменяется. Аналогично сделаны ModbusUDP, SoftMotion и др. Естественно, написать поддержку (почти) любого нестандартного оборудования, подключенного по сети или последовательным каналам не проблема. Наверное, можно назвать это драйвером . В CoDeSys можно и обработчики аппаратных прерываний писать на ST, но это все же не совсем то.

Я же имею в виду гораздо более универсальное решение, приемлемое для открытой архитектуры, причем не только PC. Например, есть отличный ПЛК, сделанный под определенную область применения. Процессорный модуль выполнен на Motorola ColdFire. Он вставлен в крейт, модулям доступна процессорная шина. CoDeSys стоит, модули поддержаны, все отлично. Прикладные программисты счастливы и решают обычные задачи на раз, два…
Теперь возник интересный заказчик, которому нужно (в дополнение типично контроллерной задаче) в течение длительности взрыва снять тренды с десятков датчиков и очень быстро отдать их процессору. Под него разрабатывается специальный модуль, с внешним запуском, способный захватывать основной процессор по прерыванию и напрямую записывать в его ОЗУ свои данные. Ни каких правил и ограничений быть не должно! Аппаратчик должен иметь возможность выжать из железа все, что только можно, любыми способами. Сейчас драйвер этого модуля я могу написать только на ассемблере или на Си. Хотелось бы на ST.

Конечно, еще лучше если внутренняя шина обладает достаточным быстродействием, стандартизирована, открыта для расширений и никаких драйверов не нужно. В новых контроллерах Bechoff модули вообще висят на EtherCAT. Решение гениально простое. Технология будущего

Dmitry M. Gaidash
Member

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

написано 16 Июня 2007 14:52ИнфоПравкаОтветитьIP

IP
которому нужно (в дополнение типично контроллерной задаче) в течение длительности взрыва снять тренды с десятков датчиков и очень быстро отдать их процессору
И какая проблема сделать специализированную железку, которая соберет нужные данные у себя, а потом спокойно отдаст их по запросу? Зачем городить нелепое решение по "захвату" основного процессора и записи данных в его ОЗУ?

Конечно, еще лучше если внутренняя шина обладает достаточным быстродействием, стандартизирована, открыта для расширений и никаких драйверов не нужно
Эта шина называется PROFIBUS или PROFINET

Simaticov
Member

Сообщений: 54
Откуда: Russia
Регистрация: Январь 2007

написано 16 Июня 2007 22:30ИнфоПравкаОтветитьIP


цитата:
Конечно, еще лучше если внутренняя шина обладает достаточным быстродействием, стандартизирована, открыта для расширений и никаких драйверов не нужно.
В новых контроллерах Bechoff модули вообще висят на EtherCAT. Решение гениально простое. Технология будущего

Опять лозунги: EtherCAT - обычный 100 мбитный клон промышленного Эзернета со всеми вытекающими ограничениями.
Я бы ещё понял, если б это был бы N Гигабитный с работой на большие растояния ... а так это уже достаточно давно освоенное решение, в том числе реализованное даже в виде помехоустойчивой оптики у Сименса и других брэндов.
Да и опять смешение понятий "внутренняя" и "внешняя" шина.
Внутренная используется внутри конструктива (корзина с разъёмами куда втыкаются модули или ISA/PCI) - может быть параллельная и последовательная и соединена непосредственно с мелкопроцессором напрямую или через буферные мелкосхемы.
Внешняя для связи с конструктивно несвязанными устройствами (это уже не модули - а станции со своими модулями или функциональные устройства) на значительные растояния с использованием интерфейсных мелкосхем - типа RS232/485/Ethernet/CAN и т.п.

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

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

А для спецзадач принято делать спецжелезяки на заказ с соответствующими характеристиками, а не использовать бытовуху.

Dmitry M. Gaidash
Member

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

написано 16 Июня 2007 22:37ИнфоПравкаОтветитьIP

IP
Больше скажу - готов выдать координаты конторы, у которой такая железка уже есть и которая готова немного доработать ее под Ваши нужды

bessonov2
Member

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

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

Simaticov
Опять лозунги: EtherCAT - обычный 100 мбитный клон промышленного Эзернета со всеми вытекающими ограничениями.
Не совсем обычный. Модуль KLxxxx после оцифровки сигнала почти сразу кидает его в сеть EtherCAT.

В сименсовских модулях на профинете данные пройдут по определению с большей задержкой задержкой, т.к. модуль ввода данных сначала передаст данные в процессор модуля ET, затем ET передаст его профинетовскому чипу. Т.е. получается, прослойка между оцифрованным сигналом и сетью профинет состоит из трёх процессоров. Чем больше процессоров - больше время задержки. При чём, доступ к шине данных на ET находится не в монопольном доступе, а разделяется во времени между модулями SM.

Американцы на днях на Мире тоже устроили "прямую запись" в контроллеры управления...
Т.е. МКС? Нет Мира уж давно.

Simaticov
Member

Сообщений: 55
Откуда: Russia
Регистрация: Январь 2007

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

цитата:
При чём, доступ к шине данных на ET находится не в монопольном доступе, а разделяется во времени между модулями SM.

Так так и должно быть - ни одно периферийное устройство не имеет право захватывать общую сеть монопольно на длительное время, иначе другие не получат в положенное время сигналы управления от контроллера со всеми вытекающими последствиями.
В лучшем случае устройство, не получившее обмен с контроллером, перейдёт в Стоп по таймауту (как частотники).
Разделение доступа по времени вроде как основопологающий принцип обмена по общей шине.

МИР - это наш кусок МКС, так как сделан из модуля, который был предназначен для МИРа.

Dmitry M. Gaidash
Member

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

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

bessonov2
Ты вспомнил пароль?

IP
Member

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

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

цитата:
Dmitry M. Gaidash писал:
Больше скажу - готов выдать координаты конторы, у которой такая железка уже есть и которая готова немного доработать ее под Ваши нужды

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

Что такое внутренняя/внешняя шина и коню понятно, но не всегда присутствует столь строгое деление. Например, мне известны компактные контроллеры, в которых внутренняя шина – это CAN (наружу он не идет). В контроллерах с EtherCAT внутренняя шина вообще не нужна, сеть спокойно проходит через все модули и это не приводит к каким либо задержкам (внутренней она является только конструктивно). Информационные сообщения вырезаются аппаратно из общего циклического и пакета передаются процессорам в готовом виде. Захвата сети просто нет в принципе.
В Profibus DP удобно придумано с GSD фалами, на подобие EDS в CANopen. Сименсовские решения всегда привлекательны, но ИМХО не в силу технической оригинальности, а в результате качественной рекламы.

Вообще все это не важно в рамках данной темы, просто иллюстрация мысли о том, что полноценный инструмент написания драйвера обязан позволять использовать абсолютно все возможности железа, которые только есть (прерывания по уровням и фронтам, DMA, массивы счетчиков и пр. и др.). На Си это можно, на стандартном ST нельзя. Нужны определенные доработки самого языка. Конечно, компилятор ST должен давать быстрый машинный код. В CoDeSys это есть, нет (пока) только механизма интеграции таких МЭК драйверов со штатным конфигуратором.

Есть ли некий документ для Сименсовских контроллеров, в котором описано, как писать драйверы (основные шаги и правила)?

Dmitry M. Gaidash
Member

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

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

IP
Есть ли некий документ для Сименсовских контроллеров, в котором описано, как писать драйверы (основные шаги и правила)?
http://support.automation.siemens.com/WW/llisapi.dll/csfetch...eid=9264329&forcedownload=true

Simaticov
Member

Сообщений: 56
Откуда: Russia
Регистрация: Январь 2007

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

цитата:
DMA – это очень красивое решение. Процессор захватывается на микросекунды, абсолютно нормальный и широко применяющийся прием, как и аппаратные прерывания.

В своё время, когда не было денег на покупку SoundBlastera (да и они были редкостью у нас), сделал его аналог на 556РТ4 + 155РЕ3 + 572ПА1, разобрав его программный драйвер.
Почему в контроллерах редко используется ДМА ? Требования взаимной достоверности набора данных в единицу времени.
Поэтому принято обновлять таблицу входов/выходов один раз в цикле.

цитата:
DMA ... Никакими программными методами добиться такого быстродействия нельзя.

А это уже спорное утверждение и зависит от конкретного мелкопроцессора - не зря ведь на РС во многих случаях не используется аппаратное ДМА - операции блочных пересылок длинных слов производятся быстрее, чем в аппаратном ДМА и не требуют накладных расходов по программированию мелкосхемы ДМА.

цитата:
Это именно "сделанная на заказ спецжелезяка с соответствующими характеристиками" которая вставляется в промышленный контроллер....

Описанная тобой спецжелезяка, как и сам процесс одноразовой регистрации одноразового процесса не обсчитывается в реальном времени и в реальном времени по характеристикам процесса не принимаются решения для управляющих воздействий. Для этих целей можно использовать любой быстродействующий регистратор и потом сколько угодно времени обсчитывать.
Другое дело обсчёт "взрыва" топливо-воздушной смеси в цилиндрах двигателя и выдача управляющих воздействий для следуещего "взрыва" по результатам предыдущих.

цитата:
В контроллерах с EtherCAT внутренняя шина вообще не нужна, сеть спокойно проходит через все модули и это не приводит к каким либо задержкам (внутренней она является только конструктивно). Информационные сообщения вырезаются аппаратно из общего циклического и пакета передаются процессорам в готовом виде.

1 пакет содержащий 30 различных подпакетов для 30 модулей = 30 последовательных пакетов для 30 модулей.
Выигрыша в арифметике не увидел.

цитата:
Захвата сети просто нет в принципе.

Днунаправленный обмен данными несколькими клиентами по сети без захвата клиентом сети для передачи своих данных в принципе невозможен.

IP
Member

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

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

[q] Simaticov писал:

По скорости DMA:
Понятно, что само по себе это ничего не дает. Смысл в уменьшении времени реакции на внешнее событие. Если бы программа сама инициировала событие, а так его еще надо поймать. Сейчас доступны 2-х портовые ОЗУ и технология DMA не столь актуальна.

По железяке, если уж она оказалась так интересна:
За время взрыва происходит очень много измерений со многих датчиков. Можно конечно и прилепить к контроллеру, но со встроенными модулями получается компактный приборчик. Это просто пример не типовой задачи на ПЛК, когда может понадобиться низкоуровневый драйвер.

Насколько я могу судить, в блоках управления впрыском не требуется столь уж высокое программное быстродействие. В бывшей у меня 099 стоял контроллер с допотопным процессором (клон 8051). Компания Бош делает блоки управления для Мерсов и БМВ, в них применяется CoDeSys без всяких специальных ухищрений.

По EtherCAT:
В Ethernet каждое информационное сообщение сопровождается не слабой шапкой. Эффективность использования сети крайне низкая. В EtherCAT данные укладываются в окошки одного пакета не захватывая магистраль. Причем в обычных сетях центральный процессор сам распаковывает данные, сортирует их по модулям (мэппинг) и несколько раз копирует их туда-сюда преобразуя, пока они не окажутся в нужном формате в нужном месте памяти. В EtherCAT используется аппаратный мэппинг (через DMA). Удаленный модуль с EtherCAT вообще не кушает ресурсы процессора. Пакет гуляет по кольцу (в штатном режиме по двум встречным кольцам) строго синхронно с циклом опроса входов/выходов! При обрыве кабеля, кольца замыкаются слейвами на ходу.

Итого:
40 осей приводов (по 6 Байт)
560 модулей I/O 2000 дискр. + 200 аналог.
Время цикла EtherCAT 230 микросекунд!!!

Это 100Мб, скоро будет 1Гб. Но, Сименс уже и так отдыхает

Dmitry M. Gaidash
Member

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

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

IP
Сименс уже и так отдыхает
У Сименса есть PROFINET - те же яйца, вид в профиль Только поддержка на порядок лучше - вот и все дела

IP
Member

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

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

цитата:
Dmitry M. Gaidash писал:
http://support.automation.siemens.com/WW/llisapi.dll/csfetch...eid=9264329&forcedownload=true

Не понял, как двоичные данные передавать этим модулем. Только ASCII можно?

Обмен данными по прерываниям не возможен в принципе?

Допустим, есть некий внешний нестандартный прибор 'NXZ1'. Мы написали ф. блок который читает его данные, преобразует их в нужный формат. В конечном итоге, получается несколько переменных, которые собственно и нужны в прикладной программе нашему пользователю (автору прикладной программы). Далее я хочу превратить это в нормальный драйвер. Т.е. пользователь просто графически мышкой из некоего списка выбирает прибор 'NXZ1' в конфигураторе контроллера и получает в готовом виде нужные переменные. Ни о каких ф. блоках, их регулярных вызовах он просто не знает, это делается автоматически. Т.е. поддержанный нами прибор будет включаться в проект и использоваться абсолютно также как и любой модуль ввода, штатно поддержанный самим изготовителем контроллера. Так можно? Или пользователь обязан явно вставлять ф. блок опроса прибора в свою программу?

Кстати, насколько востребован сейчас протокол 3964? У нас (в CoDeSys) есть биб-ка для его поддержки, но в России никто ни разу про нее не спрашивал. Может быть, вообще стоит выбросить ее из документации?

Dmitry M. Gaidash
Member

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

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

IP
Не понял, как двоичные данные передавать этим модулем. Только ASCII можно?
Ну вообще это железка для MODBUS и ASCII-протоколов.

Обмен данными по прерываниям не возможен в принципе?
Другими средствами

есть некий внешний нестандартный прибор 'NXZ1'
Нестандартным (в части интерфейсов) приборам место на помойке. Поддерживает PROFIBUS согласно IEC61158 - интегрируется именно так, как Вы описываете (несколько кликов мышкой). Не поддерживает - сам себе злобный буратино. Можно интегрировать, но уже придется проделывать дополнительные телодвижения.

Ваш ответ:

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


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

Все время MSK

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

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

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

Copyright © skunksworks.net, 2000-2018

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


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