Вышел NoRT CNC Control 0.4

По последнему пункту вспомнилось: «То, что инопланетяне до сих пор не вышли с нами на контакт, доказывает, что в космосе есть ДЕЙСТВИТЕЛЬНО РАЗУМНАЯ жизнь».

Что до контроллеров, то насколько сложно использование всяких w5500?

Это хардварные TCP/UDP сокеты. Говришь ему на какой IP и порт законнектится, и получаешь пару буферов - для отправки и для приёма. Остальное оно само всё разрулит. Там чуть ли не PPPoE даже есть. Достаточно просто всё и примеров куча в инете есть. Китайцы шлёпают модулёчки с ними занедорого (относительно, конечно, рублей 200, это в 2 раза дороже BluePill с STM32F103) поэтому информации и примеров для них на любой вкус. Ну а так - даташит почитай, там вполне всё расписано.

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

Вообще, если честно, я бы с ENC28J60 позабавлялся бы. Они прикольные и жрут меньше, и т.п. W5500 уже на какой-то готовый образ для докера, собранный непонятно кем и настроенный непонятно как похожи. :) Мне больше нравится когда я максимально контролирую поведение девайса.

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

да не вопрос- используй TCP с изернет для реалтайма :)

не посмотрел ревизию

ревизия тут при чем ? алвинеровское ядро работает с риелтеком - проблема в майнстримном ядре.

да не вопрос- используй TCP с изернет для реалтайма :)

Ну так linuxcnc и использует, например, причём очень давно. Проблем нету, в отличии от USB. Да и c CAN как-то не сложилось реалтайма.

Вообще, они конечно подороже can интерфейсов

Да, но это прям почти готовый сокет на блюдечке с голубой каёмочкой.

Если денег жалко - бери ENC28J60 - для него тоже полно всяких описаний и реализаций. И ног у него поменьше :)

Да он столько же стоит

Не пугай так. Я аж полез цены смотреть на али. ENC28J60 Почти в 2 раза дешевле - от 60 рублей, а W5500 от 100.

Ну на али да, есть за 60 рублей. С доставкой через 2 месяца

Ну на али да, есть за 60 рублей. С доставкой через 2 месяца

Так на али надо закупать не по одной микрухе за раз, а сразу много всего, у одного продавца который доставку комбинирует, и выбирать ePacket или Aliexpress Staтdard Shipping. Тогда и приедет быстро и цена доставки будет невелика относительно закупленного.

Блин, те, что за 1$ они в SSOP28. Плату под него несколько сложнее, чем под soic травить

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

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

:D

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

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

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

В жизни не встречал, но судя по описанию это про более длинные расстояния и менее частые сообщения, чем can. Ну и проще в настройке, но сложнее в реализации. Пока у вас только один ЧПУ, а не scada и аторматизированный конвейер или хим. производство can выгоднее.

Сам хоть смотрел эту статью?
https://img-fotki.yandex.ru/get/15522/79863787.12/0_d0d00_63881aae_orig.jpg
Там видно, что офисный ethernet там только для заливки программ, а управление конечными устройствами через Modbus/RTU. Как ты думаешь, почему?

как USB смог взлететь. Идеальным вариантом был бы Ethernet + PoE

USB создавался в 90-х. Тогда во-первых ethernet зачастую был по коаксиальному кабелю, во вторых, сетевые карточки были довольно громоздкими, а в-третьих все это было дорого

Там всё равно нет dma, потому это не идеальный вариант.

USB создавался в 90-х. Тогда во-первых ethernet зачастую был по коаксиальному кабелю, во вторых, сетевые карточки были довольно громоздкими, а в-третьих все это было дорого

USB и Ethernet по количеству нужных для реализации логических ячеек не сильно отличаются. Можно сравнить опенсорсные IP для FPGA. Для девайсов с коротким кабелем типа мышек и клавиатур трансформаторы и даже конденсаторы не нужны, а вилка RJ45 стоит дешевле папы USB.

Так что тут не в технических сложностях дело. :)

Чисто ради прикола и proof-of-concept делал когда-то Ethernet-мышь на PIC18F1320. Из обычной USB мыши выдрал контроллер и сунул туда свой bit-bang ethernet. Питание 5В по неиспользуемым парам (из USB порта:)), никаких трансформаторов и кондёров вообще, только TX., на компе - тупо socat из UDP в PTY, потом inputattach -bare /dev/ttyXX. Прекрасно работала.

Там всё равно нет dma, потому это не идеальный вариант.

В сымсле? Почти во всех USB periferals даже самых дешевейших контроллеров есть некое подобие DMA - USB периферия без участия процессора пишет-читает пакет из определённых областей памяти. Ничто не мешало (да и не мешает) так же и ethernet периферию для мелочёвки делать.

В то время, когда создавался usb, ethernet был громоздким

В то время, когда создавался usb, ethernet был громоздким

Так USB был настолько же громоздким. Я ж говорю - количество логических ячеек для реализаци USB и Ethernet примерно одинаково. Если делать USB на рассыпухе, как NE2000 какой-нибудь, то получится такая же громоздкая девайсина.

Там dma на уровне хоста, а не устройства.

Ну usb флешки уже давно есть и они и раньше были мелкими. А вот ethernet карточек размером с флешку я в начале 2000х не видел

Даже в простейшем PIC18F2550 есть это подобие DMA. Для каждого endpoint указываешь область памяти и оно туда само. Да даже в PIC16C745 оно было. Разумеется там USB device и никаких хостов.

А вот ethernet карточек размером с флешку я в начале 2000х не видел

Куча PCMCIA/PCCard/CF Ethernet карточек было. У меня для Psion S5 и HP iPAQ CF Ethernet карточка была как раз в начале 2000х. До сих пор где-то валяется.

Кстати, в usb надо реализовать либо только host либо только устройство, а в ethernet симметрично

Ну в любом случае устройство не может просто так читать произвольно всю память, как через pci. Чeго-то же не хватает в usb там, где используют thunderbolt, firewire и тд.

Да, в USB есть такая неприятность. И ещё USB device обязательно должен обслуживать control endpoint и выдавать необходимый минимум дескрипторов для работы, т.е. содержать некоторое немаленькое количество кода для этого, даже если это какой-ниубдь тупой датчик, или та же мышь.

Флешки уже тогда были размером с зажигалку

Ну ещё в середине 90-х были 10Mbps адаптеры которые втыкались в LPT. Размером меньше сигаретной пачки. Наверняка и USB появились по мере распространения USB. В USB-CDC ещё в 96 году про Ethernet было, если правильно помню, но микрософт поднасрал и использовал свой проприетарный USB RNDIS вместо стандартного USB-CDC. Вот этот USB RNDIS точно ещё до 2000-х появился, так что USB-LAN свистки должны были быть на рынке.

Все равно это гораздо крупнее, чем usb флешка.

Да не особо.

Вот первые флешки: https://commons.wikimedia.org/wiki/File:8mb_ibm_disk_on_key.jpg

Появились в 2000 году.

У меня есть такая, кстати, только под брендом Compaq и на 16Мб. Тоже M-Systems, как и IBMовские.

А вот достаточно распространённый, как оказалось, адаптер SMC2208USB/ETH на RTL8150 ( http://realtek.info/pdf/rtl8150.pdf в конце есть дата чертежа микрухи - 1997, а так - это v1.40 2002года )

ftp://ftp.wintel.fi/docs/SMC/SMC2208.pdf

Судя по копирайту и дате в properties PDF это 2001-2002 год

Так что никакого «гораздо крупнее».

Там видно, что офисный ethernet там только для заливки программ

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

Как ты думаешь, почему?

Потому, что коммерчески доступное оборудование (которое используют подрядчики) застряло на этих протоколах. Когда за дело берутся учёные, появляются, например, вот такие технологии:

White Rabbit is the name of a collaborative project [...] to develop a fully deterministic Ethernet-based network for general purpose data transfer and sub-nanosecond accuracy time transfer.

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

cvs-255, пока я спорил в cnc-club, я понял что стал полностью повторять твою идею, но с некоторыми нюансами, посмотри в ОП и далее в теме, может они тебе понравятся.
Предложение по увеличению скорости работы LinuxCNC #1

Кстати по поводу enc28j60. Он поддерживает 10baseT и не поддерживает auto-negotiation. И если я возьму свитч, воткну в один его порт enc28j60, а в другой ноут, и между свичем и ноутом будет 100baseT, а между свичем и девайсом 10baseT-halfduplex, как вообще пакеты, пойдут нормально?

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

Если бы я посылал в контроллер, например, интенсивность шагов на ближайшие 10 мс, например, то особого смысла в этом бы не было, т.к. в пределах такого небольшого интервала времени это не критично, ну а плавный разгон/торможение обеспечивал бы за счет изменения скорости на каждом таком участке. Но я то хочу иметь возможность послать команду на большое перемещение и отдыхать, а не бить на кусочки. И поэтому я должен заранее указать начальные и конечные скорости

Хочешь УП из команд на движение от 20 до 150 микрон?

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

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

В итоге куда проще по ресурсам расчитать участки с 3 скоростями - на концах и посередине, чем делать 100500 еще более мелких участков

Hint: если использовать Cortex M4 (stm32f303), то там есть SIMD-инструкция SMUAD, очень удобная для интерполирования скорости по полиномам 3-го порядка, т.е. как раз для jerk-limited. Считать надо будет в fixed-point.

Hint: если построить 4-мерную кривую Безье в пространстве-времени, причем разместить вторую и третью контрольные точки по оси времени на 1/3 от концов, то физический смысл пространственных координат этих точек будет начальной и конечной скоростью движения, а сама кривая будет описывать правильное движение с ограничением на скорость, ускорение и рывок. Алгоритмом де Кастельжо на Cortex M4 это можно интерполировать вплоть до >100 кГц по 6 осям одновременно.

Движение по такому алгоритму плавнее и точнее, чем при разбиении на три участка разгон-круиз-торможение. На этапе планирования траектории может потребоваться разбиение на 7 участков (начало разгона, разгон, конец разгона, круиз и т.д.), поскольку мы ограничиваем не только ускорение, но и рывок.

Я при разгоне и торможении двигаюсь с постоянным ускорением. Т.о. рывка (скачка скорости при разгоне) не происходит.

А рывки за счет изменения направления вычисляются (и может быть в дальнейшем будут сглаживаться) на компьютере, а не на микроконтроллере

Сейчас я при изменении направления ограничиваю скорость так, чтобы рывок 'вбок' не превысил указанного значения

Ну я проблем не замечал. Свитчи нормально детектят. Возможно по NLP.

И если я возьму свитч, воткну в один его порт enc28j60, а в другой ноут, и между свичем и ноутом будет 100baseT, а между свичем и девайсом 10baseT-halfduplex, как вообще пакеты, пойдут нормально?

нет конечно - в теории для этого устройства должны поддерживать flow control - отправлять pause frame когда не успевают принимать и соответственно тормозить при приёме таких фреймов

https://en.wikipedia.org/wiki/Ethernet_flow_control

на практике ethernet фреймы просто дропают а все потери обнаруживают и компенсируют протоколы верхнего уровня.

Кстати по поводу enc28j60. Он поддерживает 10baseT и не поддерживает auto-negotiation.

посмотри ksz8851snl - намного круче enc28j60, но потребляет больше и корпус не очень удобный для монтажа, правда реальная скорость всё равно ограничена SPI - больше 40 МГц он не прокачает.

Я пока думаю оставить связь через rs232, но использовать протокол с коррекцией ошибок, я пока выбрал rfc908 с некоторыми улучшениями. А потом сделать версию с enc28j60, и тем же rfc908 поверх ethernet

«Рывком» (англ. «jerk») называется первая производная ускорения по времени.

Постоянное ускорение не гарантирует отсутствия рывка. Смотрите: F=m*a, значит, в начале разгона была F=0, стало F=a/m. Но жесткость деталей не бесконечна. Пусть они подчиняются закону Гука F=k*d, где d - величина деформации вала мотора, передачи и т.п. Следовательно, d скачком меняется от 0 до a/km. Этот эффект отвечает за вибрацию в начале и конце разгона и торможения и понижает точность. Величина d легко может достигать нескольких сотых долей миллиметра.

Чтобы этого не было, используют плавное наращивание не только скорости, но и УСКОРЕНИЯ тоже, ограничивая по модулю j=da/dt.

Гуглить по «Jerk-limited trajectory planning».

Прикрутил я тут enc28j60. Вот только надо теперь заставить его работать. И что-то ищу готовую библиотеку для работы с сабжем и не нахожу подходящего. Все как-то очень привязано к конкретным платформам. В идеале хотелось бы, чтобы с одной стороны библиотеки суешь передаваемые данные, а с другой вылезает поток данных, которые надо пихать в SPI. И наоборот, берешь из spi данные, и пихаешь их в библиотеку, а тебе вылезают переданные данные.

Бери любую подходящую сишную библиотечку для любой платформы - ковырнуть надо будет только работу с SPI - это единственная платформозависимая вещь.

Пихать данные в SPI и обратно должна сама библиотечка для этого её и надо ковырнуть. Ну всякие ARP/DHCP и прочая - накой тебе надо с ними разбираться. Тебе надо только буферы с данными этой библиотечке отдавать-забирать.

А вообще минимальную библиотечку можно и самому за вечерок написать - там ничего сложного. За пару вечеров можно и с DHCP/ARP и пр.

Вообще, меня немного удивляет подход многих, кто пишет такие вещи. Вместо того, чтобы сделать независимую от платформы библиотеку, гвоздями прибивают к ардуине или тому, что используют. Это же тяжело потом использовать. И начинается потом «как портировать библиотеку для работы с X с платформы Y на платформу Z»

Из того, что видел - дергают регистры avr SPI прямо внутри кода драйвера enc28j60

Пихать данные в SPI и обратно должна сама библиотечка для этого её и надо ковырнуть

Нет. Ведь можно же при инициализации бибилиотеки передавать в нее что-то вида (это если без DMA, с DMA чуть сложнее)

char (*spi_rw_f)(char data), void (*spi_cs_f)(char enable)

Которые и будут дергать регистры SPI. Можно еще прерывания вида byte transmitted учитывать. А библиотека будет дергать эти функции. И все, библиотека полностью платформо-независима