Пожелания

[dmitribon]

Планируется ли выпуск простейших встраиваемых систем с интерфейсами USB, 1-Wire, с возможностью подключения
выносного дисплея 2х16 по I2C?
(подобные описанным в журнала "Радиолюбитель" на базе
ATMega8, расчитанные на решение относительно простых
задач, программируеые доступными средстами Atmel, предназначенные как для любителей, так и для профессионалов).
По какой цене их может предложить компания Segnetics?

Почему забыты Forth-системы? Их применение в большинстве случаев окажется более эффективным и целесообразным, чем навязанное использование относительно трудоемкого SMLogic.

[Arsie]

У меня просьба: опишите, пожалуйста, задачи, которые вы планируете решать с помощью подобных контроллеров?

PS. Насчёт цены - она зависит от того, сколько вы таких контроллеров готовы купить

[AlexG]

Задачи для которых понадобилась такая экзотика это самое интересное

[dmitribon]

Вполне достаточны для замены регуляторов Regin в простых системах вентиляции , кроме того, допускающие использование более доступных датчиков Dallas Semicondactor ($3), а также введение дополнительных фунций (например: задержки отключения вентилятора, что освобождает от применения в щите автоматики дополнительного реле времени).

Для себя купил бы один экземпляр (может два - для экспериментов с распределенными системами управления). Что касается массового применения, то те кто принимают решения о покупке компнетов для проектирования и сборки щитов не имеют других предложений.

Я лишь поневоле работаю с тем, что дают. Деградирую вместе c SMConstructor и SMLogic. Хотел бы иметь доступ к описанию аппаратных средств и (желательно, для экономии времени) функций ядра контроллеров Segnetics.

[Arsie]

Программируемые реле времени предлагаются на рынке другими производителями.

Насчёт деградации - есть схема на SMH2010, по ней видно, что к каким портам подключено...

[AlexG]

А чем вас Pixel-120x не устраивает? Термодатчики можно использовать NTC, они должны быть дешевле чем PT1000.

[dmitribon]

Полагаю, что имеется потребность в малых системах стоимостью, соизмеримой с ценой таймера, блока термоконтроля двигателя (например, в двигателях Siemens применен терморезистор, а не термоконтакт), т.е. с конечной ценой (потребления) менее $30..50.
Большинство потребителей сборочных единиц для изделий и комплексов автоматики заитересовано в развитии своей системы, но не системы компании Segnetics, которая должна предлагать и "открытые" аппаратные средства. Форум - хорошее средство для декомпозиции проблемы построения открытых систем - коллективной работы.

[Arsie]

Про форум - звучало сильно

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

[dmitribon]

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

[dmitribon]

Каждый должен быть специалистом в своем направлении. Arsie! Вы не специалист в экономике - "дорогой" (универсальный) контроллер целесообразен для единичных (иногда для мелкосерийных) проектов, но эффективно используемый аппаратный ресурс экономически целесообразен для сериных изделий.

Предлагаемое "на шару" программное обеспечение совершенно непригодно для сериных проектов на базе Atmel, язык программирования SMLogix целесообразен для Altera (прогаммируемых нескоммутированных логических устройств). Кроме того, труд схемотехника такого уровня дороже, чем работа рядового программиста-студента

[Arsie]

Цитата

Сообщение от dmitribon

Каждый должен быть специалистом в своем направлении. Arsie! Вы не специалист в экономике - "дорогой" (универсальный) контроллер целесообразен для единичных (иногда для мелкосерийных) проектов, но эффективно используемый аппаратный ресурс экономически целесообразен для сериных изделий.

Да, я не специалист в экономике. Но почему-то мне кажется, что универсальный контроллер по цене специализированного - это верный путь

Цитата

Сообщение от dmitribon

Предлагаемое "на шару" программное обеспечение совершенно непригодно для сериных проектов на базе Atmel, язык программирования SMLogix целесообразен для Altera (прогаммируемых нескоммутированных логических устройств). Кроме того, труд схемотехника такого уровня дороже, чем работа рядового программиста-студента

Тут у меня два возражения:

1) Никто не мешает программировать контроллер на C, C++, ассемблере. Рядовые студенты-программисты их обычно изучают. Что в ВУЗе, что в техникуме.

2) Я бы не решился доверить написание программы студенту. Особенно когда из-за ошибок в программе может порвать мегаваттный насос или какой-нибудь "хитрозасунутый" в закоулки техэтажа водяной калорифер. Труд такого студента вполне может стать экономически менее выгодным, чем труд специалиста с опытом и вдесятеро большей зарплатой.

Но я вполне понимаю суть вашей претензии: у нас нет такой же лёгкой альтернативы лоджику. Это да. Поверьте, наши разработчики крепко думают на эту тему.

[dmitribon]

Универсальный контроллер по приемлемой цене хорошо!
Но конструкция врядли универсальна- где выносной дисплей?
И не велико ли отверстие под SMH в дорогом щите?

[Arsie]

Цитата

Сообщение от dmitribon

Но конструкция врядли универсальна- где выносной дисплей?

Насколько я понимаю, ещё никому не удалось сделать универсальный контроллер, устраивающий всех. Именно поэтому SMH2010 имеет панельное исполнение, а Pixel дин-реечное.

Цитата

Сообщение от dmitribon

И не велико ли отверстие под SMH в дорогом щите?

Не совсем понимаю. Если уж и пилить отверстие, то разницы между 50х50 и 100х100 практически нет...

А отпиленное можно сдать в металлолом, таким образом сэкономив

[AlexG]

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

[AlexG]

Цитата:

Сообщение от Arsie

Да, я не специалист в экономике. Но почему-то мне кажется, что универсальный контроллер по цене специализированного - это верный путь

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

Цитата:

Сообщение от Arsie

Но я вполне понимаю суть вашей претензии: у нас нет такой же лёгкой альтернативы лоджику. Это да. Поверьте, наши разработчики крепко думают на эту тему.

ИМХО, лоджику нужна не альтернатива, а доводка до ума, чтобы им было легко и приятно пользоваться.

[Arsie]

Цитата

Сообщение от AlexG

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

Понятное дело, что часто граната гораздо проще и дешевле решает вопрос, чем авиационная бомба Но иногда она неплохо заменяет сотню гранат

Цитата

Сообщение от AlexG

ИМХО, лоджику нужна не альтернатива, а доводка до ума, чтобы им было легко и приятно пользоваться.

Над этим они также крупно думают.

[dmitribon]

Язык - удобство общения. И здесь перепутаны удобства.
Си - далек от совершенства, и "трехэтажные ошибки" - следствие
его "неудобочитаемости" и "вседозволенности".
Я хотел бы подойти к языку, создающему операционную среду
(как последовательной обработки, так и реального времени,
с разделением времени, распределенной обработки). В большинстве
случаев для этого потребуются 16-и , 32-разрядные МК , и возможно
архитектура Фон Неймана, а не гарвардская. Но само развитие
Segnetics с 8-разрядного МК началось в ином направлении. Ранее в Ленинграде было достаточно специалистов для проектирования любых трансляторов (генераторов кода). Но сегодняшняя "преданность" языку Си и гафическому программированию многим непонятна.

[AlexG]

В области языков программирования для ПЛК есть некоторые стандарты. Если придумать свой собственный, замечательный, но непохожий на другие язык это мало кто оценит.

[Sergey Cherevko]

Еще лет 15 назад, когда надоела отсебятина производителей, был разработан стандарт IEC61131-3 и его европейский аналог EN61131-3, описывающий пять языков программирования для программируемых логических контроллеров. Одним из этих пяти языков является FBD (Функциональные Блоковые Диаграммы), реализованные в SMLogix.
Поэтому разрабатывать свой собственный язык программирования - всё равно что использовать вместо Modbus свой коммуникационный протокол. Кому это надо?

[dmitribon]

Здесь есть место стандартным европейцам?
Да и то "добро", из которого собран Segnetics -
лишь неликвидность Запада.
Признаю, что SMLogix обладает мультизадачными
средствами (события, разделение времени, сеть).
Являясь специалистом в схемотехнике, в данном случае
я ожидаю оператор присваивания, операции
и функции, типы, объекты, но не схему счетно-решающего
устройства. Как подключить программный модуль? И стоит ли
это делать вообще!?

[Sergey Cherevko]

Эмоции опущены

Цитата

Сообщение от dmitribon

Являясь специалистом в схемотехнике, в данном случае
я ожидаю оператор присваивания, операции
и функции, типы, объекты, но не схему счетно-решающего
устройства. Как подключить программный модуль? И стоит ли
это делать вообще!?

Вроде всё вышеперечисленное в лоджике есть
Только называется несколько по другому
Присваивание = "выход"
Операции и функции = блоки (готовые) и макросы (пользовательские)
Типы разнообразные: bool, int, long, real и string
Ну структур нет, а кто их в FBD использует?
Не совсем понял, что такое программный модуль. Функция? Подпрограмма? Обработчик события? Может, просто макрос?
Сейчас в лоджике функция, подпрограмма и макрос фактически являются синонимами. Ибо по входу enable "ненужные" в данный момент блоки просто ничего полезного не делают.
А вот организовать обработчики событий не помешало бы...
Может Сегнетикс в новой версии лоджика реализует их?

[Arsie]

Цитата:

Сообщение от Sergey Cherevko

Эмоции опущены
А вот организовать обработчики событий не помешало бы...
Может Сегнетикс в новой версии лоджика реализует их?

Что именно вы имеете ввиду? Какие события нужно обрабатывать?

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

Единственное, что пришло в голову: нет события "выключение питания", но его и не обработать из-за отсутствия автономности после выключения питания, поэтому смысла в нём нет.

Может я что-то не так понимаю?

[Sergey Cherevko]

Цитата:

Сообщение от Arsie

Что именно вы имеете ввиду? Какие события нужно обрабатывать?

Немного поясню.
События могут разные, но для SMH и Pixel актуальны всего два:
1. Изменение состояния входа (прерывание по входу)
2. Асинхронное к тику прерывание по времени
Обработчики событий нужны для уменьшения времени реакции контроллера. А реакции SMH и Pixel хватает лишь на не очень быстрые процессы.
Пример из жизни. Pixel с 2 МР, проект на чуть меньше 1000 блоков. Реальный тик 50...55мс, заданный 75. Железяка с датчиками положения и довольно низкой динамикой позиционируется пикселом на границе схода флажка с датчика после его "пролета".
Конечно, можно собрать несложную схему на внешних реле с реакцией на срабатыание датчика менее 1мс. Но это же не наш метод Обычно всё наоборот и разные ошибки проектирования устраняются программными методами...
Поэтому и хотелось бы иметь какой-либо обработчик событий. Например, каждую 1мс контроллер бросает остальные дела и обрабатывает заданный пользователем макрос. В макросе опросил вход, обработал алгоритм и тут же выдал результат на выход.

[LordN]

Цитата:

Сообщение от Arsie

Что именно вы имеете ввиду? Какие события нужно обрабатывать?

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

Единственное, что пришло в голову: нет события "выключение питания", но его и не обработать из-за отсутствия автономности после выключения питания, поэтому смысла в нём нет.

Может я что-то не так понимаю?

если юзать правильный БП, то событие "выключение питания" ловится очень хорошо и стабильно.

[dmitribon]

Как-то дали частотный преобразователь подключтить, не помню какой.
Но формат обмена - 1 байт. Как быть!? Тех руководитлей, которые выбирают по-дешевле врядли интересуют трудности. Бывает контроллер только куплен и уже должен быть у заказчика. Себе позволить такой контроллер купить не могу. А вот, если бы контроллеры были простые, как для радиолюбителей - я бы по вечерам все делал сам.

[Arsie]

Цитата:

Сообщение от Sergey Cherevko

Немного поясню.
События могут разные, но для SMH и Pixel актуальны всего два:
1. Изменение состояния входа (прерывание по входу)
2. Асинхронное к тику прерывание по времени
Обработчики событий нужны для уменьшения времени реакции контроллера. А реакции SMH и Pixel хватает лишь на не очень быстрые процессы.
Пример из жизни. Pixel с 2 МР, проект на чуть меньше 1000 блоков. Реальный тик 50...55мс, заданный 75. Железяка с датчиками положения и довольно низкой динамикой позиционируется пикселом на границе схода флажка с датчика после его "пролета".
Конечно, можно собрать несложную схему на внешних реле с реакцией на срабатыание датчика менее 1мс. Но это же не наш метод Обычно всё наоборот и разные ошибки проектирования устраняются программными методами...
Поэтому и хотелось бы иметь какой-либо обработчик событий. Например, каждую 1мс контроллер бросает остальные дела и обрабатывает заданный пользователем макрос. В макросе опросил вход, обработал алгоритм и тут же выдал результат на выход.

1) В пределах своего быстродействия что SMH, что Пиксель "прерывание" отработают. Не стоит их применять в неподходящих им задачах. Если вам нужна реакция 1 мс, то контроллер должен иметь время цикла не более 0.5 мс. Иначе любые ухищрения только усугубят ситуацию.

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

Во всех мощных системах с ОС реального времени просто очень маленькое время цикла (менее 1 мс), поэтому возникает ощущение "прерывания" и "параллельной работы". Но это ощущение, не более.

У нас есть продукт, который можно использовать в системах позиционирования - это FS-01, у неё время срабатывания измеряется долями миллисекунд.

PS. Не поделитесь, какие-такие реле срабатывают быстрее, чем 1 мс?

PPS. Вы представили очень упрощённую модель, правильно это делается так: каждую 1мс контроллер бросает остальные дела, опрашивает входы, сохраняет контекст основной задачи, обрабатывает заданный пользователем макрос, выдаёт результат на выход, восстанавливает контекст основной задачи. В результате такой чехарды времени потратится больше, чем 1 мсек. Но самое грубое, что произойдёт - это потеряется синхронность выполнения основной программы. Например: основная программа включает 2 дискретных выхода. Важно, чтобы они включились одновременно. Контроллер включает один, в это время возникает прерывание, в течении которого он выполняет макрос из 100 блоков. Тратит на это 1-2 мс. В итоге второй дискретный выход включится с задержкой.

[Arsie]

Этот вариант я даже не рассматриваю, т.к. он от контролера не зависит

[Arsie]

Как для радиолюбителя?

Я в своё время собирал такое устройство. Называлось оно Микроша-80. Нифига оно не простое. И ZX Spectrum собирал. Уже проще, но всё ещё сильно сложнее нашего контроллера. При меньших возможностях.

Или у вас есть иной пример?

PS. "Формат обмена 1 байт" - это описание годится к абсолютно любому протоколу на основе любого последовательного порта (RS-232, RS-422, RS-485) и части параллельных. В них передача происходит побайтово, т.е. формат обмена однобайтовый.

[Sergey Cherevko]

Цитата:

Сообщение от Arsie

Если вам нужна реакция 1 мс, то контроллер должен иметь время цикла не более 0.5 мс. Иначе любые ухищрения только усугубят ситуацию.

Повторюсь. Практически всегда ошибки проектирования исправляются программными способами. В том числе и более быстрой обработкой некоторых входов-выходов, чем период тика/скана. В контроллерах других производителей обычно это всегда локальные входы-выходы (не модулей расширения).
Принцип простой. В системных настройках указывается программный файл/блок/сегмент, который обрабатывается асинхронно от основного тика/скана каждые 10мкс/100мкс/1мс в зависимости от контроллера/производителя. При этом в среде разработки в дереве проекта/закладке "Устройства" в папке программ основная программа и обработчики лежат сами по себе раздельно и обозначены разными пиктограммами, чтобы пользователь не перепутал.

Цитата:

Сообщение от Arsie

Асинхронность асинхронностью, но смысл в каком-то внеочередном выполнении какого-то макроса, если циклу подчинены также и обновление входов и выходов? Ну, обработал макрос данные, куда он их денет?.

Обработчик вызывается:
1. по прерыванию системного таймера;
2. или системной же функцией, которая очень часто сама опрашивает вход и определяет изменение его состояния.
По завершении работы обработчика используемые им выходы сразу же обновляются. В контроллерах других производителей есть даже специальные команды/блоки/инструкции для асинхронного чтения водов и для записи выходов.
В случае SMLogix я представляю себе обработчик отдельной "поляной", на которой будут свои входы и свои выходы. Проблему вижу в другом - как обмениваться переменными между основной программой и обработчиком,хоть они и будут использовать общую память. Наверное, появится какой-нибудь новый "леденец" глобальной связи...

Цитата:

Сообщение от Arsie

Во всех мощных системах с ОС реального времени просто очень маленькое время цикла (менее 1 мс), поэтому возникает ощущение "прерывания" и "параллельной работы". Но это ощущение, не более.

Неправда. Достаточно много видел разных мощных промышленных контроллеров в разных приложениях. Наоборот, у всех них время цикла не менее 10мс, и это еще очень хорошее быстродействие.
Если "разогнать" пиксел до цикла в 10...20мс с несколькими модулями расширения и программой около 1000 блоков, то вопрос с обработчиком сам бы отпал.

Цитата:

Сообщение от Arsie

У нас есть продукт, который можно использовать в системах позиционирования - это FS-01, у неё время срабатывания измеряется долями миллисекунд.

Если была бы потребность в сервосистеме, туда Pixel бы и не поставил. А для задачи выключения двигателя по срабатыванию датчика и за разумное время ставить FS-01 это стрелять из пушки по воробьям.

Цитата:

Сообщение от Arsie

PS. Не поделитесь, какие-такие реле срабатывают быстрее, чем 1 мс?

Твердотельные
Электромеханические подольше: 5...20мс в зависимости от номинального тока. Но все равно на порядок быстрее контроллера, про который я написал...

[AlexG]

Если вам это действительно нужно, можно получить весьма и весьма хорошее быстродействие запрограммировав SMH на Си.