Изготовление макета с компьютерным управлением
Планируем.
Планируем.
Не удивительно после такого объема работ)))
Я думаю, что любой, кто будет делать большой и довольно сложный макет рано или поздно столкнётся с проблемой подбора оборудования. А мы имеем готовое решение.
Но появятся проблемы с отработкой защиты, по короткому замыканию, особенно при длинных проводах. Кроме того в локомотивах довольно тонкие провода и большой ток может вызвать повреждение изоляции.
С этой проблемой можно побороться установкой электронных(самовосстанавливающихся) предохранителей прямо в локомотивах, размер и вес у них не большой, включаются в разрыв питания, при превышении тока разрывают цепь, после снятия напряжения восстанавливаются и снова работают пример micronica.ru/docs/safetyfuse/special.shtml
А вообще, конечно все обалдеть как здорово у вас!
Срабатывание блока занятости по крайним датчикам приводит в действие команду остановки поезда. Но такая схема не является единственной.
Вчера видел док. на конструкцию в которой колеса локомотива снабжаются датчиками, для оценки скорости движения и перемещения, но там немного другая задача решалась вроде совсем не позиция состава …
Обычно датчики на колёса устанавливаются для синхронизации звука и дыма с движением локомотива. Но идея имеет право на существование. А вообще любую задачу можно решить десятком способов.
Есть ещё одна проблемка. При эксплуатации макета, когда поезд должен остановиться на определённом блок - участке, и уже с компьютера прошла команда стоп, в этот момент из-за помехи (не будем углубляться в причину помехи) команда не воспринимается локомотивом, и он продолжает движение, или снижает скорость, но всё равно продолжает движение (такое бывает). Есть идея дублировать команду “Стоп” но не с компьютера, а какими то отдельными устройствами. Скорее всего, это должно быть завязано с блоками занятости блок - участков. Над этим стоит подумать…
А если посылать команду “стоп” и в месте с ней отключать через какое-то время питание на блок участке?
сть ещё одна проблемка. При эксплуатации макета, когда поезд должен остановиться на определённом блок - участке, и уже с компьютера прошла команда стоп, в этот момент из-за помехи (не будем углубляться в причину помехи) команда не воспринимается локомотивом, и он продолжает движение, или снижает скорость, но всё равно продолжает движение (такое бывает). Есть идея дублировать команду “Стоп” но не с компьютера, а какими то отдельными устройствами. Скорее всего, это должно быть завязано с блоками занятости блок - участков. Над этим стоит подумать…
Если я что то понимаю, то самая главная проблема кроется даже не в том как обеспечить связь, а в том что импортнячий софт должен знать про эту связь и своевременно использовать ее в автоматическом режиме работы? Если делать совсем много собственной электроники то придется писать такое количество драйверов к софту что проще уже свой софт делать… кстати, а ведь достаточно много различных SCADA систем - применяемых какраз для подобных задач для визуализации в управлении процессами, есть и дорогие и не очень и совсем бесплатные … они не задочены под какую либо единственную задачу, но подобная реализация диспетчерского контроля на реальной ЖД есть и ей уже далеко не один год…
кстати, а ведь достаточно много различных SCADA систем
Большинство, насколько я сталкивался с ними (весьма поверхностно). Работают с DDE драйверами.
подобная реализация диспетчерского контроля на реальной ЖД есть и ей уже далеко не один год…
Подобным образом реализована диспетчеризация сортировки багажа в аэропортах
Подобным образом реализована диспетчеризация сортировки багажа в аэропортах
Что только не реализовано подобным же образом…
Есть идея дублировать команду “Стоп” но не с компьютера, а какими то отдельными устройствами. Скорее всего, это должно быть завязано с блоками занятости блок - участков. Над этим стоит подумать…
-
Обычно командные станции повторяют посылку последней команды до появления новой. То есть если станция выдала команду стоп декодеру с адресом 100, она будет циклически слать эту же команду пока не появится следующая команда для отправки. Хотя конечно может быть ситуация когда при большой плотности команд повторение пакета может не успеть произойти после того как помеха прекратится.
-
Большинство DCC декодеров умеют работать в двух режимах, собственно DCC и аналог. И практически все, кроме совсем уж убогих имеют настройку что делать в случае появления вместо сигнала DCC обычного DC. Я обычно настраиваю поведение следующим образом - при наличии DC - встать. На микромакете у меня это используется для предотвращения сноса тупиковых упоров и схода ПС. Хвост перед тупиковым упором несколько больший длины самого длинного лока запитывается от DC. В случае неостановки лока он попадает на участок с постоянкой и практически гарантированно встает.
А если посылать команду “стоп” и в месте с ней отключать через какое-то время питание на блок участке?
Если отключить питание на блок - участке, выключится освещение в вагонах, звук и т.д.
Есть смысл сделать устройство, передающее в DCC формате сигнал остановки на блок - участок, где должен был остановиться поезд. Это легко реализовать на тупиковых участках. Например, установить дополнительный датчик. При его срабатывании будет передаваться сигнал аварийной остановки. Сложнее с проходящими (сквозными) блок - участками.
Сбои при торможении это не проблема моей электроники. Это проблема всех цифровых систем управления макетами ЖД.
А в сторону ABC не смотрели? Скоммутировать диод на конкретный блок большого труда не составит.
www.tonystrains.com/technews/lenz-asy-abc.htm
Например, установить дополнительный датчик. При его срабатывании будет передаваться сигнал аварийной остановки. Сложнее с проходящими (сквозными) блок - участками. Сбои при торможении это не проблема моей электроники. Это проблема всех цифровых систем управления макетами ЖД.
Вот я же говорил там где-то что датчиков нужно больше 😃 Крайний на блоке используется как краш-стоп датчик, что до выключения освещения, согласитесь, данная ситуация (неостановка лока по команде) вообще говоря аварийная и такая мелочь как погасшее освещение по сравнению с возможностью аварии ничто.
- Обычно командные станции повторяют посылку последней команды до появления новой. То есть если станция выдала команду стоп декодеру с адресом 100, она будет циклически слать эту же команду пока не появится следующая команда для отправки
Скорее всего, тут проблема в самих станциях. С них уже сигнал не идёт.
Тупая Роко-цифра из стартового набора делает именно так. И если мне память не изменяет, то это прописано в стандарте. Вообще DCC как бы стандарт с хорошей устойчивостью к ошибкам. Мне кажется что скорее лок просто встанет от потери DCC чем не воспримет команду.
Мы создали свою шину обмена информации. Назовём её LN20.
А каковы перспективы совместимости этой новой шины с существующими командными станциями? (та же упомянутая “Тупая Роко-цифра”, ESU, LENZ, Uhlenbrock…) понадобится “блок совместимости” или “новая” командная станция?
А каковы перспективы совместимости этой новой шины с существующими командными станциями?
Если окажется что разработка удалась, появится спрос значит заинтересованные лица напишут драйвер, либо соорудят аппаратный шлюз в сеть которую коммандная станция понимает.
Ага и появится еще один узкоспециальный девайс за непомерные деньги, коих уже ворох наклепано 😃 Изобретение велосипедов вообще говоря доверия не вызывает.
Ага и появится еще один узкоспециальный девайс за непомерные деньги, коих уже ворох наклепано Изобретение велосипедов вообще говоря доверия не вызывает.
Так я собственно всю тему перечитал и не нашел ниодного места в тексте, где Вас принуждали бы покупать этот девайс… В конце концов здесь не реклама его, а тема о проекте…
Я не в пику, просто у меня лично создается впечатление, что Михаил в некоторых местах изобретает уже достаточно хорошо известные велосипеды. По какой причине, я достоверно не знаю, но подозреваю что из-за недостатка информации.
Так порой в этом (изобретении велосипедов) и заключается определенная прелесть 😃 Скорее всего так и придумали многоскоростной велосипед… 😉
Да тут как сказать 😃 Изобретение велосипедов в электронике жд моделестроения привело к тому, чем сейчас занимается Михаил 😃 К массовым проблемам стыковки всяких устройств работающих по разным, подчас кардинально, протоколам, как логически, так и физически.