У меня так работали московские магазины в базе, которая в +4 мск живёт. Проблем не было.
Ответил выше, какой часовой пояс сеанса ни установи, на отображение даты в имеющихся документах он не влияет. Вы, наверное, наоборот делали: дата в доке устанавливается в часовом поясе пользователя - но это абсолтно порочная практика, доки разных ЧП получаются вперемешку, а не в хронологическом порядке. А люди ж как хотят: чтоб в базе в таблицах всё в UTC (или каком другом, но едином ЧП), но если работаем в Мск - хотим видеть отображение этого же времени по Мск, работаем во Владике - хотим по Владику и т.п., а не заниматься прибавлением-вычитанием часов в уме.
Используется для определения текущей даты сеанса и получения оперативной отметки времени.
Это не то, т.к. нужно не просто определять текущую дату сеанса, а чтобы, скажем, один и тот же док с датой в БД 01.01.2024 00:00:00 UTC у пользователя с часовым поясом МСК отображался с датой 01.01.2024 03:00:00, у пользователя с часовым поясом ЕКБ отображался с датой 01.01.2024 05:00:00 итд. А также все остальные реквизиты типа "Дата" во всех формах и отчетах у пользователя на лету приводились к текущей дате его сеанса.
Я уже джва года жду (на самом деле сильно дольше) когда сделают нормальную поддержку часовых поясов, когда в базе всё хранится в UTC, а в интерфейсе дата отображается в часовом поясе клиента.
CAN тоже имеет разъёмы, тоже соединяется по цепочке. Прям на провод соплями ничего не вешают.
Stub'ы в CAN от провода отводят, daisy chain не нужен. В противном случае все устройства должны были бы иметь 2 порта (условные "вход" и "выход"). Также выход из строя или просто демонтаж любого из устройств не приводит к разрыву линии.
Там также адреса надо выставлять.
Не надо, у узла может быть как много идентификаторов, так и ни одного, одинаковые "идентификаторы" у разных устройств - также не редкость.
Я понимаю ваши переживания, но вы чуток передёргиваете
Вот схема из даташита: А ещё есть топология типа Ring
Вот интересно, если на шине цепочкой висит сотня таких девайсов, и все они работают по сути как повторители (сигнал ходит не напрямую от края до края шины), то при скорости среды в 10 Мбит/с, какова будет реальная скорость обмена между первым и последним узлом. А если они все еще и будут активно общаться, да пакетами размером в килобайт, будет ли вообще это работать, или всё потонет в синхронизациях и коллизиях. Честно - я не знаю, было бы интересно узнать.
У вас там датчики не свои? Ну так сделайте свои. У вас же серьёзная задача.
Мы же тут не про какую-то конкретную задачу говорим, а про "в принципе", про перспективы новых протоколов в промышленной автоматизации, нет? Вот есть (или скоро появятся, если говорить о сабже) станки c интерфейсом на стандартных протоколах, есть инженерное оборудование (вентиляция, электрораспределительное оборудование), есть телеметрические датчики. И протокол либо будет позволять работать с ними "из коробки", либо нет, и потребуются какие-то переходные платы и подобн (либо эти переходные платы придется добавлять в качестве довеска в каждое устройство). Пока что, то, что я вижу в T1 - оно либо более сложно и дорого, чем CAN, либо дает меньшую гибкость или лимитировано по функционалу. Возможно, найдутся применения, где это оправдано, но с точки зрения универсальности пока это решение вопросов вызывает больше, чем есть ответов.
Коммутаторам еще и питание нужно, и подводить его в разных местах вдоль шины - тот еще геморрой. Обычно потребителям на шине достаточно трёх незадействованных пар кабеля, чтобы подать питание по ним, соответственно, нужны низковольтовые (12-36В) коммутаторы, которые умеют питаться от той же шины и одновременно потреблять достаточно мало, чтобы на длинной высокоомной шине не просаживать напряжение ниже уровней, которые могут вытянуть импульсники (сомневаюсь, что это вообще возможно).
Вы просто представьте что вы предлагаете. Вот идут у меня 20 датчиков с интервалом в 50 метров каждый. В случае с CAN мы просто берем 3 бухты витой пары и бросаем, садя устройства прямо на провод. В вашем случае я даже не представляю что вы предлагаете, каждые 50 метров вешать на линию предлагаемое выше устройство-переходник? А какой протокол будет на шине? Обычный 10Base-T работать не будет (слишком длинная шина), 10Base-T1 - тоже (не умеет в multidrop). Коммутаторы ставить каждые 100 метров? Тогда зачем нам вообще тут T1L, это обычный Ethernet выйдет)
И что значит "делаете систему с нуля"? Промышленная автоматизация чуть менее, чем полностью, состоит из готовых модулей управления, датчиков, сенсоров, которые из коробки можно садить прямо на шину, в этом и суть стандартов.
Так по первой ссылке-то переходник с T на T1L. Ставите два таких на длинную линию, и вот у вас связь на полтора километра с разъёмами типа T с обоих сторон.
Если бы у нас была задача передать данные точка-точка на километр, можно было бы просто кинуть оптику. Здесь же идет речь о совсем другой задаче, когда у нас длинная линия и множество узлов, рассредоточенных по этой линии. Ваш переходник эту задачу не решает.
Но это не означает, что больше устройств подключить невозможно. Надо просто отказаться от идеи-фикс садить абсолютно все устройства на один провод, и поставить нужное количество коммутаторов. Точно также как это делается в нормальных сетях.
Пфф... В нормальных промышленных сетях шины могут идти на километры. С вашим подходом вы как затраты на СКС увеличиваете минимум на порядок, так еще и абсолютно лишние коммутаторы нужно ставить.
Судя по спецификации, это вообще ни разу не такой же Ethernet. Почему тогда много где упоминается, что по стандарту S поддерживается длина шины до 25 метров с гарантированным кол-вом узлов равным 8? В CAN нужна длинная шина - уменьшаем скорость. Здесь как будто 10 Мбит - фикс (что косвенно следует из названия), соответственно, и шину длиннее 25м не сделать?
И поверх 10Base-T1 есть масса решений, включая прямой выход в глобальную сеть с огромным количеством опенсорсных проектов.
Берем самое банальное промышленное применение. Дано: некое производственное помещение длиной в сотню-другую метров, и пара десятков (или сотен) управляемых узлов. Нужен большой (скажем, килобайт) размер пакета, а скорость передачи здесь выведем за скобки, чтобы не усложнять расчеты. 10Base-T1 справится с такими вводными?
В интернете сравнений полно, я и конкретно это читал, но они поверхностные (ту проблематику, которую я обозначил хотя бы в комменте выше, они в явном виде не рассматривают), и вопросики позадавать некому (поэтому на хабре и не любят статьи-переводы, т.к. обычно автор такой публикации ни бе, ни ме по предмету от себя добавить не может).
Однако с CAN XL я чипов не нашёл. А 10Base-T1 уже есть доступные и недорогие.
Он появился лет 5 назад, а XL всего пару лет назад, т.ч. с доступностью последнего у ширнармасс, видимо, придется еще годик подождать.
Судя по фоткам, вообще не совсем понятно зачем там ардуины. Блок с дешифраторами в DIP-корпусах там уже присутствует, можно попробовать работать напрямую с ними.
Тогда уж наверное проще использовать CAN - стандартный интерфейс, дифпары, меньше сигналов.
Для такого проще modbus rtu поверх какого-нибудь rs485: протокол прост как три рубля, железяки стоят три копейки (и не нужен контроллер), скорости те же, ну и за раз 256 байт можно передать.
Вообще я нигде не писал, что он "лучше" или "хуже". Ещё не щупал руками, но по описании 10Base-T1S/L я для себя вынес, что это чуть более быстрая свистелка (на ~20%, что само по себе не очень существенно), чем XL. При этом, это "чуть" достигается засчет того, как работает PLCA: необходимость в мастер-ноде, отсутствие приоритизации сообщений, необходимость в присваивании узлам уникальных ID и ведении их списка на мастере, упрощенный механизм отключения от шины сбоящей ноды, ограничение на максимальное количество нод, очень короткая линия для T1S, либо отсутствие шины вовсе (только peer-to-peer) для T1L.
Для кого-то у XL-контроллеров также плюсом будет обратная совместимость со всем вплоть до еще паянного дедушкой в сарае из навесных элементов классического CAN.
Но если у вас есть конкретный опыт, напишите статью, где приведите более подробное сравнение, с удовольствием почитаю.
Это да некоторые железяки для контрольной суммы не делали nrz, а другие делали в результате для "везучих" пакетов ack распологался в разном месте и такой пакет никогда не доходил.
Ок, просто отмечу, что это функция контроллера, трансивер ничего про контрольные суммы не знает, его задача - напряжения и крутизна фронта.
По поводу помех, у нас вообще оптика использовалась, что бы помех было поменьше.
Конвертеры среды волокно-CAN видел, но CAN по оптике - это как?
Лучше вы расскажите что она у вас не тянет?
Ответил выше, какой часовой пояс сеанса ни установи, на отображение даты в имеющихся документах он не влияет. Вы, наверное, наоборот делали: дата в доке устанавливается в часовом поясе пользователя - но это абсолтно порочная практика, доки разных ЧП получаются вперемешку, а не в хронологическом порядке. А люди ж как хотят: чтоб в базе в таблицах всё в UTC (или каком другом, но едином ЧП), но если работаем в Мск - хотим видеть отображение этого же времени по Мск, работаем во Владике - хотим по Владику и т.п., а не заниматься прибавлением-вычитанием часов в уме.
Это не то, т.к. нужно не просто определять текущую дату сеанса, а чтобы, скажем, один и тот же док с датой в БД 01.01.2024 00:00:00 UTC у пользователя с часовым поясом МСК отображался с датой 01.01.2024 03:00:00, у пользователя с часовым поясом ЕКБ отображался с датой 01.01.2024 05:00:00 итд. А также все остальные реквизиты типа "Дата" во всех формах и отчетах у пользователя на лету приводились к текущей дате его сеанса.
Я уже д
жва года жду (на самом деле сильно дольше) когда сделают нормальную поддержку часовых поясов, когда в базе всё хранится в UTC, а в интерфейсе дата отображается в часовом поясе клиента.Stub'ы в CAN от провода отводят, daisy chain не нужен. В противном случае все устройства должны были бы иметь 2 порта (условные "вход" и "выход"). Также выход из строя или просто демонтаж любого из устройств не приводит к разрыву линии.
Не надо, у узла может быть как много идентификаторов, так и ни одного, одинаковые "идентификаторы" у разных устройств - также не редкость.
Вот интересно, если на шине цепочкой висит сотня таких девайсов, и все они работают по сути как повторители (сигнал ходит не напрямую от края до края шины), то при скорости среды в 10 Мбит/с, какова будет реальная скорость обмена между первым и последним узлом. А если они все еще и будут активно общаться, да пакетами размером в килобайт, будет ли вообще это работать, или всё потонет в синхронизациях и коллизиях. Честно - я не знаю, было бы интересно узнать.
Мы же тут не про какую-то конкретную задачу говорим, а про "в принципе", про перспективы новых протоколов в промышленной автоматизации, нет? Вот есть (или скоро появятся, если говорить о сабже) станки c интерфейсом на стандартных протоколах, есть инженерное оборудование (вентиляция, электрораспределительное оборудование), есть телеметрические датчики. И протокол либо будет позволять работать с ними "из коробки", либо нет, и потребуются какие-то переходные платы и подобн (либо эти переходные платы придется добавлять в качестве довеска в каждое устройство). Пока что, то, что я вижу в T1 - оно либо более сложно и дорого, чем CAN, либо дает меньшую гибкость или лимитировано по функционалу. Возможно, найдутся применения, где это оправдано, но с точки зрения универсальности пока это решение вопросов вызывает больше, чем есть ответов.
Коммутаторам еще и питание нужно, и подводить его в разных местах вдоль шины - тот еще геморрой. Обычно потребителям на шине достаточно трёх незадействованных пар кабеля, чтобы подать питание по ним, соответственно, нужны низковольтовые (12-36В) коммутаторы, которые умеют питаться от той же шины и одновременно потреблять достаточно мало, чтобы на длинной высокоомной шине не просаживать напряжение ниже уровней, которые могут вытянуть импульсники (сомневаюсь, что это вообще возможно).
Вы просто представьте что вы предлагаете. Вот идут у меня 20 датчиков с интервалом в 50 метров каждый. В случае с CAN мы просто берем 3 бухты витой пары и бросаем, садя устройства прямо на провод. В вашем случае я даже не представляю что вы предлагаете, каждые 50 метров вешать на линию предлагаемое выше устройство-переходник? А какой протокол будет на шине? Обычный 10Base-T работать не будет (слишком длинная шина), 10Base-T1 - тоже (не умеет в multidrop). Коммутаторы ставить каждые 100 метров? Тогда зачем нам вообще тут T1L, это обычный Ethernet выйдет)
И что значит "делаете систему с нуля"? Промышленная автоматизация чуть менее, чем полностью, состоит из готовых модулей управления, датчиков, сенсоров, которые из коробки можно садить прямо на шину, в этом и суть стандартов.
Если бы у нас была задача передать данные точка-точка на километр, можно было бы просто кинуть оптику. Здесь же идет речь о совсем другой задаче, когда у нас длинная линия и множество узлов, рассредоточенных по этой линии. Ваш переходник эту задачу не решает.
Пфф... В нормальных промышленных сетях шины могут идти на километры. С вашим подходом вы как затраты на СКС увеличиваете минимум на порядок, так еще и абсолютно лишние коммутаторы нужно ставить.
Это вы плохо смотрели. T1L - это peer-to-peer, а не шина (только 2 устройства).
Судя по спецификации, это вообще ни разу не такой же Ethernet. Почему тогда много где упоминается, что по стандарту S поддерживается длина шины до 25 метров с гарантированным кол-вом узлов равным 8? В CAN нужна длинная шина - уменьшаем скорость. Здесь как будто 10 Мбит - фикс (что косвенно следует из названия), соответственно, и шину длиннее 25м не сделать?
Берем самое банальное промышленное применение. Дано: некое производственное помещение длиной в сотню-другую метров, и пара десятков (или сотен) управляемых узлов. Нужен большой (скажем, килобайт) размер пакета, а скорость передачи здесь выведем за скобки, чтобы не усложнять расчеты. 10Base-T1 справится с такими вводными?
В интернете сравнений полно, я и конкретно это читал, но они поверхностные (ту проблематику, которую я обозначил хотя бы в комменте выше, они в явном виде не рассматривают), и вопросики позадавать некому (поэтому на хабре и не любят статьи-переводы, т.к. обычно автор такой публикации ни бе, ни ме по предмету от себя добавить не может).
Он появился лет 5 назад, а XL всего пару лет назад, т.ч. с доступностью последнего у ширнармасс, видимо, придется еще годик подождать.
Судя по фоткам, вообще не совсем понятно зачем там ардуины. Блок с дешифраторами в DIP-корпусах там уже присутствует, можно попробовать работать напрямую с ними.
Для такого проще modbus rtu поверх какого-нибудь rs485: протокол прост как три рубля, железяки стоят три копейки (и не нужен контроллер), скорости те же, ну и за раз 256 байт можно передать.
Вообще я нигде не писал, что он "лучше" или "хуже". Ещё не щупал руками, но по описании 10Base-T1S/L я для себя вынес, что это чуть более быстрая свистелка (на ~20%, что само по себе не очень существенно), чем XL. При этом, это "чуть" достигается засчет того, как работает PLCA: необходимость в мастер-ноде, отсутствие приоритизации сообщений, необходимость в присваивании узлам уникальных ID и ведении их списка на мастере, упрощенный механизм отключения от шины сбоящей ноды, ограничение на максимальное количество нод, очень короткая линия для T1S, либо отсутствие шины вовсе (только peer-to-peer) для T1L.
Для кого-то у XL-контроллеров также плюсом будет обратная совместимость со всем вплоть до еще паянного дедушкой в сарае из навесных элементов классического CAN.
Но если у вас есть конкретный опыт, напишите статью, где приведите более подробное сравнение, с удовольствием почитаю.
С появлением CAN XL всё это legacy можно уже начать забывать.
Смешались в кучу кони, люди...
Ок, просто отмечу, что это функция контроллера, трансивер ничего про контрольные суммы не знает, его задача - напряжения и крутизна фронта.
Конвертеры среды волокно-CAN видел, но CAN по оптике - это как?
Робот "построен в лесу" примерно также, как я "живу в лесу", т.к. вокруг города - лес.