LINUX.ORG.RU

Вышел NoRT CNC Control 0.4

 


2

2

Состоялся новый релиз разрабатываемой мной системы управления фрезерным станком с ЧПУ. В этом релизе в основном исправлены недоработки и баги предыдущего релиза (Вышел NoRT CNC Control)

Улучшения:

  • Переделан планировщик скорости движений. Новый планировщик полностью анализирует движение от начала и до конца, в том числе учитывает кривизну дуг при движении по дуге и выбирает максимально возможную скорость впределах установленных скоростей так, чтобы не превысить максимально допустимых ускорений
  • Часть конфигурации, которая хранилась в RT части на микроконтроллере, полностью перенесена в python код
  • Исправлены проблемы с потерей фокуса в UI при ручном вводе команд
  • Добавлена возможность независимо эмулировать шпиндель и координатный стол
  • Исправлены баги состояния машины при ручном вводе команд
  • Скорректирован цикл отсылки сообщений в координатный стол и на шпиндель, корректная обработка сигнала резета и обработка сообщения о резете от микроконтроллера
  • Добавлена CRC в протокол взаимодействия с микроконтроллером
  • Завершение работы при отключении USB serial порта, если взаимодействие с микроконтроллером идет через него - ранее система начинала в цикле читать уже несуществующий ttyUSB0
  • Теперь движения заблокированы после перезагрузки микроконтроллера. Чтобы разблокировать, надо послать в микроконтроллер специальную команду. Она отсылается при старте исполнения g-code. Тем самым исключается некорректное движение в случае внезапной перезагрузки MCU в ходе движения

Параллельно с написанием кода я уже использую станок под его управлением. Недавно напилил детальки для модели планера. Тем самым этот код уже используется на практике.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 3)

Ответ на: комментарий от torvn77

А так как у меня дуги представляются не набором отрезков, а именно дугами, то основной компьютер говорит МК, чтобы он прошелся по такой-то дуге с такой-то скоростью, и все. Задача обеспечения формы дуги лежит целиком на МК.

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от cvs-255

Ладно, если ты будешь брать следующие координаты не по сервопериоду, а по факту их достижения то твоя идея будет работать.

torvn77 ★★★★★
()
Ответ на: комментарий от cvs-255

К тому моменту когда ты напишешь и раскрутишь своё ЧПУ индустрия перейдёт на интерполяцию кривыми кубическими(G5), квадратическими(G5.1) и NURBS блоками (G5.2,G5.3)

torvn77 ★★★★★
()
Ответ на: комментарий от torvn77

Ну добавлю я тогда и эти кривые в свою систему. На написание и отладку движения по дуге ушло несколько вечеров довольно ленивого программирования

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от cvs-255

Эти криаые программировать не так просто, у них могут быть особые параметры которые приводят к движениям по очень шмешным траекториям и всё это надо отлавливать.

torvn77 ★★★★★
()
Ответ на: комментарий от torvn77

рассчитывать геометрию я умею

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от cvs-255

Если задача заменить RS232 - то в пределах одной подсети можно просто с MAC на MAC пакеты гонять и вообще не париться. Заголовок пакета туп как пробка - 6byte dstMAC, 6byte srcMAC, 2byte EtherType (значение >=0x600 - тип пакета <0x600 - размер данных). И это будет прекрасно по сегменту бегать. Стека никакого вообще не нужно. Из-за значительно большей скорости, всякие свитчи и пр. встретившиеся на пути, никак не повлияют на latency по сравнению с RS232.

Чем удобнее ethernet по сравнению с прочими

  • обычно инфраструктура для него уже есть готовая. Не надо тянуть отдельные кабели, просто воткнуть девайс в ближайший свитч.
  • можно гонять без проблем по оптике. Это аццкий ништяк при работе с мощным оборудованием - ни тебе земляных петель, ни наводок, ничего. Есть, конечно конвертеры CAN<>Fiber но это редкость и нужна отдельная оптика.
  • Много хорошо известных микрух и качественных готовых либ для ethernet.
  • Можно всегда перейти на уровень выше - IP, UDP/TCP, HTTP/TFTP/...
  • Если очень нужно, всегда можно обеспечить полный гарантированный realtime кинув отдельную верёвку между master и slave, хотя обычно этого не требуется - скорость и постоянство задержек после того, как свитч запомнит в каком порту какой MAC весьма кстати для realtime. Гораздо больше проблем с reatime создаёт нынешнее x86 железо и ОС ведущего компа.
Stanson ★★★★★
()

Круто конечно, но где почитать в чём отличия от аналогов? Что смотивировало писать свою версию?

zabbal ★★★★★
()
Ответ на: комментарий от Stanson

Вообще, я так думаю, что ethernet излишен. Все равно, например, шпиндель я по rs485 включаю с компа. А значит комп близко должен быть, чтобы не тянуть длинную витуху для rs485. Да и всякий обдув и сож, когда будут, тоже не с микроконтроллера включаться будут. А значит либо еще одна плата с ethernet, либо напрямую с компа. И второе реалистичнее.

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от zabbal

Сподвигло 2 причины:

затруднения с использованием linuxcnc с ноутбука, ибо из интерфейсов только usb, который для реалтайма вообще не подходит

Ограниченность решений типа grbl

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от cvs-255

Если комп рядом, то вообще пофиг каким интерфейсом пользоваться, можно хоть ножки LPT дёргать, чтобы тот же насосик сож включать.

Stanson ★★★★★
()
Ответ на: комментарий от dekar

В ethernet забыли collision resolver(не detectiin) завезти. Для реалтайма он не подходит.

А про EtherCAT что скажете? Я выше писал. Интересно, встречались ли с ним на практике? Если да, то какие там минусы? А то с моего дивана видно одни плюсы :)

TwisteR ★★
()
Ответ на: комментарий от Stanson

Если очень нужно, всегда можно обеспечить полный гарантированный realtime кинув отдельную верёвку между master и slave

смешно - как можно гарантировать реалтайм если изернет не гарантирует доставку пакетов. Для изернета нужно городить протокол верхнего уровня для контроля доставки и целостногсти данных, а если говорить о сети а не прямом соединении - еще для арбитража на основе приоритетов. В CAN всё это из коробки.

anonymous
()
Ответ на: комментарий от anonymous

смешно - как можно гарантировать реалтайм если изернет не гарантирует доставку пакетов

Так ни один интерфейс этого не гарантирует. CAN тоже. Да даже дорожка на плате от одной микрухи к другой этого не гарантирует.

Для изернета нужно городить протокол верхнего уровня для контроля доставки и целостногсти данных,

Можно подумать в CAN иначе.

В CAN всё это из коробки.

Нет там ничего из коробки. Там из коробки полудуплексная линия связи из проводочков CANH и CANL. Нужно данные передавать, да ещё с гарантированной доставкой - будь любезен стек написать. Ну или заплатить за девайс где чужой дядя уже всё для тебя сделал. Точно так же, как с Ethernet или любым другим способом передачи данных.

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от Stanson

Нет там ничего из коробки

есть ACK в конце каждого фейма для контроля что кто-то тебя услышал, есть специальный error frame для контроля целостности, есть арбитраж на основе приоритета фрейма. В изернете ничего этого нет и он херачит фреймы в никуда - там вообще невозможно контролировать сеть.

anonymous
()
Ответ на: комментарий от Stanson

Можно и usb lpt воткнуть, чтобы насосы включать. можно что другое. Тут уж вариантов масса

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от anonymous

есть ACK в конце каждого фейма для контроля что кто-то тебя услышал, есть специальный error frame для контроля целостности, есть арбитраж на основе приоритета фрейма.

Мда. Если ты не в курсе, то это всё не какая-то особая CAN магия, появляющаяся сама по себе когда ты начинаешь дебильно дёргать один проводок от 0 до 2.5 а другой от 5 до 2.5 вольт, а кем-то реализованная в стеке функциональность. И в отличии от ethernet, реализации этой функциональности оставляют желать лучшего.

В изернете ничего этого нет и он херачит фреймы в никуда - там вообще невозможно контролировать сеть.

Вообще-то никто не мешает передавать те же самые фреймы CAN внутри пакетов Ethernet и получить абсолютно ту же самую функциональность что и у CAN без прокладывания отдельнях проводов и с гораздо большей скоростью. Вот только нахрена этот убогий CAN реализовывать, если есть гораздо более приличные протоколы,

CAN вообще придумывался Bosch'ем для автомобилей, для передачи _некритичной_ информации на короткие расстояния (да, никто не передаёт по CAN информацию от, например, датчика положения коленвала к ЭБУ двигателя, а вот окошки открывать или на приборку уровень топлива в бензобаке доставлять оно уже годится). Недостатков у CAN - выше крыши, начиная от низкой скорости, высокого оверхеда из-за ограниченного размера пакета и т.д. и заканчивая простым фактом того, что при сдыхании любого одного драйвера на шине, полностью перестаёт работать вся сеть.

Так что при нынешней доступности деталек для Ethernet, нет вообще никакого смыла пердолится с CANBus.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

кем-то реализованная в стеке функциональность

не знаю в курсе ли ты - это реализовано в контроллерах CAN аппаратно - для этого не нужен какой-то еще стек

передавать те же самые фреймы CAN внутри пакетов Ethernet и получить абсолютно ту же самую функциональность что и у CAN без прокладывания отдельнях проводов и с гораздо большей скоростью

для CAN-сети нужно 2 проводка а для изернета специальная витая пара и свичи, поэтому изернета нет в автомобилях и не будет - есть CAN FD

Так что при нынешней доступности деталек для Ethernet, нет вообще никакого смыла пердолится с CANBus

для сетей интернет- конечно нет, для автомобилей и промышленности CAN рулит.

anonymous
()
Ответ на: комментарий от anonymous

не знаю в курсе ли ты - это реализовано в контроллерах CAN аппаратно - для этого не нужен какой-то еще стек

Ну так и контроллеры Ethernet есть аппаратные - вплоть до TCP. WIZnet там всякие типа W5100 и пр. Я ж говорю - не хочешь сам стек писать - заплати кому-то, получишь что угодно, вплоть до аппаратного вариант - что CAN что Ethernet, разницы никакой. Вот только взять даром готовый отлаженный программный стек CAN - хрен выйдет, в отличии от Ethernet.

для CAN-сети нужно 2 проводка а для изернета специальная витая пара и свичи, поэтому изернета нет в автомобилях и не будет - есть CAN FD

Вот пусть в автомобилях и остаётся.

для сетей интернет- конечно нет, для автомобилей и промышленности CAN рулит.

Для автомобилей - да, хотя и там сходу найти издохший девайс - приходится всё подряд отключать с шины, пока не наткнёшся, для промышленности же CAN - пожалй один из наихудших вариантов. Я периодически имею дело со спектрофотометрами у которых голова по CAN подключается - вечная борьба с земляными петлями, непонятными наводками и пр. И это на 125kbit. В последнее время хотя бы конвертеры CAN-Fiber появились, чуть попроще стало, хотя с оптикой другая проблема - на отечественных предприятиях ещё дохрена дебилоидов, которые кабели в узлы завязывают или гвоздями прибивают а потом невинную рожу делают «а чо такого-то? всегда так делали, чо.».

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 3)
Ответ на: комментарий от Stanson

Ну так и контроллеры Ethernet есть аппаратные - вплоть до TCP

и как давно TCP включили в стандарт Ethernet ?

для промышленности же CAN - пожалй один из наихудших вариантов. Я периодически имею дело со спектрофотометрами у которых голова по CAN подключается - вечная борьба с земляными петлями, непонятными наводками и пр.

не пойму - чем в данном случае CAN хуже того же rs485 на физическом уровне.

Недостатки изеренета - необходимость специальных кабелей и оборудования - такие сети громоздкие, дорогие, энергозатратные, при том что для управления и телеметрии преимущества они не имеют никакого.

anonymous
()
Ответ на: комментарий от Stanson

Для ethernet нужно phy и трансформатор. Плюс специальный разъем. Тоже все это не бесплатно в магазинах раздают

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

и как давно TCP включили в стандарт Ethernet ?

Бгг. :) Какой-ниубдь ISO-TP или CANOpen тоже нифига не включен в ISO11898. :)

не пойму - чем в данном случае CAN хуже того же rs485 на физическом уровне.

Ничем. Ethernet лучше и того и другого.

Недостатки изеренета - необходимость специальных кабелей и оборудования - такие сети громоздкие,

Чем это витуха или опта громоздкая, если речь о промышленном применении а не автомобильном? Тем более, что обычно CAN витухой и прокидывают.

дорогие,

Сколько там 125kbps CAN-Fiber конвертер стоит? А тот же IXXAT USB-CAN?

энергозатратные,

Мы ж о промышленном применении говорим. Для какой-нибудь бумагоделательной машины разница в пару десятков миллиампер на девайс не отличима от нуля.

при том что для управления и телеметрии преимущества они не имеют никакого.

Ну подключи по CAN систему промышленного зрения, например. :) CAN медленный - этого уже достаточно.

Stanson ★★★★★
()
Ответ на: комментарий от cvs-255

Для ethernet нужно phy

Не всегда. достаточно много однокристалок и контроллеров со встроенным phy.

и трансформатор.

На самом деле тоже необязательно, если нужно во что бы то ни стало сэкономить этот десяток центов. С развязкой прекрасно справится трансформатор на другом конце.

Плюс специальный разъем.

Ты не поверишь. Можно и на разъёме сэкономить.

Тоже все это не бесплатно в магазинах раздают

А барахло для CAN бесплатно раздают, что-ли?

Не, в машине CAN на своём месте - не надо тянуть кучу проводов из водительской двери ко всем остальным, или там жгутище со всех концов к приборке. Но на предприятии - как-то сомнительно, в промышленности CAN это такое же легаси как RS485/422. Они не отвечают нынешним потребностям, да и аппаратные средства нынче позволяют Ethernet в любой датчик пихнуть.

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от Stanson

Какой-ниубдь ISO-TP или CANOpen тоже нифига не включен в ISO11898

контроль передачи, целостности и арбитраж - это стандарт CAN

Ничем

перед этим ты говорил что он самый худший :)

Сколько там 125kbps CAN-Fiber конвертер стоит? А тот же IXXAT USB-CAN?

нисколько, для CAN-сети нужно 2 проводка и встроенный контроллер

Ну подключи по CAN систему промышленного зрения

у тебя какие-то странные представления о промышленности :) в АСУ ТП это зрение нужно чуть чаще чем никогда, разве что гуманоидов контролировать.

anonymous
()
Ответ на: комментарий от anonymous

контроль передачи, целостности и арбитраж - это стандарт CAN

Ты не поверишь, но в Ethernet тоже есть и преамбула и CRC и окончание пакета и даже всякие TP_IDL, просто ты этого никогда не видишь, т.к. это обрабатывается контроллером.

перед этим ты говорил что он самый худший :)

Он хуже RS485 необходимостью заморачиваться с адресацией и тратить почти полпакета на оверхед. Но речь шла о замляных петлях и наводках. А с точки зрения земляных петель и наводок, разницы между CAN и RS485, естественно, никакой нет.

у тебя какие-то странные представления о промышленности :) в АСУ ТП это зрение нужно чуть чаще чем никогда, разве что гуманоидов контролировать.

Вот недавно был на заводе по производству сайдинга. Нифига не rocket science. Так у них даже нанесение рисунка на «кирпичики» фундаментного сайдинга управляется через камеру. Камера видит как лежит заготовка, и робот в нужных местах пульвером водит. Хотят ещё на стеновой сайдинг поставить, чтобы контролировать нанесение рисунка. У бумажников тоже камеры повсюду - дефекты и пятна ловить. Текстильщики победнее, но те кто ткани с рисунком делает тоже промзрение очень хотят и потихоньку начинают раскошеливаться.

Stanson ★★★★★
()
Ответ на: комментарий от cvs-255

Да, кстати, когда делал себе «умный дом» (не в том смысле, который сейчас хайпят), то натурально оказалось дешевле ethernet использовать даже чтобы с контроллера насоса скважины текущее состояние (давление, время работы насоса, ошибки и пр.) на сервак кидать. Потому что для CAN/RS485 надо было как минимум трансиверов накупить и USB затычку в сервак. А для ethenet всё под рукой было - и копеечные PIC18F1320 и трансформаторы и разъёмы. А уж витуха и обжиматор по умолчанию у любого нерукожопа есть. Так что даже всякие DS18B20 у меня из погреба и прочих мест по ethernet вещают. И бардака никакого - все девайсы в одну сеть подключены, хоть камеры, хоть датчики, хоть релюшки. И если что-то из этого сдохнет, то всё остальное будет работать как ни в чём не бывало. А не как с CAN/RS485 - сдох один девайс, труба всей шине.

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 2)
Ответ на: комментарий от Stanson

Третий раз пишу в этом треде про EtherCAT, что-то все игнорируют. Я вот, когда узнал про него, тоже сразу понял, что теперь нет никакого смысла сношаться с CAN/RS485/RS422 в тех случаях, где планируется опрашивать больше трёх устройств в реальном времени. Немного большие расходы на обвяз, как по мне, стоят тех преимуществ, которые предоставляет данная технология. А вы как думаете?

TwisteR ★★
()
Ответ на: комментарий от Stanson

Ты не поверишь, но в Ethernet тоже есть и преамбула и CRC и окончание пакета и даже всякие TP_IDL

в случае ошибки изернет-фреймы просто дропаются

Вот недавно был на заводе по производству сайдинга

ну в полиграфии наверно нужен визуальный контроль, но на одну камеру приходится наверно сотни датчиков, измерителей, приводов - нафик им этот изернет сдался

anonymous
()
Ответ на: комментарий от anonymous

в случае ошибки изернет-фреймы просто дропаются

Ну и достаточно. Если есть потери пакетов в ethernet - это, во-первых, легко обнаруживается следующим уровнем, а во-вторых, это означает, что где-то проблема и её надо срочно чинить. А когда проблем нет пакеты не пропадают. Рассчитывать промышленное оборудование на работу через говённый канал связи - это кем надо быть-то? Особенно если учесть, что стоимость канала на порядки порядков меньше стоимости прочего оборудования.

ну в полиграфии наверно нужен визуальный контроль, но на одну камеру приходится наверно сотни датчиков, измерителей, приводов - нафик им этот изернет сдался

Чтобы увеличить частоту опроса датчиков и, соответственно, уменьшить время реакции на отклонение. А так же, чтобы собирать гораздо больше данных. Очевидно же. И да, сотни датчиков ты уже запаришься по CAN опрашивать. :)

ЗЫ: Полиграфия - вообще не промышленность :) Ну по крайней мере совершенно несерьёзная. А когда газеты-журналы подохнут окончательно, останутся только книжки в небольших количествах, а там и без промышленного зрения всё нормально.

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от Stanson

Чтобы увеличить частоту опроса датчиков и, соответственно, уменьшить время реакции на отклонение. А так же, чтобы собирать гораздо больше данных.

а кому это нужно ? применяемые технологии должны соответствовать требованиям иначе это экономически невыгодно.

anonymous
()
Ответ на: комментарий от TwisteR

Может и взлетит, но попозже. Для начала пусть хотя бы документацию откроют полностью.

Так-то промышленность достаточно консервативная штука, и EtherCAT для них только недавно появился. Ну и до сих пор нету SoC с integrated phy чтобы только разъёмы с трансформаторами подключить. Да и контроллеров-то не очень, только микрочиповский LAN92чего-то там на ум приходит.

Stanson ★★★★★
()
Ответ на: комментарий от anonymous

а кому это нужно ? применяемые технологии должны соответствовать требованиям иначе это экономически невыгодно.

Именно. Вот у тебя с машины идёт бумага шириной 12 метров и скоростью полтора километра в минуту. Тебе надо за её толщиной следить, причём по всей ширине. CAN экономически не выгоден, потому что пока ты по CAN опросишь несколько сотен датчиков, у тебя полкилометра бумаги в брак уйдёт.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

пока ты по CAN опросишь несколько сотен датчиков, у тебя полкилометра бумаги в брак уйдёт

я не говорил что всегда и везде CAN. Кстати, какой там минимальный payload у изернет фреймов ? с учётом гарантийной доставки пакетов (повторов передачи при ошибках) 100 мегабитный изерент для 100 датчиков еще медленней CAN окажется

anonymous
()
Ответ на: комментарий от anonymous

с учётом гарантийной доставки пакетов (повторов передачи при ошибках) 100 мегабитный изерент для 100 датчиков еще медленней CAN окажется

кстати - удачи тебе дешевых микроконтроллеров с гигабитным изерентом найти

anonymous
()
Ответ на: комментарий от anonymous

Кстати, какой там минимальный payload у изернет фреймов ?

Минимальный размер фрейма - 64 байта. Заголовок - 14 байт, CRC 4 байта. Так что 46 байт данных. Несколько меньший оверхед, чем у CAN. Особенно с учётом того, что максимальный размер - 1522 байта, а у CAN - фиксированный.

я не говорил что всегда и везде CAN

Ну так и я не говорю что всегда и везде ethernet. В автомобиле он вполне на своём месте. Или в качестве интерфейса внутри одного девайса вполне может сгодится. А вот уже даже для банального сбора данных с сотни датчиков лучше использовать что-то другое.

с учётом гарантийной доставки пакетов (повторов передачи при ошибках) 100 мегабитный изерент для 100 датчиков еще медленней CAN окажется

Ещё раз. Если в ethernet есть потери, то надо не пакеты повторно передавать, а ремонтировать сеть. Точно так же, как если на серваке демон упал, его не перезапускать надо, а разбираться чо за херня.

Тем не менее, 100Mbps с TCP, где доставка пакета гарантирована, на порядки уделывает CAN даже 1Mb. А если учесть что на предприятиях не любят 1Mbps и работают на 125kbps, из-за наводок и помех, которых в отличии от автомобиля на заводе дофигищи может быть, то CAN вообще тухло выглядит.

Stanson ★★★★★
()
Ответ на: комментарий от anonymous

кстати - удачи тебе дешевых микроконтроллеров с гигабитным изерентом найти

10/100 для промавтоматики пока вполне достаточно. Но если понадобится, то никаких проблем нету. Цена SoC с гигабитным контроллером - ну $5 вместо $2. Для предприятия - неотличимая от нуля величина.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Если в ethernet есть потери, то надо не пакеты повторно передавать, а ремонтировать сеть

просто этот стандарт не расчитан на условия произодства

100Mbps с TCP, где доставка пакета гарантирована, на порядки уделывает CAN даже 1Mb

еще бы пруфов вместо лозунгов

anonymous
()
Ответ на: комментарий от Stanson

Цена SoC с гигабитным контроллером - ну $5 вместо $2. Для предприятия - неотличимая от нуля величина.

ну такой SoC (я так понимаю это медитеки, алвиннеры и прочая лабуда) можно сразу в унитаз выкинуть - для них документации даже нет, а андроид в контроллерах разве что идиот на производстве станет использовать

anonymous
()
Ответ на: комментарий от anonymous

просто этот стандарт не расчитан на условия произодства

CAN вообще рассчитан на автомобили. А вот Ethernet как раз промышленный стандарт.

еще бы пруфов вместо лозунгов

С математикой не дружим? Там считать-то нечего.

1Mbps без потерь, при оверхеде в 40% на заголовки - за секунду 75 килобайт.

100Mbps c потерями 50%, при оверхеде в 2% - за секуду 6 мегабайт.

А если учесть, что ethernet full-duplex, то CAN вообще ни о чём.

Stanson ★★★★★
()
Ответ на: комментарий от anonymous

ну такой SoC (я так понимаю это медитеки, алвиннеры и прочая лабуда) можно сразу в унитаз выкинуть - для них документации даже нет, а андроид в контроллерах разве что идиот на производстве станет использовать

Во-первых, на всём перечисленном прекрасно работает и mainline ядро. На производстве как бы не особо нужно видосики декодировать и в игрухи OpenGLные резаться.

Во-вторых, я не слышал о том, что все роутеры и телеприставки на китаеSOC'ах массово дохнут. Бывают неудачные модели, но в общем и целом с надёжностью всё весьма неплохо.

В-третьих, не нравится китайщина, ну есть TI Sitara, STP32MP, iMX 6 и т.д. тоже с ценой от $5. Там может за эти деньги и не будет GPU и VideoCore но нахера они в станке?

В-четвёртых, даже если бы они стоили не $5 а $50, то это неотличимая от нуля сумма если речь идёт о промышленных девайсах. Один из самых дешёвых лазерных измерителей смещения - Panasonic HG-C1xxx один стоит ~$200. Для измерения толщины их надо по две штуки на точку. Десяток точек будут $4000 стоить. На этом фоне даже $50 - вообще ни о чём.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Он хуже RS485 необходимостью заморачиваться с адресацией

Сам по себе rs485 хоть и не требует адресации, но если хотим больше, чем точка-точка, то адресация уже нужна

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от Stanson

Уточни пожалуйста по микросхемам свичей. Вот скажем если я хочу несколько контроллеров на одгой плате держать, и у кажого свой интерфейс, насколько просто объединять их через микросхему свитча? Есть ли возможность подключать их к свичу без phy, а наружу из платы вывести 1 разъем?

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от cvs-255

Сам по себе rs485 хоть и не требует адресации, но если хотим больше, чем точка-точка, то адресация уже нужна

Разумеется. Если надо точка-точка, то RS485/422 вполне годен. Если надо 10 не сильно отдалённых девайсов свзяать, как например, в автомобиле, то CAN вполне подойдёт. Если запросы побольше - то кроме Ethernet толком ничего и не придумаешь. Плюс Ethernet в том, что он перекрывает весь диапазон задач при не сильно больших затратах средств и времени. А т.к. речь о промышленности, то ещё и инфраструктура для него там уже есть.

До сих пор, кстати, удивляюсь, как USB смог взлететь. Идеальным вариантом был бы Ethernet + PoE, ну может для экономии энергии добавили бы какой-нибудь low-speed Ethernet 1BASE-T со скоростью в 1Mbps - и USB сдох бы не родившись. Зато сейчас была бы огромная масса девайсов разнообразнейшего назначения с искаробочной сетевой прозрачностью. Дык вот, по теме данного треда - были бы копеечные Ethernet-serial конвертеры вместо всяких FTDI, CP2102 или CH340, а не здоровые агрегаты по 10 баксов за штучку с сомнительными прошивками. И куча всяких мелких Atmega/PIC/STM с Ethernet phy на борту просто по дефолту вместо USB. ТСу бы вообще в тему зашло. :)

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

А вот Ethernet как раз промышленный стандарт

ну насмешил - это чисто офисная шняга, всякие EtherCAT широко распространены только в википедии «Спецификация протокола EtherCAT доступна только членам организации»

Там считать-то нечего

Начнем с того что 8 байт данных в фрейме CAN в запросах и ответах при обмене с датчиком выше крыши. Стандартный фрейм с 8 байт данных - 111 бит, запрос-ответ 222 бита или ~28 байт. У изернета запрос-ответ 64 * 2 = 128 байт - это еще без повторов. У CAN при ошибке CRC прилетит коротенький error frame и аппаратный повтор - в изернете затраты времени на софтовый стек и по 64 байта в обе стороны минимум

100Mbps c потерями 50%

отсоёт у CAN по полной

Во-первых, на всём перечисленном прекрасно работает и mainline ядро

я как то не заметил - так и не смог заставить работать майстримный stmmac на алвинере с realtek а когда начал гуглить решение то обнаружилось что всякие бананы просто сделали новые ревизии плат с другим PHY

В-четвёртых, даже если бы они стоили не $5 а $50, то это неотличимая от нуля сумма если речь идёт о промышленных девайсах.

даа, ты как-то совсем далек от производства - на жалкой партии 10 тыс датчиков оверхед в 5 миллионов долларов

anonymous
()
Ответ на: комментарий от cvs-255

Уточни пожалуйста по микросхемам свичей. Вот скажем если я хочу несколько контроллеров на одгой плате держать, и у кажого свой интерфейс, насколько просто объединять их через микросхему свитча? Есть ли возможность подключать их к свичу без phy, а наружу из платы вывести 1 разъем?

Ну в принципе попадались чисто свитчи с фабрикой но без phy, просто много RMII, но это ИМХО редкость. Проще взять обычный свитч и контроллеры с phy и соединить RX/TX контрллеров и свитча напрямую, просто через кондёры, без всяких трансформаторов. Кстати развязку на кондёрах вполне можно использовать и для обычных подключений, если расстояния невелики и нет проблем с ЭМИ, если почему-то очень не хочется трансформатор ставить - вот, даже такой мастодонт как Texas Instruments такое советовал - http://www.ti.com/lit/an/snla088a/snla088a.pdf.

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от Stanson

Ну на выход то можно поставить разъем сразу с трансформатором. А вот между свичем и девайсами трансформатор не охота, место занимает

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от cvs-255

Ну для этого однозначно ставь конденсаторы. Как их номинал считать - читай в вышезапощенной AppNote.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Что до контроллеров, то насколько сложно использование всяких w5500? Контроллеры то я, если понадобится, хочу использовать массовые, младшие stm32 и avr, которые без ethernet

Я думаю собрать простую платку, в которую воткнуть имеющуюся у меня девборду stm32f103 и напаять atmega48, которых у меня много, для всякого не реалтайма типа управлять релюшками включения сож и включать шпиндель. А наружу ethernet пустить

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 3)
Ответ на: комментарий от anonymous

ну насмешил - это чисто офисная шняга,

Ну да, ну да. Автомобильный CAN - вот панацея и серебряная пуля да промышленности!

У CAN при ошибке CRC прилетит коротенький error frame и аппаратный повтор - в изернете затраты времени на софтовый стек и по 64 байта в обе стороны минимум

Только вот CAN полудуплексный, пока CAN- девайс отправляет error frame, ethernet успеет собрать данные с десятка датчиков и раз несколько повторить «пропавший» фрейм.

отсоёт у CAN по полной

Да чо там, у CAN всё отсосёт, CAN же самый великий и могучий интерфейс.

я как то не заметил - так и не смог заставить работать майстримный stmmac на алвинере с realtek а когда начал гуглить решение то обнаружилось что всякие бананы просто сделали новые ревизии плат с другим PHY

И конечно все вокруг бараны, но только не почитатель CAN который не посмотрел ревизию прежде чем пердолится.

Stanson ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.