Не думал, что такие простые вещи нужно пояснять на хабре, но между колесом и полотном действуют силы трения. Они помогают как набирать скорость, так и останавливаться. Если бы их не было было бы невозможно ни то ни другое. При торможении между тормозными колодками и колесом поезда действуют силы трения скольжения, а между колесом и полотном — все те же — силы трения качения. При этом сила трения скольжения металл/металл меньше силы трения качения металл/металл. Поэтому большая часть энергии торможения тратится на работу по преодолению силы трения качения и меньшая — на скольжение. Надеюсь я подробно разжевал.
На тормозах нужно "рассеять" только половину этой энергии. Еще половина уйдет на трение между колесом и рельсом (если торможение без юза, иначе вклад будет еще меньше в сторону тормозов и больше в сторону рельс).
Циклы из shared_ptr это банальщина и enable_shared_from_this просто еще один из миллиона способов их сделать. А вот weak_ptr и make_shared это посерьезнее проблема. Когда все пользовательские деструкторы выполнились, а память в систему не вернулась.
сколько входных/выходных сигналов он способен обработать и с какой частотой опроса?
Давно дело было. Уже плохо помню точные цифры. Если память не подводит, то локальных модулей УСО можно было до 16 добавить + 4 модуля интерфейсной связи с корзинами, в каждой из которых снова до 16 модулей. Максимальное число дискретов (с групповой развязкой) в одном модуле — 16. Максимальное число аналогов — 8. Итого получается 16*5*16 — 1200 дискретов или 640 аналогов. Примерно так, но это не точно.
какова длительность рабочих циклов исполнительной программы, сколько их? Какую вообще минимальную длительность цикла данный контроллер способен реализовать?
Число параллельно исполняемых ресурсов в контроллере не ограничивалось, но разумно их было делать до 4х. Каждый ресурс мог работать с минимальным временем цикла 1 мс. При выполнении порядка 100 ПИД регуляторов, время выполнения было в районе 0,2-0,4 мс. Т.о. в ресурсе с самым быстрым циклом, который выполнял 100 ПИД регуляторов CPU нагружался где-то процентов на 40 прикладной задачей. Все остальные ресурсы могли быть использованы операционной системой, сетью, синхронизацией и т.п. службами.
используете ли вы симуляцию, чтобы отладить ПО контроллера
Безусловно. Существовало понятие виртуального контроллера, который мог полностью имитировать информационный обмен с УСО и межконтроллерные коммуникации (на самом деле все техпрограммы всех контроллеров проекта работали на одном большом сервере моделирования и межконтроллерные взаимодействия выполнялись просто через память). Помимо простой имитации УСО существовали продвинутые средства для написания программ моделирования технологических процессов на тех же самых технологических языках, семейства IEC 61131-3.
Он имеет смысл только при большом числе интеллектуальных датчиков и исполнительных механизмов. Как правило, на крупных локальных объектах автоматизации датчики и ИМ либо аналоговые и связь с ними по меди, либо поддерживают Modbus или Profibus в лучшем случае. Верхний уровень так же в основном по устоявшимся протоколам работает, типа OPC UA. Так что у нас с IIoT не очень развит.
Насколько я знаю, все шкафы с оборудованием заземляются обязательно. Все, что приходит с поля обязательно гальванически развязывается. Иногда потеря земли или даже некачественная земля приводят к трудно уловимым и невоспроизводимым глюкам в работе. Так что уверен, что все без исключения заземляется, причем не однократно.
Насколько я понимаю, сейчас все сводится к одноплатникам и даже SoC собственной разработки. Опять же тема "импортозапрещения" вносит свою лепту. Контроллеры перестают создавать из готовых "вражеских" модулей и всякие 104 оказываются не нужны.
Но я не разработчик железа, могу сильно заблуждаться.
Нередко на одной станции встречаются несколько поколений одного и того же ПТК. Иногда даже приходится интегрироваться со своим же софтом десятилетней давности.
Такое вот "работает — не трогай" на максимальных настройках.
Генератор, конечно синхронная машина, но всему есть пределы. Кроме того, до подключения в сеть, его следует разогнать до частоты сети и синхронизировать с сетью. Ну и в дальнейшем регулировку частоты и мощности никто не отменял.
Это еще что. Первые процессоры этой линейки были сделаны на советской элементной базе (типа, КР1847). На гетинаксовых платах и местами навесном монтаже. Вот где была жесть и низкая надежность, операционка — DOS 5.0 и системное ПО на ассемблере. Но это работало и поговаривают, что кое-где работает до сих пор. Дублирование и ЗИП творят чудеса.
Учитывая, что первая центральная электростанция была запущена в 1882 году, не удивительно, что все управление было механическим, довольно продолжительное время до наступления эры электроники.
Ну т.е. при торможении работа совершается силами (трения?) колеса и колодки, а силы, между колесом и рельсом работы не совершают? Ок.
Не думал, что такие простые вещи нужно пояснять на хабре, но между колесом и полотном действуют силы трения. Они помогают как набирать скорость, так и останавливаться. Если бы их не было было бы невозможно ни то ни другое. При торможении между тормозными колодками и колесом поезда действуют силы трения скольжения, а между колесом и полотном — все те же — силы трения качения. При этом сила трения скольжения металл/металл меньше силы трения качения металл/металл. Поэтому большая часть энергии торможения тратится на работу по преодолению силы трения качения и меньшая — на скольжение. Надеюсь я подробно разжевал.
На тормозах нужно "рассеять" только половину этой энергии. Еще половина уйдет на трение между колесом и рельсом (если торможение без юза, иначе вклад будет еще меньше в сторону тормозов и больше в сторону рельс).
Отличный, содержательный и полезный для остальных получится комментарий.
Ну не уверен — не включай. Выбор есть.
Кстати, декрементирование кармы тоже логично было бы оснастить похожим диалогом.
Предлагаю добавить опцию в профиле: Открытое минусование. По умолчанию пусть будет снята. Лично я бы ее у себя выставил.
Давно дело было. Уже плохо помню точные цифры. Если память не подводит, то локальных модулей УСО можно было до 16 добавить + 4 модуля интерфейсной связи с корзинами, в каждой из которых снова до 16 модулей. Максимальное число дискретов (с групповой развязкой) в одном модуле — 16. Максимальное число аналогов — 8. Итого получается 16*5*16 — 1200 дискретов или 640 аналогов. Примерно так, но это не точно.
Число параллельно исполняемых ресурсов в контроллере не ограничивалось, но разумно их было делать до 4х. Каждый ресурс мог работать с минимальным временем цикла 1 мс. При выполнении порядка 100 ПИД регуляторов, время выполнения было в районе 0,2-0,4 мс. Т.о. в ресурсе с самым быстрым циклом, который выполнял 100 ПИД регуляторов CPU нагружался где-то процентов на 40 прикладной задачей. Все остальные ресурсы могли быть использованы операционной системой, сетью, синхронизацией и т.п. службами.
Безусловно. Существовало понятие виртуального контроллера, который мог полностью имитировать информационный обмен с УСО и межконтроллерные коммуникации (на самом деле все техпрограммы всех контроллеров проекта работали на одном большом сервере моделирования и межконтроллерные взаимодействия выполнялись просто через память). Помимо простой имитации УСО существовали продвинутые средства для написания программ моделирования технологических процессов на тех же самых технологических языках, семейства IEC 61131-3.
Думаю свой, т.к. и чипсет там обычно свой. Но это не точно.
Он имеет смысл только при большом числе интеллектуальных датчиков и исполнительных механизмов. Как правило, на крупных локальных объектах автоматизации датчики и ИМ либо аналоговые и связь с ними по меди, либо поддерживают Modbus или Profibus в лучшем случае. Верхний уровень так же в основном по устоявшимся протоколам работает, типа OPC UA. Так что у нас с IIoT не очень развит.
Насколько я знаю, все шкафы с оборудованием заземляются обязательно. Все, что приходит с поля обязательно гальванически развязывается. Иногда потеря земли или даже некачественная земля приводят к трудно уловимым и невоспроизводимым глюкам в работе. Так что уверен, что все без исключения заземляется, причем не однократно.
Насколько я понимаю, сейчас все сводится к одноплатникам и даже SoC собственной разработки. Опять же тема "импортозапрещения" вносит свою лепту. Контроллеры перестают создавать из готовых "вражеских" модулей и всякие 104 оказываются не нужны.
Но я не разработчик железа, могу сильно заблуждаться.
Нередко на одной станции встречаются несколько поколений одного и того же ПТК. Иногда даже приходится интегрироваться со своим же софтом десятилетней давности.
Такое вот "работает — не трогай" на максимальных настройках.
Генератор, конечно синхронная машина, но всему есть пределы. Кроме того, до подключения в сеть, его следует разогнать до частоты сети и синхронизировать с сетью. Ну и в дальнейшем регулировку частоты и мощности никто не отменял.
Это еще что. Первые процессоры этой линейки были сделаны на советской элементной базе (типа, КР1847). На гетинаксовых платах и местами навесном монтаже. Вот где была жесть и низкая надежность, операционка — DOS 5.0 и системное ПО на ассемблере. Но это работало и поговаривают, что кое-где работает до сих пор. Дублирование и ЗИП творят чудеса.
Ну, это уже вне моей компетенции. Думаю, кто следит за этим, те в курсе.
В точку.
Учитывая, что первая центральная электростанция была запущена в 1882 году, не удивительно, что все управление было механическим, довольно продолжительное время до наступления эры электроники.