Практическое значение тех или иных особенностей языка.

@BRcr · Регистрация: 03.02.2011

Комментарий модератора

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

Да ладно уж, можно и заоффопиться ненадолго.

На крайняк, если обсуждение окажется интересным, вынесем в другую тему - и всех делов.

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

@Fulcrum_013 · 18.12.2014, 19:39

Сообщение от taras atavin

Эти типы синонимичны и ни каких ошибок здесь быть не должно. Если компилятор их выдаёт - язык на помойку истории.

Спецы по Аде считают что если в таких случаях компилятор выдает ошибки то именно это делает его пригодным для написания надежного софта так как не даст к примеру сложить время со скоростью

@taras atavin · 18.12.2014, 19:50

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

Спецы по Аде считают что если в таких случаях компилятор выдает ошибки то именно это делает его пригодным для написания надежного софта так как не даст к примеру сложить время со скоростью

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

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
struct A
{
 int v;
};
struct B
{
 int v;
};
void f(A)
{
 ...
}
...
B b;
f(b);//Эта строка по правилам c/c++ не валидна.

.

@Fulcrum_013 · 18.12.2014, 19:58

Сообщение от taras atavin

чтоб в эти паузы делать что то, направленное на профилактику глюков/зависаний

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

Сообщение от taras atavin

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

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

@taras atavin · 18.12.2014, 20:09

Но к надёжности это не относится. Если ты складываешь время со скоростью, то не понимаешь, что вообще хочешь сделать и глюки тогда неизбежны. А когда типы фактического и формального параметров должны различаться, то выбор конкретного способа преобразования не будет неожиданностью. Например, если формальный параметр целый, а фактический - переменная, экспонента, то надо его округлить и это можно сделать как минимум тремя способами: вниз, вверх и к ближайшему. Если неявное приведение float к int запрещено, то выбор между

C++
1
2
x=exp(...);
f(round(x));

и

C++
1
2
x=exp(...);
f((int)x);

делается вручную. Наоборот, приведение int к float очевидно выполняется только одним способом - значение дополняется нулевой дробной частью. Соответственно можно автоматически подставить оператор приведения. с++ и на неявное приведение int к float, и наоборот выдаёт только предупреждение, для надёжного софта оно достаточно. А вот для того, чтоб полёт под уровнем моря вырубал автопилот нафиг, понадобилась, судя по всему, как раз АДА.

Добавлено через 7 минут

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

Откуда они там возьмутся? Там система хитро сделана.

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

@Fulcrum_013 · 18.12.2014, 23:56

Сообщение от taras atavin

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

Ну это не потому что не понимает а по описке.

Сообщение от taras atavin

А вот для того, чтоб полёт под уровнем моря вырубал автопилот нафиг, понадобилась, судя по всему, как раз АДА

Для этого нужен unsigned в канале барометрического высотомера. Переполнение вниз и самолет думает что он в космосе. А это коэффициенты для трубки Пито (скорость), коэффициенты коррекции во всех трех каналах рулей, автоматика триммирования, коэффициенты для противопомпажа, ну а в данном случае отключение радиовысотомера а вместе с ним и режима огибания рельефа местности.

Добавлено через 22 минуты

Сообщение от taras atavin

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

Естественно. Операционка там кстати вобщем то оффисная, но надежность там выше крыши. Siemens-R300-16. Приложений в системе вообще нет. Только обработчики прерываний по большому счету. 800kGz тактовая FPU - эмуляция на уровне микропрограмм, память 768KB.
Ну у меня правильно как то получалась. Занимался как раз тем что немцы в машину сувать побоялись - сбором логов и их парсингом, с поднятием тревоги (сирена в реальном времени) в случае пробоем, местами с выдачей команд главной машине. Техника конечно помощней была 8088 прикрутил к ней вместо телетайпа бо как тот сдох окончательно. Сбоить не сбоил, но был на грани по перегреву винта. вместо него нашли 286 приделал туда плюсом еще и эмулятор терминала. Были готовы эмулятор принтера, эмулятор графической станции, но на это техники не нашлось пока я там работал. То что прикрутили работало без обслуживания лет 8 подряд.

Добавлено через 14 минут
Делалось на Borland C++ 3.1 естественно с online Assembler.

Добавлено через 1 час 32 минуты

Сообщение от taras atavin

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

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

Добавлено через 1 час 33 минуты

Сообщение от taras atavin

или вместо МНЛЗ вообще юзаются изложницы, то она будет

На соседнем стане 1700 там вообще весело -он непрерывный а не реверсивный, хотя катают блюмы. Вернее блюмы раскатывает слябинг, они по рольганам идут на стан-1700 выквтываются в один проход а после прохода идут на холодный прокат тоже по рольгангам. Отам у них житуха - службы обслуживания в случае чего вызывают гудками - один гудок электрики, два гудка гидравлики и т.д, а то не успевают. А на соседнем комбинате там вообще звиздец - с конветера на стан слябы везут гоячими на белазах, и катают не подогревая. Спец-дорога по которой белазы носятся со скоростью 100-120 км/ч

@taras atavin · 19.12.2014, 08:27

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

Ну это не потому что не понимает а по описке.

Чёрта с два. По описке можно пропустить преобразование, когда специально подставляешь float на место int. Застрелить бандита из его же пулемёта тоже можно случайно. А булки с гвоздями складывает тот, кто не знает, что вообще хочет сделать.

Добавлено через 2 минуты

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

Для этого нужен unsigned в канале барометрического высотомера. Переполнение вниз и самолет думает что он в космосе. А это коэффициенты для трубки Пито (скорость), коэффициенты коррекции во всех трех каналах рулей, автоматика триммирования, коэффициенты для противопомпажа, ну а в данном случае отключение радиовысотомера а вместе с ним и режима огибания рельефа местности.

А как там вообще оказался ансигнед? На c/c++ это возможно только специально и даже на паскале это в принципе не возможно.

Добавлено через 4 минуты

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

Приложений в системе вообще нет.

Ктож станом то управляет?

Добавлено через 3 минуты

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

Ну у меня правильно как то получалась....Делалось на Borland C++ 3.1 естественно с online Assembler.

. Вот. А некоторые делают криво, зато на АДЕ.

@SatanaXIII · 19.12.2014, 10:53

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

Ну если по вашим меркам компоненты системы управления прокатным станом надежности не требуют.... ну тада я не знаю. И писал я там софт который как запустили в рабочем режиме так и пахал в режиме 24/7/365 без сбоев, и еще другие машины мониторил и их косяки выправлял. Скока лет не считал, но пока компы полностью не заменили.

Очень странно вообще, что для обслуживания прокатного стана используется пк. Это как раз противоречит предмету беседы. Сименсовские или шнайдеровские контроллеры, которые специально под это придуманы, софт, язык, все дела. Никакой самодеятельности. Что за завод, постеснялся я бы конечно спросить?

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

Кстати то же самое - режим работы 24/7/365 касается и мобилки и к примеру Wi-Fi
роутера.

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

@taras atavin · 19.12.2014, 11:14

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

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

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

Добавлено через 5 минут

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

Кстати то же самое - режим работы 24/7/365 касается и мобилки и к примеру Wi-Fi
роутера.

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

@Fulcrum_013 · 19.12.2014, 17:51

Сообщение от taras atavin

Ктож станом то управляет?

Обоаботчики прерываний

Добавлено через 5 минут

Сообщение от taras atavin

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

Да компы. Но там обычно
1. Нет операционки.
2. Одна программа заточенная под конкретную задачу, так что сбои по конфликту прилад исключаются.
Мало того вычислительная мощность современных контроллеров в большинстве случаев избыточна для управления техпроцессами. А вот красивые картинки по инфе получаемой пользователями можно генерить и на планшетах по выплевывемой контроллерами инфе. Соответственно, увал прилады с картинками на управляющий комп вообще никак не повлияет.

Добавлено через 2 минуты

Сообщение от taras atavin

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

НУ я роутер как купил так и не выключал.

Сообщение от taras atavin

В случае же самолёта, или технологического агрегата с глюком надо не бороться после его наступления, а недопустить. Хотя ещё какой самолёт.

Согласен. Ты кстати когда нибудь слышал о зависании контроллера в энергосберегающей лампочке? Я тоже никогда не слышал.

Добавлено через 10 минут

Сообщение от taras atavin

И если вышестоящий комп повис, или сглючил, то сглючит вся система.

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

@taras atavin · 19.12.2014, 18:12

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

Да компы. Но там обычно
1. Нет операционки.
2. Одна программа заточенная под конкретную задачу, так что сбои по конфликту прилад исключаются.

1. Операционка стоит на той машине, где верх системы.
2.1. Найди ка первое упоминание в теме конфликта прилад межу собой. Шей прогу хоть в ПЗУ (как это на контроллерах чаще всего и делается), если она криво написана, виснуть и глючить она будет. В бесконечный цикл уйдёт, или за границы массива выйдет, или просто окажется перепутана формула.
2.2. В сети могут конфликтовать и две прошивки, если одна шлёт данные не того формата, который может распарсить другая, или ждёт данные, которая вторая вообще не собирается посылать.
Так что вопрос надёжности решается не одним лишь выбором контроллера в качестве непосредственно управляющего приводом компа. Надёжными должны быть все компоненты, включая код, а его надо написать.

Добавлено через 9 минут

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

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

Ога. Вот только задача верха системы - не отображение картинок для красивости, а выбор уставок тому регулятору, который реализован на контроллере. Есть управление, а есть регулирование, сложными процессами ремиконты и сопоставимые с ними не управляют, их возможности очень быстро оказываются ограничены лишь регулированием. Я писал часть верха системы, так там чтоб тогдашний ПК хоть как то тянул, пришлось основательно сжать данные и покопаться в алгоритме. У какого контроллера 228 мебибайт памяти только на одно данное из 14, не считая самой проги? И это ещё на минимальных настройках, а так то эта прога схавает и терабайт, а после соответствующей перекомпиляции даже петабайт. А для низа да, характеристики контроллеров имеют даже запас.

Добавлено через 2 минуты

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

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

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

@Fulcrum_013 · 19.12.2014, 18:15

Сообщение от taras atavin

Найди ка первое упоминание в теме конфликта прилад межу собой. Шей прогу хоть в ПЗУ (как это на контроллерах чаще всего и делается), если она криво написана, виснуть и глючить она будет. В бесконечный цикл уйдёт, или за границы массива выйдет, или просто окажется перепутана формула.
2.2. В сети могут конфликтовать и две прошивки, если одна шлёт данные не того формата, который может распарсить другая, или ждёт данные, которая вторая вообще не собирается посылать.
Так что вопрос надёжности решается не одним лишь выбором контроллера в качестве непосредственно управляющего приводом компа. Надёжными должны быть все компоненты, включая код, а его надо написать.

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

@taras atavin · 19.12.2014, 18:17

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

Если мобилка или роутер заглючат, то скорее всего немного повисят и быстренько перезагрузятся.

Быстренько - это через три дня? Да и то причина перезагрузки была в питании роутера.

Добавлено через 1 минуту

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

А про то что данные не того формата - так это не то что между контроллерами, это и между двумя процедурами возможно.

В сырой проге на этапе отладки вполне ожидаемо, в действующей системе такого быть не должно.

@Fulcrum_013 · 19.12.2014, 18:23

Сообщение от taras atavin

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

То када было... система 78-го года разработки... там еще проц на нескольких платах. но делалось там по принципу как сейчас в контроллерах - все висит на прерываниях по приоритетам.

Добавлено через 1 минуту

Сообщение от taras atavin

сырой проге на этапе отладки вполне ожидаемо, в действующей системе такого быть не должно.

Естественно

@taras atavin · 19.12.2014, 18:30

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

А вот как раз вынос каждой задачи на отдельный проц(контроллер) снижает вероятность увала всего и сразу по увалу в одной подзадаче.

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

@Fulcrum_013 · 19.12.2014, 18:34

Сообщение от taras atavin

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

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

@taras atavin · 19.12.2014, 18:41

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

Добавлено через 5 минут

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

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

Это отлично настраивается вручную. А вот если пока перезагружают верх, на стане идёт брак, то чем это лучше остановившегося стана? В случае печи можно сталь выплеснуть. В металле искупаться не охота? Бывали случаи и такие. А в случае агрегата внепечной доводки все 380 тонн можно выбросить. Уж лучше тогда АКОС остановить, ковш отдать на УПСА, команды ввести вручную и всё таки разлить.

@Fulcrum_013 · 19.12.2014, 18:55

Сообщение от taras atavin

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

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

Добавлено через 10 минут

Сообщение от taras atavin

Это отлично настраивается вручную. А вот если пока перезагружают верх, на стане идёт брак, то чем это лучше остановившегося стана? В случае печи можно сталь выплеснуть. В металле искупать не охота? А в случае агрегата внепечной доводки все 380 тонн можно выбросить. Уж лучше тогда АКОС остановить, ковш отдать на УПСА, команды ввести вручную и всё таки разлить.

Ну лыжа это не брак, после клетей стоит правильная машина. Лист из клети выходит все равно ну как синусоида. В плоский его правильная машина превращает. Чем меньше лыжа (загиб края) тем удобнее пропускать через правилку.

Сообщение от taras atavin

Это отлично настраивается вручную.

Стоимость исследований по определению коэффициента жестости клети дороже новой клети, опять же требует остановки стана. А вот применеение нейронной сети которая постоянно подстраивается под уход коэффициента позволяет снизить размер обрезаемой кромки. Мало того, если возраст клети более 20 лет то наврное единственный способ давать толщину листа в допустимых пределах.

@taras atavin · 19.12.2014, 19:01

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

Вышестоящий комп вносит только задание (что нужно на выходе, раз на партию) и по вводу оператора усилие в последнем проходе.

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

Добавлено через 2 минуты

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

Стоимость исследований по определению коэффициента жестости клети дороже новой клети, опять же требует остановки стана. А вот применеение нейронной сети которая постоянно подстраивается под уход коэффициента позволяет снизить размер обрезаемой кромки. Мало того, если возраст клети более 20 лет то наврное единственный способ давать толщину листа в допустимых пределах.

1. Как же работали до создания адаптивных регуляторов?
2. Идентификация объектов ни когда не выполняется после их остановки. Данные как собирать?

@Fulcrum_013 · 19.12.2014, 20:21

Сообщение от taras atavin

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

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

Добавлено через 1 минуту

Сообщение от taras atavin

Как же работали до создания адаптивных регуляторов?

Обрезали некондиционный край и на переплавку. Мужики рассказывали что когда в начале 80-ых катали сталь на АПЛ то из листа вырезали полосу шириной в метр

Добавлено через 3 минуты

Сообщение от taras atavin

Идентификация объектов ни когда не выполняется после их остановки. Данные как собирать?

Естественно через датчики. УСО - устройство связи с объектом. Если оно данные не только собирает и передает вверх а сверху принимает непосредственные комманды на движеня приводами, а умеет в рамках своего участка обсчитывать по данным с датчиков и заданиям движения приводов, то это делает его менне зависимым от верхнего уровня. Оптимальны такие интеллектуальные УСО на конвейерах

Добавлено через 1 час 11 минут

Сообщение от taras atavin

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

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

@taras atavin · 19.12.2014, 20:34

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

Ну в конвертерной плавке тоже можно выделить независимые или малозависимые друг от друга процессы.

Я занимался АКОСом, там независимых каналов нет.

Новые блоги и статьи Все статьи Все блоги /
Контроль уникальности строк в табличной части документа Maks 18.06.2026 Алгоритм из решения ниже разработан на примере нетипового документа "ПланированиеСпецтехники" с табличной частью "НаличиеОборудования", разработанного в КА2. Задача: контроль уникальности строк в. . .	Клиент Uhbif79 18.06.2026 Здесь простой клиент для работы с сервером.	Сервер Uhbif79 18.06.2026 Выкладываю простейший сервер.	Дефенестрация kumehtar 18.06.2026 Узнал интересное слово. Дефенестрация. Это когда ты выбрасываешь кого-либо или что-либо из окна. Возьму на вооружение)))
Дихотомия добра и зла kumehtar 18.06.2026 Как Дзен-буддисты говорят о добре и зле: не нужно воевать против зла, нужно воевать против невежества. Тогда добро станет ествественным, и поэтому вечным. Но дело в том, что невежество всё время. . .	Своя Интернет-Компания iceja 18.06.2026 Я программист с экономическим образованием, пишу свой проект, это SaaS для бизнесов. Мне нужен co-founder с высшим экономическим образованием, и/ или инвестор. Сейчас проект в интенсивной разработке,. . .	24 Мат модель здравосохранения: функциональные требования к строительству пищеблока anaschu 18.06.2026 СРесурсами1: финансовый SD-контур, калькулятор функциональных требований пищеблока Сегодня разделили затраты в агенте Экономика по образцу модели НАСОСЫ, добавили расчёт ROI и построили первый. . .	23. что сделано за последнее время. anaschu 17.06.2026 • Эталон: Клиника НИИ питания РАМН, Москва — централизованный пищеблок, 225 коек, 180 пациентов • Git: репозиторий med2, ветка абсентеизм. Рабочий файл: СРесурсами1_v4. alp • Смежный проект:. . .