Метеор-М №2-1 с попутчиками – Союз-2.1Б/Фрегат – Восточный 1С – 28.11.2017 08:41 ДМВ

[Serge V Iz]

Внутричерепного, что-ли?

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

[opinion]

Denis Voronin пишет:


Потому что регулярный рефакторинг кода это норма. Как и обновления по железу. Такова жизнь в IT.

Далеко не всегда и никогда не самоцель. Только когда код изменяется.

По ПО: есть программы на COBOL, которые реально используются. Людей, которые знают язык, давно нет, а проги работают.
По железу - истории о серверах, замурованных в стенах во время ремонта много лет назад, весьма недалеки от реальности.

[Denis Voronin]

opinion пишет:
По ПО: есть программы на COBOL, которые реально используются. Людей, которые знают язык, давно нет, а проги работают.

Раньше делали всё весьма монолитно. Но последние два десятка лет стараются делать модульно и обновляемо.

opinion пишет:
По железу - истории о серверах, замурованных в стенах во время ремонта много лет назад, весьма недалеки от реальности.

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

[Lunatik-k]

Denis Voronin пишет:

opinion пишет:
По ПО: есть программы на COBOL, которые реально используются. Людей, которые знают язык, давно нет, а проги работают.

Раньше делали всё весьма монолитно. Но последние два десятка лет стараются делать модульно и обновляемо.

opinion пишет:
По железу - истории о серверах, замурованных в стенах во время ремонта много лет назад, весьма недалеки от реальности.

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

Когда наступит осознание что процессом рулит не специалист, а кумы и сваты, то все вопросы сразу отпадают.

[Штуцер]

Lunatik-k пишет:
Когда наступит осознание что процессом рулит не специалист, а кумы и сваты, то все вопросы сразу отпадают.

Ну хватит уже. Мы осознали Вашу позицию.

[Morin]

SGS_67 пишет:

Morin пишет:
 

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

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

"Давно", - имеется в виду - вскоре после аварии, а не до нее. Если б знали ДО, то, конечно, как-нибудь довели до начальства. У меня были такие случаи. Без заявлений на стол. :-)

[Morin]

Denis Voronin пишет:

ZOOR пишет:
Наконец понял, кто виноват. Это были 2 геодезиста

Точно 2?

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

Чем они руководствовались мы знать не можем, но, точно, не проектной документацией, которой не было. Может рельеф местности позволял уменьшить объем земляных работ, может подъезд удобнее было организовать...? Х.з. Справедливости ради надо сказать, что строители пытались выяснить, как же им расположить ПУ, но ответа не получили. Наверное, был неофициальный ответ типа: Мы щас умеем с любого азимута пускать.

[Serge V Iz]

Я видел испытательный стенд для МДУ, при строительстве которого использовался удачно подвернувшийся огромный овраг.

[Denis Voronin]

Morin пишет:
Справедливости ради надо сказать, что строители пытались выяснить, как же им расположить ПУ, но ответа не получили.

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

[Кубик]

Morin пишет: типа: Мы щас умеем с любого азимута пускать.

А раньше не умели? и что изменилось, кроме способа поворота ракеты вокруг продольной оси в начале? На любой азимут - говорить надо.. И то практически далеко не на любой.

[Дем]

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

Morin пишет:
Справедливости ради надо сказать, что строители пытались выяснить, как же им расположить ПУ, но ответа не получили. Наверное, был неофициальный ответ типа: Мы щас умеем с любого азимута пускать.

Учитывая что ПУ расположено почти как надо, только наоборот - какую-то цифру про азимут всё же сказали. Но теперь тому кто сказал и ошибся на 180 стыдно признаться.

[Serge V Iz]

умеет ли компьютер и компилятор вообще реагировать на прерывания

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

[Кубик]

Дем пишет: Учитывая что ПУ расположено почти как надо, только наоборот - какую-то цифру про
азимут всё же сказали. Но теперь тому кто сказал и ошибся на 180 стыдно признаться.

Вот уж как проблемно всё оказалось..Да установите вы ракету на ПУ с поворотом на 180, оси переименуйте, ну и живите счастливо..  Если топлива на разворот по крену жаль, а виноватых найти надо..

[Serge V Iz]

Да установите вы ракету на ПУ с поворотом на 180,

Так ведь КЗМ куда-то подводить-отводить надо. Автомать.ика )

[Кубик]

Serge V Iz пишет:

Да установите вы ракету на ПУ с поворотом на 180,

Так ведь КЗМ куда-то подводить-отводить надо. Автомать.ика )

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

[Serge V Iz]

 болгарками и кувалдами могёт

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

[Кубик]

Занятно, что использование для запуска Союза-2 старых ПУ с поворотным кругом усложняет операции по подготовке.. Вот и чеши тут репу..

[Дем]

Serge V Iz пишет:
Вопрос не совсем того... Дракон слишком высокоуровневый для детализации того, как на уровне системного ПО этой машины реализовать механизмы доставки асинхронных событий.

А Скратч что круто низкоуровневый? Однако умеет.

[mind22]

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

Если писать программу с применением подхода, как в ПЛК (Программируемый логический контроллер), то на уровне прикладной программы никаких прерываний и не нужно.

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

[/li]
• считывание входных сигналов, в том числе манипуляций, например, на клавиатуре оператором;
• вычисления выходных сигналов и проверка логических условий;
• выдача управляющих сигналов и при необходимости управление индикаторами интерфейса оператора
  

Так же можно заметить, что ПЛК на C/C++ никто особо и не программирует. Для программирования используется стандартизированные языки МЭК (IEC) стандарта IEC61131-3:

Языки программирования (графические)

[/li]
• LD (Ladder Diagram) -- Язык релейных схем -- самый распространённый язык для PLC
• FBD (Function Block Diagram) -- Язык функциональных блоков -- 2-й по распространённости язык для PLC
• SFC (Sequential Function Chart) -- Язык диаграмм состояний -- используется для программирования автоматов
• CFC (Continuous Function Chart) -- Не сертифицирован IEC61131-3, дальнейшее развитие FBD
  

Языки программирования (текстовые)

[/li]
• IL (Instruction List) -- Ассемблеро-подобный язык
• ST (Structured Text) -- Паскале-подобный язык
• C-YART -- Си-подобный язык (YART Studio)
  

[opinion]

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

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

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

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