Изготовление макета с компьютерным управлением
Наконец нашёл время и доделал вокзал. Осталось только покрасить и склеить.
Чертовски интересная тема! А какой размер “паравозиков” используете?
Пардон. обнаружил масштаб НО
Из всех масштабов больше всего нравится НО. Надёжная механика, хороший токосъём, куча производителей. Очень красиво ездят по макету.
Наконец нашёл время и доделал вокзал.
А каков размер вокзала ДхШхВ? Какой толщины пластик используете? Это макет существующего вокзала или “из головы”? Сколько материала ушло на строительство? Очень интересная тема и макеты тоже!
Вокзал примерно (Д;Ш;В) 1635х435х240. Материал: ПВХ 2мм; 3мм; 4мм; 5мм; 10мм, Оргстекло прозрачное 1мм. Материала ушло несколько квадратов. Точно сказать не могу, но довольно много. Больше всего ушло пластика: 2мм (на стенки), 10мм (из него фрезерованы все столбы и несущие элементы).
Вокзала такого не существует. Давно задумывал сделать проект 2-х уровневого вокзала, где на оба уровня будут приходить поезда, с автостоянкой и рестораном на верхнем уровне.
За счёт большого количества стёкол, подвижной состав хорошо просматриваться.
Михаил, как успехи с данным проектом?
Делаю ландшафт.
На днях выложу фотки. Все заезды в тоннели резал вручную. Надоели покупные. На всех макетах одни и те же элементы.
К сожалению, много времени уходит на электронику. Сделали мы блоки занятости блок-участков с поддержкой функции автоматического определения адреса локомотива. Представьте как удобно: Вы ставите на рельсы локомотив, а программа тут же определяет его адрес и место положения. Сейчас делаем командную станцию, поддерживающую эту функцию. Проблема в том, что присоединить оборудование к программе управления макетом TrainController просто не получается. Протоколы, поддерживающие функцию автоматического определения адреса локомотива являются закрытыми (их всего 3. У ESU, Lenz, Digitrax). А те, которые в открытом доступе не поддерживают данную функцию.
Зато если не брать в расчёт проблемы с автоматическим определением адреса, система управления получилась. И сейчас мы её доводим…
Сейчас делаем командную станцию, поддерживающую эту функцию. Проблема в том, что присоединить оборудование к программе управления макетом TrainController просто не получается. Протоколы, поддерживающие функцию автоматического определения адреса локомотива являются закрытыми (их всего 3. У ESU, Lenz, Digitrax). А те, которые в открытом доступе не поддерживают данную функцию.
Очень интересная фича, а каким образом, происходит определение адреса? Сам принцип действия любопытен… И что более конкретно имеется ввиду под адресом локомотива? это координаты в пределах макетного поля или какие то еще привязки?
Сделали мы блоки занятости блок-участков с поддержкой функции автоматического определения адреса локомотива.
Что такое блоки занятости? разделители участков полотен или что то более интересное?
И что более конкретно имеется ввиду под адресом локомотива?
Я так понимаю это уникальный адрес (номер) локомотива, для адресации команд.
Я так понимаю это уникальный адрес (номер) локомотива, для адресации команд.
Вот отсюда и вопрос. Адрес может быть логический - имя/номер, а может очень даже физический 😉 координата местоположения, тогда и вопрос…
как “общаться” с оборудованным локомотивом вроде более менее документированно, а как на автомате проконтроллировать его место на макете? не вычислять же из “пробега” и заданной скорости… при ручных манипуляциях составами, вроде все более менее ясно…
я думаю управление идет по принципу адрес локомотива / номер блок участка. Что в итоге позволяет точно определять координаты и параметры.
На макете, на рельсах (по одной стороне) устанавливаются изоляторы, делящие макет на блок - участки. Основное требование к блок - участкам, чтобы длина состава была меньше длины блок-участков. (Хотя иногда можно использовать более короткие блок - участки). Стрелки обычно в блок-участки не входят (но при желании их можно привязать к нужному блок-участку) (См. фото). Питание к каждому блок - участку подаётся своё, через датчик занятости путей. Это блок, который реагирует на нагрузку, возникающую на определённом блок-участке, и в случае её возникновения (например: наличие на путях локомотива или вагона с установленным на колёсах сопротивлением подаёт сигнал на командную станцию, а она в свою очередь на компьютер. Блок передаёт информацию о номере блок - участка, на котором появилась нагрузка. Чтобы всё заработало, на датчик занятости надо подать сигнал управления локомотивом (он же является и питанием локомотива) с командной станции. В нашем случае это сигнал в формате 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 драйверами.
подобная реализация диспетчерского контроля на реальной ЖД есть и ей уже далеко не один год…
Подобным образом реализована диспетчеризация сортировки багажа в аэропортах