Ну и есть ещё одна проблема которая касается почти всех шинных протоколов. Это скорость. Например модбас для датчика. Мастер отправил запрос по определённому адресу. Потом таймаут что бы слейв понял что запрос кончился. потом слейв отправил мастеру ОДИН параметр. Опять таймаут. Потом мастер подтвердил приём данных. Опять таймаут. переход к следующему адресу. Эта процедура ускоряется для устройств с кучей параметров. Там слейв отправляет сразу МНОГО параметров. Тогда в модбасе появляется смысл. И это актуально для всех шинных протоколов. Если увеличивать скорость — падает помехозащищённость и появляются потери пакетов.
Выходит дешевле. Ну по крайней мере я знаю очень мало датчиков с интерфейсом Modbus на борту. Обычно его имеют более сложные устройства. Например измерители сети — там необходимо передавать достаточно много параметров (напряжение в каждой фазе. ток. ну и ещё кучу расчитываемых самим прибором параметров — можность активная, реактивная ....). А вот отдельные трансформаторы тока расчитанные на удалённое расположение — поголовно 4-20. Не очень выгодно тратить один адрес на один параметр.
А если длинна линии до датчика километр — другой. И при этом он проходит через десяток соединительных коробок с клемниками которые имеют достаточно высокое переходное сопротивление?
TWI и SPI очень чувствительны к помехам. Поэтому в промышленности они и не применяются. А вот RS485 — да — это транспорт для модбаса — очень старого и проверенного протокола (правда уже потихоньку умирающего — его заменяет профинет). 485 позволяет кидать линии до 1200 метров (на практике нормально с потерями в 15-20 процентов посылок работает до 3 км). Но датчики с интерфейсом модбас стоят в разы дороже датчиков 4-20 мА.
И вторая проблема — в сегменте модбас может быть не более 250 датчиков. А значит ещё нужны устройства сегментирования которые то же недёшевы.
Опять вы считаеть не умеете. Кабеля намного меньше не станет. Во первых к вашим имкам все равно тащить три кабеля — два питания и один оптика (то же очень не дешёвый, медь не пойдёт, максимальная длинна сегмента даже для экранированного если не ошибаюсь 250 метров ).
Да и стоит прежде чем давать «полезные» советы стоит немного поучить матчасть. Никто не будет тащить к каждому датчику свой кабель. В проекте рассчитывается оптимальный маршрут, кабеля от датчиков группируются в многожилку (например все датчики и исполнительные устройства от одного охладителя в одну соеденительную коробку, оттуда многожилкой в коробку более высокого уровня и так далее). В результате на щит с контролером приходит несколько кабелей с кучей жил.
Расчёт наиболее оптимального маршрута как раз и является задачей разработчика. И в таком варианте исполнения как раз проявляется вся прелесть токового сигнала. Ему плевать сколько клемников он прошёл, и какое у них переходное сопротивление (конечно в разумных пределах), значения передаваемые с него всегда будут точными.
А вот установка удалённых станций оправданно там, где в небольшом объёме сконцентрированно большое количество датчиков и исполнительных механизмов. У нас например они стоят непосредственно на турбине. Там да — они оправданны.
Так что как говорится вставайте с дивана товарищ и учите матчасть. Ну или просто помолчите, зачем позорится то.
Да не нужно вообще то — установка уже действующая. Кстати проект разрабатывал сименс, а их тяжело назвать глупыми. Не имеет смысла. Во первых 4-20 мА все таки является промышленным стандартом.
Ну и второй вопрос. Вы как то странно считаете. 2 станции ET200 — это далеко не всё. Блок питания для них нужен? Конечно! И желательно два с резервированием (требование процесса), два фидера питания (опять таки резервирование), вводные автоматы, автоматический переключатель питания (то же не дешёвая штука как ни странно). Потом нужен шкаф для всего этого хозяйства, причём уличного исполнения. Конечно же клемники, монтаж и т.п. Опять таки этот шкаф надо закрепить на чём то, то есть фундамент варить, а кое где и отдельный столб бетонировать.
Ну и как Вы думаете, пару кабелей на 500 метров бросить всё таки дешевле будет? Считать правильнее надо товарищ, если собираетесь советы профессиональному проектировщику давать)))))
О ВЕЛИКИЙ ГЕНИЙ Вы нас просветили. Как же мы идиоты не додумались ставить удалённые станции. Теперь на каждые 2 датчика ОБЯЗАТЕЛЬНО будем ставить такую станцию. Ведь датчики в поле разнесены на большие расстояния (установка не маленькая) и плотность датчиков составляет где то 1 — 2 на 100 метров. Ну ВАМ то ГЛАВНОМУ СПЕЦИАЛИСТУ по проектированию систем автоматизации сверху не видно)))
А кому то проще LAD и FBD. А Вам как программисту изучить LAD, не? Вообще то в основном проектировкой систем управления промышленными системами занимаются как раз специалисты в предметной области (в основном это касается энергетики, да и в остальных областях человек разрабатывающий систему автоматизации должен как минимум разбираться в электрике, поскольку все системы как раз электричеством управляются). Ну а программистов которые не отличают нормально открытый контакт от нормально закрытого в разработку систем управления нельзя подпускать на пушечный выстрел. Как то жить ещё хочется)))
А вы уверенны что инженеру — проектировщику понятнее и ближе ST и IL. Я в области проектирования и наладки систем АСУ работаю уже почти 15 лет, и честно скажу — очень редко вижу вставки на IL или ST. Ну и конечно обычно те самые проектировщики и наладчики громко матерятся на тех кто эти вставки сделал.
Ну и для полного счастья подключаем часы реального времени, картридер, и гоним на флешку статистику с метками времени в csv файл.
После проведения замеров флешку в комп, и считай готовый отчёт в экселе (который кстати умеет строить графики по таблицам).
Получится готовый анализатор
Для измерения пульсаций можно добавить простой фоторезистор. Ведь не требуется измерять освещённость (этим занимается люксометр), а необходимо только измерять её изменение за определённый период времени.
То есть в течении например 500 мс в цикле читаем значение с аналогового выхода к которому подключён фоторезистор, определяем максимальное и минимальное значение за это время, и разница между ними в процентах как раз будет необходимая величина.
Это лишь часть того что сделали дауны которые ни в зуб ногой в С, только с помощью даунской программы.
Ну а на Вашу задачу этим даунам от 5 минут до часа.
Ну раз с электричеством разбираешся, а с кодом сложно — то тебе точно сюда.
Кстати для люксометра (BH1750) там есть стандартный блок. Так же есть стандартный блок для измерителя цвета TCS230.
Только один вопрос — а зачем здесь WS2812. Обычный трёхцветный светодиод (который кстати и стоит в WS2812) — не кошерно?
WS2812 — это хорошо для тех случаев когда их много, для пиксельной адресации, а здесь он один, и приводит к такой куче проблем. Не понятно.
PS так и не увидел понятного рисунка из квадратиков, который получил бы пятые степени.
Дайте ссылочку на описание алгоритма (я честно говоря не нашёл его описание в нете) Вы же вроде об этом где то писали. Я думаю без проблем реализую его в FBD.
Ни в коей мере не принижая все сделанное перечисленными Вами людьми, позволю себе заметить, что ветка началась с фразы в комментарии (не моем) «никто же программы не пишет блок-схемами» и эта фраза безусловно верна.
Ладно, посмотрим с другой стороныю Смотрим википедию.
Компью́терная програ́мма — 1) комбинация компьютерных инструкций и данных, позволяющая аппаратному обеспечению вычислительной системы выполнять вычисления или функции управления
Языки FBD и LAD соответствуют этому определению? Блоки представляют собой инструкции, имеются входные данные, программа на этих языках выполняется согласно описанного алгоритма.
Ищем дальше
FBD (англ. Function Block Diagram) — графический язык программирования стандарта МЭК 61131-3. Предназначен для программирования программируемых логических контроллеров (ПЛК). Программа образуется из списка цепей, выполняемых последовательно сверху вниз. Цепи могут иметь метки. Инструкция перехода на метку позволяет изменять последовательность выполнения цепей для программирования условий и циклов.
Это не просто язык, а стандартизированный, мэковский.
Ladder Diagram (англ. LD, англ. LAD, рус. РКС) — язык релейной (лестничной) логики.
Применяются также названия:
язык релейно-контактной логики
релейные диаграммы
релейно-контактные схемы (РКС)
язык программирования релейно-лестничной логики стандарта МЭК 61131-3.
То же себе настоящий стандартизированный язык.
Теперь сравним С и FBD.
1. В языке С используются стандартные функции заранее прописанные в спцификации языка. В FBD в их качестве используются функциональные блоки.
2.В С есть классы, которые имеют свои интерфейсы для взаимодействия с ними. В FBD так же существуют аналоги классов. В зависимости от реализации это могут быть чарты, нетворки, FB ( функциональные блоки), функции (да да именно так они и называются у сименса) или платы как в FLProg. Они так же имеют интерфейсы — переменные, входы, выходы.
3. Как и в С в FBD реализована вся математика, алгебра, и работа со всеми типами данных, возможность создания собственных типов данных, реализация собственных библиотек, а так же пользовательских блоков (аналогов функций и классов в С ). Добавление блока на схему аналогично созданию нового инстанса класса в С.
4. Вы будете очень удивлены но в FBD как и в С реализовано ветвление, циклическое выполнение, и даже рекурсия (скажу чесно, рекурсию в FLProg я пока не реализовал, всё остальное есть. У сименса и рекурсия есть ). Учите матчасть прежде чем плевать в кого то. Может вернуться.
А теперь расскажите мне что может С того чего не может FBD. Функционал то одинаковый, разница как говорится только в синтаксисе, и в способе его отображения. Значит и сложность алгоритмов который можно описать обеими этими языками одинакова.
Теперь посмотрим на разработчиков. Вы как «классический» программист думаете текстом — то есть программа на FBD для Вас непонятное нагромождение квадратиков и линий. Ну что поделаешь — не дано(((
А теперь представте себе (если конечно воображения хватит ) разработчика АСУ, по большому счёту электронщика, который эти кубики и линии читает так же как Вы листинг, на счёт раз. А вот Ваш любимый набор буковок для него китайская грамота (как и для Вас схема программы на визуальном языке). Он тупее Вас? Или он не способен описать сложный алгоритм? Ведь возможности языков как мы уже выяснили одинаковые. Значит разница только в разработчиках. Исходя из этого получается что Вы считаете всех программистов АСУ тупыми недоумками которые не способны написать программу (они ведь не пользуются великим и могучем С) а балуются всякими «Здравствуй мир». Опять таки исходя из Вашего мнения, мы, программисты АСУ можем считать Вас — программистов на С такими же недопрограмистами, ведь Вы не пользуетесь и не понимаете великий и могучий FBD на котором вообще то работает вся промышленность, за счёт которой Вы вообще то живёте.
Вот так гражданские войны и начинаются (шутка).
Ну и так, напоследок, поинтересуйтесь у автора программы FLProg, на чем он ее реализовывал. Если на блок-схемах, то я обещаю съесть свою шляпу.
Ну вообще то я написал её на языке SmallTalk. Он кстати далёк от C так же примерно как и FBD но только немного в другую сторону, а точнее сказать в бок. Это язык где нет примитивов (так всё — объекты — это сложо понять, но когда понимаешь — влюбляешся), где нет кучи файлов, а есть шикарный класс браузер. В этом языке можно остановить программу, внести изменения в код, или заменить значения переменных, и продолжить выполнение программы с того же места дальше. Это наверное единственный язык, где возможно программирование через дебаг (нет я не извращенец, это действительно удобно). И именно он позволяет мне одному развивать проект FLProg достаточно интенсивно. Ни на каком другом языке я бы не справился.
И вторая проблема — в сегменте модбас может быть не более 250 датчиков. А значит ещё нужны устройства сегментирования которые то же недёшевы.
Да и стоит прежде чем давать «полезные» советы стоит немного поучить матчасть. Никто не будет тащить к каждому датчику свой кабель. В проекте рассчитывается оптимальный маршрут, кабеля от датчиков группируются в многожилку (например все датчики и исполнительные устройства от одного охладителя в одну соеденительную коробку, оттуда многожилкой в коробку более высокого уровня и так далее). В результате на щит с контролером приходит несколько кабелей с кучей жил.
Расчёт наиболее оптимального маршрута как раз и является задачей разработчика. И в таком варианте исполнения как раз проявляется вся прелесть токового сигнала. Ему плевать сколько клемников он прошёл, и какое у них переходное сопротивление (конечно в разумных пределах), значения передаваемые с него всегда будут точными.
А вот установка удалённых станций оправданно там, где в небольшом объёме сконцентрированно большое количество датчиков и исполнительных механизмов. У нас например они стоят непосредственно на турбине. Там да — они оправданны.
Так что как говорится вставайте с дивана товарищ и учите матчасть. Ну или просто помолчите, зачем позорится то.
Ну и второй вопрос. Вы как то странно считаете. 2 станции ET200 — это далеко не всё. Блок питания для них нужен? Конечно! И желательно два с резервированием (требование процесса), два фидера питания (опять таки резервирование), вводные автоматы, автоматический переключатель питания (то же не дешёвая штука как ни странно). Потом нужен шкаф для всего этого хозяйства, причём уличного исполнения. Конечно же клемники, монтаж и т.п. Опять таки этот шкаф надо закрепить на чём то, то есть фундамент варить, а кое где и отдельный столб бетонировать.
Ну и как Вы думаете, пару кабелей на 500 метров бросить всё таки дешевле будет? Считать правильнее надо товарищ, если собираетесь советы профессиональному проектировщику давать)))))
Ну и во вторых стоит такой сертифицированных люксометр будет наверное немало.
После проведения замеров флешку в комп, и считай готовый отчёт в экселе (который кстати умеет строить графики по таблицам).
Получится готовый анализатор
То есть в течении например 500 мс в цикле читаем значение с аналогового выхода к которому подключён фоторезистор, определяем максимальное и минимальное значение за это время, и разница между ними в процентах как раз будет необходимая величина.
Термостат газового котла с управлением по CMC
Автозапуск двигателя по звонку
Система управления самогонным аппаратом
Круиз контроль для автомобиля.
Авто GSM сигнализация к иммобилайзеру.
Метеостанция и GSM сигнализация для загородного дома.
Дальномер+уровень+угломер+лазерная разметка.
Блок управления спиртовой ректификационной колонной.
…
…
Это лишь часть того что сделали дауны которые ни в зуб ногой в С, только с помощью даунской программы.
Ну а на Вашу задачу этим даунам от 5 минут до часа.
Кстати для люксометра (BH1750) там есть стандартный блок. Так же есть стандартный блок для измерителя цвета TCS230.
WS2812 — это хорошо для тех случаев когда их много, для пиксельной адресации, а здесь он один, и приводит к такой куче проблем. Не понятно.
Упс, нашёл ответ выше
Дайте ссылочку на описание алгоритма (я честно говоря не нашёл его описание в нете) Вы же вроде об этом где то писали. Я думаю без проблем реализую его в FBD.
Ладно, посмотрим с другой стороныю Смотрим википедию.
Языки FBD и LAD соответствуют этому определению? Блоки представляют собой инструкции, имеются входные данные, программа на этих языках выполняется согласно описанного алгоритма.
Ищем дальше
Это не просто язык, а стандартизированный, мэковский.
То же себе настоящий стандартизированный язык.
Теперь сравним С и FBD.
1. В языке С используются стандартные функции заранее прописанные в спцификации языка. В FBD в их качестве используются функциональные блоки.
2.В С есть классы, которые имеют свои интерфейсы для взаимодействия с ними. В FBD так же существуют аналоги классов. В зависимости от реализации это могут быть чарты, нетворки, FB ( функциональные блоки), функции (да да именно так они и называются у сименса) или платы как в FLProg. Они так же имеют интерфейсы — переменные, входы, выходы.
3. Как и в С в FBD реализована вся математика, алгебра, и работа со всеми типами данных, возможность создания собственных типов данных, реализация собственных библиотек, а так же пользовательских блоков (аналогов функций и классов в С ). Добавление блока на схему аналогично созданию нового инстанса класса в С.
4. Вы будете очень удивлены но в FBD как и в С реализовано ветвление, циклическое выполнение, и даже рекурсия (скажу чесно, рекурсию в FLProg я пока не реализовал, всё остальное есть. У сименса и рекурсия есть ). Учите матчасть прежде чем плевать в кого то. Может вернуться.
А теперь расскажите мне что может С того чего не может FBD. Функционал то одинаковый, разница как говорится только в синтаксисе, и в способе его отображения. Значит и сложность алгоритмов который можно описать обеими этими языками одинакова.
Теперь посмотрим на разработчиков. Вы как «классический» программист думаете текстом — то есть программа на FBD для Вас непонятное нагромождение квадратиков и линий. Ну что поделаешь — не дано(((
А теперь представте себе (если конечно воображения хватит ) разработчика АСУ, по большому счёту электронщика, который эти кубики и линии читает так же как Вы листинг, на счёт раз. А вот Ваш любимый набор буковок для него китайская грамота (как и для Вас схема программы на визуальном языке). Он тупее Вас? Или он не способен описать сложный алгоритм? Ведь возможности языков как мы уже выяснили одинаковые. Значит разница только в разработчиках. Исходя из этого получается что Вы считаете всех программистов АСУ тупыми недоумками которые не способны написать программу (они ведь не пользуются великим и могучем С) а балуются всякими «Здравствуй мир». Опять таки исходя из Вашего мнения, мы, программисты АСУ можем считать Вас — программистов на С такими же недопрограмистами, ведь Вы не пользуетесь и не понимаете великий и могучий FBD на котором вообще то работает вся промышленность, за счёт которой Вы вообще то живёте.
Вот так гражданские войны и начинаются (шутка).
Ну вообще то я написал её на языке SmallTalk. Он кстати далёк от C так же примерно как и FBD но только немного в другую сторону, а точнее сказать в бок. Это язык где нет примитивов (так всё — объекты — это сложо понять, но когда понимаешь — влюбляешся), где нет кучи файлов, а есть шикарный класс браузер. В этом языке можно остановить программу, внести изменения в код, или заменить значения переменных, и продолжить выполнение программы с того же места дальше. Это наверное единственный язык, где возможно программирование через дебаг (нет я не извращенец, это действительно удобно). И именно он позволяет мне одному развивать проект FLProg достаточно интенсивно. Ни на каком другом языке я бы не справился.