Изготовление макета с компьютерным управлением
я думаю управление идет по принципу адрес локомотива / номер блок участка. Что в итоге позволяет точно определять координаты и параметры.
На макете, на рельсах (по одной стороне) устанавливаются изоляторы, делящие макет на блок - участки. Основное требование к блок - участкам, чтобы длина состава была меньше длины блок-участков. (Хотя иногда можно использовать более короткие блок - участки). Стрелки обычно в блок-участки не входят (но при желании их можно привязать к нужному блок-участку) (См. фото). Питание к каждому блок - участку подаётся своё, через датчик занятости путей. Это блок, который реагирует на нагрузку, возникающую на определённом блок-участке, и в случае её возникновения (например: наличие на путях локомотива или вагона с установленным на колёсах сопротивлением подаёт сигнал на командную станцию, а она в свою очередь на компьютер. Блок передаёт информацию о номере блок - участка, на котором появилась нагрузка. Чтобы всё заработало, на датчик занятости надо подать сигнал управления локомотивом (он же является и питанием локомотива) с командной станции. В нашем случае это сигнал в формате DCC. А с датчика необходимо снять информацию о занятых блок - участках по шине обмена данных.
Сам блок-участок может быть разделён изоляторами на 2 или 3 отрезка (в зависимости от организации движения в одну или 2 стороны). При этом средний отрезок длинный, а крайние отрезки короткие (примерно по 15 см (в масштабе НО). Срабатывание блока занятости по крайним датчикам приводит в действие команду остановки поезда. Но такая схема не является единственной. В качестве тормозных датчиков можно использовать герконы, механические контакты, оптические датчики и т.д. У каждого решения есть свои преимущества и недостатки. Можно вообще обойтись без тормозных датчиков на блок - участках. Так работает классическая схема обратной связи на макетах железных дорог.
В моём случае я использую на локомотивах декодеры с функцией Rail Com (например, декодеры ESU, версии V4). Декодер с функцией Rail Com передаёт информацию о адресе локомотива. Блок занятости кроме информации о имеющейся нагрузки на конкретном блок-участке получает информацию о адресе (номере) локомотива находящемся на этом блок-участке и передаёт информацию на командную станцию по шине передачи данных. Командная станция обрабатывает эту информацию и передаёт её на компьютер с установленной программой управления макетом. После того, как адрес локомотива и его место положение автоматически определены программой она показывает его изображение на панели управления программой. Это нужно для того, чтобы программа при сбоях в работе не теряла локомотив. Кроме того, если Вы устанавливаете локомотив на макет, его не нужно прописывать. Всё за Вас сделает программа. Она тут же высветит его рисунок в том блок - участке, где он установлен.
Второй вопрос, который мы смогли решить это вопрос питания. В среднем командная станция может выдать ток 3-5 ампер. Этого хватит, чтобы использовать 3-7 локомотивов. А если надо больше, то приходится устанавливать бустеры. Чем больше локомотивов, тем больше бустеров. Можно поставить мощный, например ампер на 8. Но появятся проблемы с отработкой защиты, по короткому замыканию, особенно при длинных проводах. Кроме того в локомотивах довольно тонкие провода и большой ток может вызвать повреждение изоляции. Вывод: надо устанавливать больше бустеров, рассчитанных на меньший ток. Вот и получается нагромождение оборудования. Куча блоков занятости, куча бустеров.
Мы объединили датчики занятости с бустерами в одно устройство. В результате мы получили блок занятости, рассчитанный на 16 блок - участков с двумя бустерами по 3 ампера (каждый бустер отвечает за свои 8 блок-участков). Из них 7 блок - участков с функцией автоматического определения адреса локомотива.
Третий вопрос, который мы смогли решить: Мы создали свою шину обмена информации. Назовём её LN20. В результате мы смогли добиться увеличения скорости обмена данными и стабильности работы, при большом количестве блоков занятости и исполнительных механизмов.
Мы создали свою шину обмена информации.
Ну вы, блин даете… Я так чувствую итогом этого макета станет целый программно-аппаратный комплекс… В серию пускать не планируете? 😃
Планируем.
Планируем.
Не удивительно после такого объема работ)))
Я думаю, что любой, кто будет делать большой и довольно сложный макет рано или поздно столкнётся с проблемой подбора оборудования. А мы имеем готовое решение.
Но появятся проблемы с отработкой защиты, по короткому замыканию, особенно при длинных проводах. Кроме того в локомотивах довольно тонкие провода и большой ток может вызвать повреждение изоляции.
С этой проблемой можно побороться установкой электронных(самовосстанавливающихся) предохранителей прямо в локомотивах, размер и вес у них не большой, включаются в разрыв питания, при превышении тока разрывают цепь, после снятия напряжения восстанавливаются и снова работают пример 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…) понадобится “блок совместимости” или “новая” командная станция?
А каковы перспективы совместимости этой новой шины с существующими командными станциями?
Если окажется что разработка удалась, появится спрос значит заинтересованные лица напишут драйвер, либо соорудят аппаратный шлюз в сеть которую коммандная станция понимает.
Ага и появится еще один узкоспециальный девайс за непомерные деньги, коих уже ворох наклепано 😃 Изобретение велосипедов вообще говоря доверия не вызывает.
Ага и появится еще один узкоспециальный девайс за непомерные деньги, коих уже ворох наклепано Изобретение велосипедов вообще говоря доверия не вызывает.
Так я собственно всю тему перечитал и не нашел ниодного места в тексте, где Вас принуждали бы покупать этот девайс… В конце концов здесь не реклама его, а тема о проекте…