cnc-club.ru

А что если добавить возможность подключения по SPI ? У одноплатных ПК ethernet порт - это зачастую единственный выход в сеть. Если воткнуть STM'ку в этот порт, то одноплатник сразу лишается интернетов и прочих сетевых прелестей. Я, к примеру, очень часто закидываю файлы УП по сети.

Для интернетов есть USB-Eth.

У SPI есть такой недостаток как длина линии связи. Тогда уж RS422.

Ясно, значит, пока не дёргаюсь (:

SPI на длинной линии, описание проблемы и решение.

sergx99 писал(а):SPI на длинной линии, описание проблемы и решение.

Т.ё. тот-же самый RS422, только пар проводов больше.
Напрашивается вопрос: а собственно сам SPI там зачем?..

UAVpilot писал(а):

sergx99 писал(а):SPI на длинной линии, описание проблемы и решение.

Т.ё. тот-же самый RS422, только пар проводов больше.
Напрашивается вопрос: а собственно сам SPI там зачем?..

Да проводов больше, два SPI со стороны мастера, но идет речь о кабеле 100м и скорости 10 Мбит/с.
Честный RS422, на этой длинне, только 1 Мбит / с гарантирует.

Простой SPI вообще ничего не гарантирует по длине и скорости - это всё зависит только от физического уровня который SPI не описывает. Например если его засунуть в оптоволокно, то это вообще будут гигабиты или десятки километров.
Если-же SPI запихнуть в "честный RS422" (что собственно в статье и предлагается), то скорости и дальность теоретически будет как у "честного RS422".

Кстати, про

sergx99 писал(а):речь о кабеле 100м и скорости 10 Мбит/с.

для SPI это невозможно физически. В смысле законы физики не позволят.

У меня когда встал вопрос о расширении кол-ва входов , осей и пр. То я выбрал такую схему: с ПК соединяется stm32f4 (или круче) по usb. Далее сеть can с опторазвязкой (iso1050) от пк. Результат более чем устраивает.

+ Аппаратная поддержка stm 32
+ Стремящаяся к нулю вероятность передачи неверных данных
+ Приоритетности передачи
+ Одну посылку видят все
+ Можно передавать децентрализованно
+ Цена

- пакет максимум 8 байт

Например у меня f4 двигает осями а датчик org "y " подключен через can к f1. Или
управление узлом рубки сделал так что ШИМ и входные сигналы по can а логика сидит на f4.

Ну, с ethernet'ами вопрос расширения решается довольно просто (: Я, буквально, вчера проверял.

До проверки скоростей ещё не дошёл, изучаю тонкости работы с ethernet в F4. Хочу убрать из функций приёма и отправки всё лишнее. Остановился на RAW пакетах, для меня это лучший вариант.

Хочу присоединиться к проекту. СТМ программировать умею, ЛЦНЦ видел, даже поставил на 3Д фрезер большой Пратт-Уитни.
Со стороны ЛСНЦ как раз проблемы - не понимаю протокола обмена, как настраивать и т.д.

Немного отвлёкся на другой проект (OrangePi + LinuxCNC). Но отвлёкся не зря. В перерывах было время подумать на тему, как использовать этот проект (STM32 + Ethernet) как можно продуктивнее.

В какой-то момент в голову ударила мысль, что эту платку можно смело заюзать не только как ногодрыг для LinuxCNC, но и как отдельный контроллер с веб мордой. Причём, морда управления будет лежать внутри самой STM'ки (или рядом на SPI флэшке 8/16/32 Мб). Для хранения файлов УП будет использоваться любая внешняя SD флэшка. Согласно этой задумке, решил взять за основу STM32F407VGT6 у которой на борту 1024 Кб программной памяти.

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

Ух и задумки ...
Если файлы УП на флешке - значит в контроллере планируется полноценный ЧПУ с планировщиком и тп?
А не за мало мощи у стм-ки для этого.
Может лучше все таки в таком случае разделить на два сопроцессора, реалтайм отдельно, а все остальное .... ну наверное на OrangePI:)
Веб морда реалтайму вряд ли мешать будет, потому как она больше стоять будет чем работать.

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

Самая большая проблема у них была в скорости работы с SD картой. Если G код был из очень мелких отрезков, контроллер тупо не успевал их читать и обрабатывать. Мне в этом плане нравится подход программы CNC USB Controller. Она перед стартом переваривает весь текстовый G код в удобный бинарный формат. Т.е. планирует всё заранее. Этот бинарный файл, состоящий из строгих команд контроллеру, читается и выполняется в разы быстрее. Поэтому во время работы проц не волнуется о планировании и занимается более полезными делами.

MX_Master писал(а):Этот бинарный формат потом читается в разы быстрее обычного текста. Поэтому во время работы проц уже не занимается этой ерундой.

Смотрел много разных решений, и это на мой взгляд самое интересное, да контроллер сам не парсит G-код, зато есть единый формат "кадров" которые передаются в контроллер либо по USB, либо по сети, либо с карты памяти, где в каждом кадре есть информация о том какие оси на каких скоростях, сколько должны выполнить импульсов, и какие доп-выходы какой должны генерировать сигнал (для шпинделя, лазера, тумана).
К похожему решению я постепенно и двигаюсь, генерация данных в бинарном формате в принципе уже у меня частично готова, а вот контроллер только в планах, и было-бы прикольно, если логика работы контроллера позволила добавить работу с бинарными данными.

selenur писал(а):Смотрел много разных решений, и это на мой взгляд самое интересное, да контроллер сам не парсит G-код, зато есть единый формат "кадров" которые передаются в контроллер либо по USB, либо по сети, либо с карты памяти, где в каждом кадре есть информация о том какие оси на каких скоростях, сколько должны выполнить импульсов, и какие доп-выходы какой должны генерировать сигнал (для шпинделя, лазера, тумана).

В моем случае надо проверить, какой вариант разбора G кода будет быстрее - STM'кой или средствами браузера. Давно хотел поверить возможности WebAssembly.

Продолжение темы - http://www.cnc-club.ru/forum/viewtopic.php?f=41&t=19713.

MX_Master писал(а):Давно хотел поверить возможности WebAssembly.

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

selenur писал(а):посмотрел как выглядит "линейный ассемблерный код байт-код"
Смесь Си и ассемблера в перемешку, выглядит конечно странновато....

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

Вот, кстати, и тесты - https://takahirox.github.io/WebAssembly-benchmark/
Видно, что именно на тяжёлых процессорных подсчётах WebAssembly намного быстрее.

MX_Master писал(а):Видно, что именно на тяжёлых процессорных подсчётах WebAssembly намного быстрее.

Вобщем в очередной раз изобрели велосипед...
В давние времена, ещё до существования Java самым кросплатформенным языком был Tcl/Tk - работал на любых платформах, коих тогда было сильно больше трёх.
Так-же его можно было встроить в браузер (сейчас это называют плагинами) и исполнять Tcl скрипты в браузере.
Потом появилась группа людей, которые решили создать мощный, удобный и "единственный" кросплатформенный язык - и появила Java. Нет, про Tcl они конечно-же знали, просто его лицензия не позволяла продавать свои лицензии на его использование...
Кстати, по размеру Runtime комплекта Tcl/Tk и по использованию им памяти ему до сих пор нет равных среди других решений при одинаковом функционале.

Сейчас практически любая новая мысль - это небольшая переработка старой идеи. Казалось бы, это плохо, велосипеды/повторение/блаблабла, но именно так идёт эволюция. Даже наш организм в цепочке ДНК несёт информацию, добытую эволюционно ещё черти сколько тысяч лет назад. Так что я не удивлюсь, если кто-то скоро подправит внешне Tcl/Tk, назовёт его иначе и разрекламирует это как новую прорывную технологию..

Это эволюция способов победы маркетологов над инженерами.
Java и iPhone - классические примеры тому. Например ещё в 1998 году у меня в кармане лежал "наладонник" со встроенным мобильником и лишь спустя почти 10 лет Джобс "изобрёл" iPhone...