Изготовление макета с компьютерным управлением
сть ещё одна проблемка. При эксплуатации макета, когда поезд должен остановиться на определённом блок - участке, и уже с компьютера прошла команда стоп, в этот момент из-за помехи (не будем углубляться в причину помехи) команда не воспринимается локомотивом, и он продолжает движение, или снижает скорость, но всё равно продолжает движение (такое бывает). Есть идея дублировать команду “Стоп” но не с компьютера, а какими то отдельными устройствами. Скорее всего, это должно быть завязано с блоками занятости блок - участков. Над этим стоит подумать…
Если я что то понимаю, то самая главная проблема кроется даже не в том как обеспечить связь, а в том что импортнячий софт должен знать про эту связь и своевременно использовать ее в автоматическом режиме работы? Если делать совсем много собственной электроники то придется писать такое количество драйверов к софту что проще уже свой софт делать… кстати, а ведь достаточно много различных 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…) понадобится “блок совместимости” или “новая” командная станция?
А каковы перспективы совместимости этой новой шины с существующими командными станциями?
Если окажется что разработка удалась, появится спрос значит заинтересованные лица напишут драйвер, либо соорудят аппаратный шлюз в сеть которую коммандная станция понимает.
Ага и появится еще один узкоспециальный девайс за непомерные деньги, коих уже ворох наклепано 😃 Изобретение велосипедов вообще говоря доверия не вызывает.
Ага и появится еще один узкоспециальный девайс за непомерные деньги, коих уже ворох наклепано Изобретение велосипедов вообще говоря доверия не вызывает.
Так я собственно всю тему перечитал и не нашел ниодного места в тексте, где Вас принуждали бы покупать этот девайс… В конце концов здесь не реклама его, а тема о проекте…
Я не в пику, просто у меня лично создается впечатление, что Михаил в некоторых местах изобретает уже достаточно хорошо известные велосипеды. По какой причине, я достоверно не знаю, но подозреваю что из-за недостатка информации.
Так порой в этом (изобретении велосипедов) и заключается определенная прелесть 😃 Скорее всего так и придумали многоскоростной велосипед… 😉
Да тут как сказать 😃 Изобретение велосипедов в электронике жд моделестроения привело к тому, чем сейчас занимается Михаил 😃 К массовым проблемам стыковки всяких устройств работающих по разным, подчас кардинально, протоколам, как логически, так и физически.
Изобретение велосипедов вообще говоря доверия не вызывает.
Речи об изобретении велосипеда не было, речь была о модернизации существующего, или выпуске новой, более совершенной модели…
Изобретение велосипедов в электронике жд моделестроения привело к тому, чем сейчас занимается Михаил
Не столько изобретение велосипедов в ЖД моделестроении, сколько вообще работу практически с нуля без каких либо координаций друг с другом. Впрочем ЖД моделирование не далеко ушло и от ЖД реального, у них тоже не каждая колея, к любому “паровозу” подходит, а уж софт и автоматика в каждом ведомстве собственная, у нас в России то же самое … кстати, вчера прислал сюда, посмотреть на тему, одного своего знакомого какраз занимающегося автоматизацией на РЖД, вот что он ответил заглянув сюда - “у нас у товарища есть такой макет с действующей (реальной ) системой ж.д. автоматики”. вот такие велосипеды… никогда нельзя быть уверенным что впереди, макет сделан по подобию настоящего, или настоящее работает по подобию макета…
Ну раз уж мой вопрос вызвал такую дискуссию, внесу свой вклад. Велосипед изобретен в большей степени на бумаге т.е. есть открытый стандарт DCC и кроме как от производителя велосипеда ни от кого не зависит как он будет выглядеть мы имеем кучу разных на все вкусы, но в результате мы имеем “массовые проблемы стыковки…” запчастей от разных производителей. Самое обидное, что ни один производитель не заинтересован в изменении ситуации.
А Михаил прост сделать велосипеду вместо деревянных колес алюминиевые, вместо тормоза в виде палки дисковые тормоз и т.д. за что ему огромный респект.
И кроме него вряд ли найдутся “заинтересованные лица”, им проще будет продавать что-то “свое” сделанное по данной технологии.
Тут мнений может быть множество. Но при внимательном прочтении ветки мне показалось, что Михаил в процессе строительства сталкивается с некоторыми затыками, появление этих затыков меняет на ходу идеологию автоматизации и появляется осмысление подкрепленное опытом. Но со стороны, мне лично, как человеку причастному к жд моделизму, это переосмысление на ходу и вообще ход дела кажется странным, потому как проблемы как идеологического плана, так и технического возникают много раз обговоренные как у буржуев так и у нас. А Михаил как мне кажется вместо того что-бы внимательно эти вопросы изучить, решает затыки самоделками, которые и существующие-то стандарты не поддерживает.
ЗЫЖ Кстати ни на одном из живых российских жд форумов, насколько я знаю, о данном проекте нет ни слова 😦 А жаль.
Попробую внести ясность в дискуссию.
Я занимаюсь проектированием и изготовлением больших и сложных макетов, где движение организованно не по принципу “Каждый состав движется по своему кругу”, как делают большинство производителей, и, кстати, сделан Wonderland. Я активно использую стрелочные механизмы. По сложности я не знаю ни в России, ни в Европе более сложных проектов (Если я ошибаюсь - поправьте). И соответственно я сталкиваюсь с проблемами, которые на меньших макетах не встречаются. А так как проектов у меня несколько мне постоянно приходится вести учёт отказа работы оборудования.
Что касается разработки электроники, это вынужденная мера. Дело в том, что электроника ведущих производителей (я пробовал Littfinski, Lenz, Uhlenbrock, Esu, Roco, Viessmann, Digitrax и ещё ряд производителей) не рассчитана на сложные макеты. Когда общаешься с производителями, то понимаешь, что они сами не знают, как их электроник работает на подобных макетах. И в лучшем случае на вопрос “почему не работает” получаешь ответ “Что Вы хотите? Это же игрушка…” Вот и приходится городить своё оборудование. Если говорить о бюджете, то тут сразу понятно, что мне эти затраты не окупить. И это не коммерческий проект. Коммерческий проект это хорошо работающий сложный макет.
Цель моей ветки: Поделиться той информацией, которую я получаю в результате своей деятельности. И я буду искренне рад, если моя информация окажется кому- то полезна.
Есть хорошая новость: Сегодня вечером инженеры с Train Controller дали мне ссылку на открытый протокол, поддерживающий передачу информации адреса локомотива. УРА!!! Теперь всё срослось.
На вопрос о подключении к оборудованию других производителей: Мы можем без труда переделать своё оборудование на LocoNet и подключать его к оборудованию Uhlenbrock или Digitrax. Но какой в этом смысл?
Ай ладно, развели почти что флуд, бум следить за проектом и таки поглядим на результат 😃
Михаил, может быть попутно поделитесь другими сложными макетами? Хотя бы схемы того что реально реализовано.
Что касается разработки электроники, это вынужденная мера.
Все правильно. еще ни один производитель не сделал “игрушку” которая устроила бы абсолютно всех, менеджеры которые вам отвечают скорее всего вообще ни чего не понимают во внутренностях разработки. И вообще не удивлюсь если и у них все происходило примерно как же, один человек с энтузиазмом копался и создавал что то под улюлюканье, а кому то из манагеров пришло в голову, что все, хватит, пора продавать то что есть, и плевать им что не все работает так как хочется разработчику или как должно работать…
Отсюда вывод, чем дольше разработчик самостоятелен тем меньше проблем у разработки в будущем…
Поэтому Михаил, будет лучше если будешь прислушиваться только к советам/идеям по существу, остальное не понятно к чему…