Гаражные войны

[Кass]

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

Да какая разница сколько ядер и какое чем занимается. Суть вообще не в этом. Каждый количественный параметр в системе помимо количественной величины имеет и временное значение, в абсолютном значении времени. Ни относительное относительно чего либо, а конкретно ДД.ММ.ГГГГ ЧЧ:ММ:СС.СС  Это главное. Вот нет у вас нигде в параметре просто значения, не имеющего временной метки.

Далее мы понимаем, что значения параметров внешних изменяются не синхронно. Между ними могут быть сдвиги в микросекунды или наносекунды. Как вы в системе посчитаете хотя бы разницу двух давлений (к примеру 6 и 3 бара), если одно имеет время 14:47:25.315, а другое 14:47:25.317? А если считать до наносекунд? Все? Система реального времени посчитает и выдаст два значения Р1-0 с меткой 14:47:25.315 и 0-Р2 с меткой 14:47:25.317. В итоге вместо 3 бар вы получите два значения 6 бар и -3 бара с разницей по времени в 2 мкс. То есть за 2 мкс у вас значение перепада давления изменилось на 9 бар. ПИДы с ума сойдут.

Таким образом вы должны читать входные параметры не когда они изменяют значение или приходят, а точно в одно время через одинаковый период. Тогда вы бы получили одно значение 3 бара с меткой к примеру 14:47:25.3 или 14:47:25.32 в зависимости от длины цикла.

Поэтому в системах АСУ ТП чтение всех параметров всех датчиков происходит в начале цикла, внутри цикла расчет, и запись выходных значений в конце цикла. Только так и никак иначе. Вычислительная мощь просто позволит вам снизить время цикла, если в этом есть такая необходимость, но цикл будет в любом случае. И время цикла будет одинаковым у всех элементов системы. В таком случае, если какой то контроллер в цикле считает данные, собранные с удаленных объектов, он будет использовать данные только с одинаковыми временными метками.

Тот же мой стенд для изучения АКБ выполнен именно на базе платформы АСУ ТП, а его АРМ ни что иное как СКАДА система, упомянутая в букваре. И соответственно стенд работает на полном реалтайме. Цикл в нем я выбрал 50 мс. Могу выставить и 100 мс и 10 мс. Тут вопрос смысла, что и зачем нам нужно. Любой параметр внутри контроллера имеет временные метки через 50 мс. На сервер АРМа контроллер выплевывает их когда захочет, но с метками кратными целым минутам. То есть в базе данных АРМа все параметры лежать именно с такими временными метками. Если в отчете запросить данные по любому одному или группе параметров за какой то период, АРМ вам их выдаст обязательно с временными метками. Ибо в АСУ ТП значение без временной метки не имеет никакого смысла.

http://80.240.100.86/WebApplicationNERO/LogArchiveView3.aspx?dtFrom=18.04.2019%2012%3A00&dtTo=18.04.2019%2013%3A00&MasterSN=806355154&Parameters=1_Напряжение_ЗУ%0A01.ЗУ.Напряжение&table=true

Вот для примера вывел вам один параметр, напряжение на АКБ за 1 час. У каждого значения стоит временная метка. Это не время получения сервером параметра, а именно временные метки, когда данный параметр был считан контроллером.

[Shadow_ru]

В итоге вместо 3 бар вы получите два значения 6 бар и -3 бара с разницей по времени в 2 мкс. То есть за 2 мкс у вас значение перепада давления изменилось на 9 бар. ПИДы с ума сойдут.  Таким образом вы должны читать входные параметры не когда они изменяют значение или приходят, а точно в одно время через одинаковый период

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

[Кass]

Это не так.

Это так. Вникните в суть написанного.

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

Это не я синхронизацией занимаюсь, а ОС реального времени. Все измерения так же снимает ОС. Я только описываю алгоритм расчета. Я просто вам описал, как работают ОС реального режима в контроллерах  АСУ ТП. За время цикла АЦП делает сотни измерений, и ОС берет среднее на начало цикла по аналоговым. Но так же временные метки имеют и дискретные сигналы. Читаются то все значения, и булевые, и int, и float и в конце цикла все промежуточные и конечные получают метки времени. В этом и есть суть системы РЕАЛЬНОГО ВРЕМЕНИ, что каждое значение помимо скалярного значения имеет метку реального времени, измеренную реальными часами. Без этой метки времени ситуация бы выглядела так:

- Петька, приборы!
- 80!!!
- Чего 80?
- А чего "приборы"?

Я на самом деле не понял - почему нельзя передавать данные не в гиперцикле, а параллельными процессами. Вы же писали что будете передавать только в строго выделенное време и никак иначе.

Передавать в строго определенное время нужно данные между контроллерами, которые требуются в расчетах. А вот данные для передачи на верхний уровень, в серверы СКАДА можно когда угодно. Но передаются все данные в виде двумерного массива. На серверах нет необходимости делать какие то вычисления мгновенно. Там данные используются для постобработки, какие то отчеты, статистики, анализ, и т.п. То есть вы можете в одном наборе трендов вывести массу данных с разных мест и городов, и при этом на оси времени они все будут синхронизированны. Если меня инетесуют данные в какой то конкретный момент данных, то нет никаких проблем увидеть именно в таком виде.

Ну к примеру на том же стенде, вот хочу я узнать, какие значения напряжения на АКТ, тока, скорости и 2 производной были 18 апреля 2019 года ровно в 12:42, я делаю запрос на сервер и получаю в этом отчете:

http://80.240.100.86/WebApplicationNERO/LogArchiveView3.aspx?dtFrom=18.04.2019%2012%3A00&dtTo=18.04.2019%2013%3A00&MasterSN=806355154&Parameters=1_2Пр_Напряжение%0A01.Напряжение.2Пр%2C1_Скорость_Напряжение%0A01.Напряжение.Скорость%2C1_Ток_ЗУ%0A01.ЗУ.Ток%2C1_Напряжение_ЗУ%0A01.ЗУ.Напряжение&table=true



Ну тут заряда или разряда нет, поэтому к примеру хочу я знать эти же параметры в новогодние праздники, к примеру 03.01.2019 ровно в 12:00. Пожалуйста:



Вот в первом столбце и есть реальное время. И мне не нужно этим вообще голову забивать. Это делается автоматом в ОС реального времени. Мне нужно только понимать, как это все работает, что бы правильно это использовать. Каждое значение имеет значение и реального времени. В этом и есть суть всех этих систем.

К примеру система управления движения поездами или авиа сообщением. Представляете, если данные не будут иметь этих меток или эти метки не будут синхронизированы?

[Shadow_ru]

Вникните в суть написанного

Я вроде вник.

Система реального времени посчитает и выдаст два значения Р1-0 с меткой 14:47:25.315 и 0-Р2 с меткой 14:47:25.317. В итоге вместо 3 бар вы получите два значения 6 бар и -3 бара с разницей по времени в 2 мкс

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

Я просто вам описал, как работают ОС реального режима в контроллерах  АСУ ТП

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

Передавать в строго определенное время нужно данные между контроллерами, которые требуются в расчетах

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

[Кass]

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

Это очевидно только вам. Поясните, в чем очевидность?

Потмоу что там стоят убогие процы с гиперциклами

Одни из самых дешевых ПЛК от Овена используют АРМ 9 уже лет 12. Толку то от этого? Все равно все работает точно так же. Если вы сделаете иначе, то можете оставить это себе в качестве игрушки. Никому не продадите ни одного комплекта. Вы не можете понять, что АСУ ТП - это не смартфон. Там нет такого, что чем быстрее, тем лучше. Там дорога ложка к обеду и все.

Повторюсь - есть системы и не требующие подобных костылей. Которые собирают высокоскоростными датчиками, фильтруют точки, считают параллельно параметры на цифровой модели процесса и при выбеге какого-то показателя с датчика - берут оттуда. И рулят они весьма высокоскоростными химреакторами без особых пролем.

Только это не системы реального времени. Таким образом вы можете сделать Тамагочи или контроллер к стиральной машине. АСУ ТП вы так не сделаете. Это никому не нужно. Если вы будете снимать данные каждые 100 нс, то вы просто положите каналы, сервера, все будет жрать море электроэнергии и ресурсов, а весь пар выйдет в свисток. Люди же еще и деньги считать научились. Сейчас же везде тендерная система. Есть ТЗ на построение системы, есть тендер. Кто дал лучшее предложение, тот и на коне. Если вы в каждый контроллер и субмодуль поставите по Ксеону, то вы не пройдете ни в один тендер, ибо ваша система будет стоить в сотни тысяч раз дороже в комплексе, чем у конкурентов. К примеру в одном бизнесцентре у нас получается пару сотен щитов автоматики. Вся система под ключ стоит порядка 12-15 млн рублей. Теперь просто посчитайте, если просто купить 200 i7 или Ксеонов. Вот ничего вообще больше не делать, ни серверов, ни каналов связи, ни софта, просто процессоры. Все? Вы никогда не получите ни одного заказа.

В промышленности умеют считать деньги. Более того, там никому не нужно снимать аналоговые данные чаще чем 1 раз в 10 мс максимум.  К примеру у меня стенд работает с периодом 50 мс. Перевести его на цикл в 10 мс, нужно пару секунд. Что дальше то? Вы думаете будет лучше работать? Ни сколько. Вот в 5 раз больше измерений, больше погрешность, больше данных в логах, а толку ноль вообще.

Более практичная задача, чем издевательства над АКБ, та, что я описывал выше. Насосная с одним щитом автоматики, в паре километров к пример вентиляционная, где есть датчик давления на входе и на выходе. Р1 и Р2. Нужно получать данные о давлении, и регулировать частоту. Все контроллеры для дешевизны решения общаются по полевой шине на RS-485. То есть одна пара витухи. Понятно, что по ней море параметров туда-сюда, включая и то, что передается мастеру для передачи на верхний уровень. Как часто вы собираетесь передавать с удаленного цита два параметра давления (флоат 4 байта) на щит в насосной? каждые 100 нс? )))  А как часто нужно передавать, если учесть инерцию насоса, что вы просто не можете мгновенно его раскрутить или остановить? Если это будет 1 рас в 100 мс, то это с огромным запасом. В принципе пойдет 500 мс. А что бы передавать все 1 раз в мкс, то нужно тогда тянуть по всему объекту оптику, поднимать на ней синхронные каналы, оптические кроссы, супер быстрые процессоры, стоимость растет в миллионы раз, а работать в лучшем случае будет так же, а в худшем вообще работать не будет.

[Shadow_ru]

Поясните, в чем очевидность

Ну закон Шеннона же. Если вам надо мерять процесс с некоей точностью по времени - снимайте показатели как минимум чаще в два раза, чем нужная точность. Да, я знаю, что по книжному он по другому звучит, но в данном случае - именно так он и будет работать. Сейчас можно поспорить про то, что еще надо посчитать коэффициент устойчивости и сигма времени должна быть не менее чем, но мне лень ) Идея, я полагаю, понятна.

используют АРМ 9 уже лет 12. Толку то от этого? Все равно все работает точно так же. Если вы сделаете иначе, то можете оставить это себе в качестве игрушки. Никому не продадите ни одного комплекта

Забавно звучит, потому что digital twin process control системы нынче считают крайне нужными, полезными и вваливают туда бабки тоннами. Сименсы всякие, да. А почему в Овене нет ? Ну повторюсь - никто учить асинхронным процессам АСУшников не хочет, да и привыкли они к трем циферкам в управлении.

Таким образом вы можете сделать Тамагочи или контроллер к стиральной машине. АСУ ТП вы так не сделаете. Это никому не нужно. Если вы будете снимать данные каждые 100 нс, то вы просто положите каналы, сервера, все будет жрать море электроэнергии и ресурсов, а весь пар выйдет в свисток

Таким образом ракеты летают, химреактора высокого давления и турбины размером с мамонта управляются.  И там не надо никаких невероятных каналов, повторюсь, данные используются для подкрепления цифровой модели, и если их не хватает для управления контуром с реальных датчиков - берутся из модели. Зачем мне 200 Ксеонов ? Хватит парочки и гигабитных каналов. Однако вы получите вместо туповатого ПИД контроллера систему много гибче. Тут вопрос, конечно, надо ли такое БЦ, но это такое - кому то понадобится, кому то нет. Вы же выставляете как единственную возможность - строить системы АСУ на гиперциклах. Повторюсь - это достаточно старый подход, есть и новее.

Вот в 5 раз больше измерений, больше погрешность, больше данных в логах, а толку ноль вообще

Очевидно нужен другой датчик, более скоростной, если текущий так шумит на малом диапазоне. Если его нет - то таки да, можно как диды.

работать в лучшем случае будет так же

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

[Кass]

Ну закон Шеннона же.

Если речь о теореме Шеннона — Хартли, то это из области связи, и не имеет никакого отношения к АСУ тП и системам реального времени.

Забавно звучит, потому что digital twin process control системы нынче считают крайне нужными, полезными и вваливают туда бабки тоннами. Сименсы всякие, да. А почему в Овене нет ?

Дело не в том, нет или да, а в том, что и на АРМе там те же самые циклы из реалтайма. Но при этом реализации ПЛК на АРМе не дала Овену ну абсолютн никаких плюсов. Ну не нужно это в АСУ ТП и все. Это просто удешевляет производство, к примеру банально потому, что Ethernet на борту, и не более. При этом куча проблем и море времени на разработку серьезных систем, и все, процессор более мощный, но применение только для самых простых систем. Ну не строит никто обмен низкого уровня через Ethernet по более очевидным причинам. Посему станок какой то автоматизировать без проблем, а построить АСУ ТП на пару сотен щитов автоматики и столько же объектов автоматизации на за что. Это будет ад.

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

Да ничего подобного. Ракеты начали летать еще когда вообще не было МК и процессоров. Все остальное в подавляющем числе на 8 битных МК работает. И прекрасно работает. Обратите внимание, что аварии только на новых объектах. Уж поверьте, чт порой приходится демонтировать "мощные" ПЛК, выбрасывать и ставить что то проверенное, когда люди намучались. Приходилось и JC выбрасывать и GE и многое другое. Коллекция большая. Потому и дома у меня не спроста море разных ПЛК на любой вкус.

Понимаете ли в чем дело. Вот нужна мотопомпа или бензокосилка. Так вот редкая глупость попытка поставить на них мотор от АМГ GTR или М5. Если вы такое сделаете, разведя заказчика на деньги, в итоге это работать не будет, и в конечном итоге придет профессионал, выкинет этот хлам и поставит маленький и слабенький проверенный двигатель. Дело в том, что надежность в АСУ ТП в миллионы раз важнее чем быстродействие МК.

Очевидно нужен другой датчик, более скоростной, если текущий так шумит на малом диапазоне.

Я уже промолчу, что такой датчик будет в сотни раз дороже, но опять пар будет в свисток, ибо инерция самой системы в миллион раз выше. Ну к примеру я замеряю частоту вращения ротора турбины. Вот какой смысл мне замерять ее через 1 мкс, если инерция ее в миллион раз выше?

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

Я прошу прощения, вы много создали систем АСУ ТП?    У нас котельная и так работает при отказе нескольких датчиков. Просто при отказе одного датчика вступает резервный алгоритм, при отказе следующего еще один резервный. Инерция процессов в котельных такова, что можно период выставлять хоть в 1 секунду. Там вообще все очень инертно.

Там проблема то как раз не в этом. Там нужно иметь огромную глубину архива СКАДА с огромным числом параметров. Если вы возьмете бесплатную MS SQL, то там объем базы 4 гига. Если вы начнете писать в нее тысячу параметров 1 раз в 1 мкс, то у вас база быстро переполнится. Хватит ее на 1000 секунд. И все.    А если нужно микро айтиикс всунуть в щит? Значит нужны мощные серверы с оптическими каналами. А если мне посмотреть что то пару лет назад? В общем это не более чем из пушки по воробьям.  

[SapienzSPB]

В общем это не более чем из пушки по воробьям. 

Это именно то о чем  я подумал когда прочитал:

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

Мне не все понятно из написанного в Вашем сообщении, но более не понятно зачем использовать для в общем-то простой и решённой задачи, с удовлетворительной точностью, очевидно избыточно-крутое железо. Я до него доберусь, конечно, со временем, как только у АТМЕГИ328, запрограммированой в ArduinoIDE, не останется ресурсов, чтобы реализовать мои хотелки. Если вникать в суть работы устройства и его компонентов, то нет нужды гнаться за производительностью (пусть и ценой всего 15 долларов). Мне принципиально интересно решить проблему изящно, наперекор современным тенденциям оверклокинга. Тем более что более половины времени проц недогружен и простаивает 

Спойлер

К примеру сейчас делаю идеальный диод для солнечных батарей. Могу на процессоре со статистикой, но интересно на счетверенном ОУ LM324. Просто спортивный интерес.

[slonenok]

это что это АКБ на Марс будут запускать ???

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

[Кобольд]

Может, давайте лучше про баб потрындим?

[AlexAi]

Может, давайте лучше про баб потрындим?

Из-за них и разговорах о них почти все войны в истории начинались.
Из-за ПЛК, АСУ ТП и реалтайма ещё пока никто не подрался.

[Яков93]

Из-за них и разговорах о них почти все войны в истории начинались.
Из-за ПЛК, АСУ ТП и реалтайма ещё пока никто не подрался.

То ли дело "паразитные диоды", вот это конечно повод для холивара 

[Cyberpapa]

То ли дело "паразитные диоды", вот это конечно повод для холивара

Очень важный спор. Чертежи опубликованы. [user]Яков93[/user], Вы разве не собираетесь изготавливать полевики с правильным диодом ?

[Яков93]

Очень важный спор. Чертежи опубликованы. [user]Яков93[/user], Вы разве не собираетесь изготавливать полевики с правильным диодом ?

Я еще не до конца вник, пагубно сказывается отсутствие профильного образования. 
Жду кто же в итоге победит, а то начнешь делать, а в итоге окажутся МОПы не той системы.

[serggio]

а то начнешь делать, а в итоге окажутся МОПы не той системы.

Ага. Вместо М в слове МОПы первая буква может быть Ж

[Кass]

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

В том то и дело, что никому не нужен калькулятор на i7. Да, это было бы круто, и его можно было бы выпустить под крутым брендом, под тем же огрызком, и скорее всего какая то часть любителей огрызков купили бы их чисто для понтов, для чего собственно и выпускается сия продукция, но АСУ ТП выпускается не для любителей и там сей трюк не пройдет.

Главное - система реального времени, эта не та, что выполняет все вычисления на 1 нс, а система, где каждое значение, что входное, что выходное вычисленное, имеет временную метку реальных часов, и при обмене такими данными передаются и временные метки. Если вы это реализуете на Атмеге 328, то это тоже будет система реального времени. Для этого всем контроллерам вашей системы нужно приделать часы реального времени и написать алгоритм их синхронизации, потом научиться после каждого измерения опрашивать часы, и вот когда кто то попробует это реализовать, он придет к тому, что я писал выше, как работают АСУ ТП, причем на любом железе.

[slonenok]

Может, давайте лучше про баб потрындим?

и очередной раз .многие подписались не по думавший .
а если копнуть поглубже ---- даже если и за них начиналось что то ---- то значит кто то хотел все зразу и много !
ему нужно показать --  что он самый самый крутой !   но весь сыр бор был в том ,что он в 95 % был начальником своего войска
но и у девченок тоже есть свои войны --- только у них изначально заложено -- быть обвешанными разными побрекушками и разной дребеденью и накормить его --что бы он мог дальше заниматься не понятно чем .
а у пацанов им многим интересно что нибудь взорвать .запустить куда нибудь что то изобрести,--- не важно что
и на фоне всего этого нам нужно реализовать свое изобретения в действии и показать что я сильнее его !
воины везде бывают и деревнях и между домами ,у нас раньше было 12 ти подъездный дом на такой же --только это было зимой . и тоже и за них
у кого власть побольше там  ! доказать свое превосходство ! чтобы она выбрала после битвы, какого героя  приласкать !!!!!

но есть и обратная сторона в 98% случаях не бывает идеальных исходов ,победы !  всегда возникают проблемы со здоровьем --- а кому нужен больной и и не дееспособный муж.--- который нечего не может !

если честно то можно и без всей этой показухи  -- и не каждый может пойти на примирения даже если он и прав !

[CMaxx22]

Прикольно. Мой пост был удалён перманентно с выносом предупреждения. Хотя он был полностью оправдан и злободневен, пусть и содержал слегка ненормативной лексики. А где же тогда можно всласть проораться, как не в гараже? Видимо задел за болячку админа, бывает, тоталитаризм....