cnc-club.ru

alex1816 писал(а):Немножко не понял. Имеется в виду, что стек (который из куба слишком много кода имеет? или ??)

Да.

UAVpilot писал(а):Мне всё равно на каком языке писать.

AAN писал(а):Пытались мы нанять специалистов или контору, чтобы добавить нужные нам функции в ПО, написанное на Perl

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

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

UAVpilot писал(а): Вот вы лепите ссылки даже не вникая о чём они... Вопрос по Modbus был с подвохом - pymodbus в Микропитоне не будет правильно работать, ибо Микропитон заметно отличается от настоящего Питона.

Просто показываю реализуемость задачи средствами ЯП. Допилить, конечно, придётся.

UAVpilot писал(а): Только вот на PC этот модуль на скоростях выше 230400 bps на современном компе уже начинает терять байты, а порт-то умеет работать аж на 10Mbps...

аж на 10Mbps? В лабораторных условиях? Но мы, вроде как станки обсуждали, для которых и стандартно-максимальные 115200бод RS232го реализовать - проблема.

AAN писал(а):Весьма распространённая среди программистов профессиональная деформация - на одном вдохе произносится заявление об своей универсальности, перетекающее в сложность поставленной задачи поддержки кода и завершаемое гордым отказом от средств, облегчающих такую поддержку

И к чему этот набор бессмысленных слов? Средства, подобные Микропитон ничего не облегчают, а только усложняют сопровождение и добавляют ограничений, хотя-бы необходимостью таскать за собой этот самый Микропитон в полном объёме, даже если от него требуется только поморгать лампочкой.

AAN писал(а):Просто показываю реализуемость задачи средствами ЯП. Допилить, конечно, придётся.

Ну и зачем мне для реализации своего проекта допиливать ещё и какие-то другие проекты?..

AAN писал(а):аж на 10Mbps? В лабораторных условиях? Но мы, вроде как станки обсуждали, для которых и стандартно-максимальные 115200бод RS232го реализовать - проблема.

Лично я тут говорю не про станки, а про накладные расходы для всяких интерпретаторов и их влияние на быстродействие. И это именно вы завели речь про работу RS232 (PySerial), а я лишь сказал про его скоростные возможности, накладываемые интерпретатором Python.

P.S. В этой теме я закончил про Микропитон, желающие продолжить могут создать соотв. тему.

Коллеги, я бы тоже присоединился к этому проекту. Поясните, зачем вы хотите использовать Ethernet протокол. Есть ведь USB. Мне еще вот что думается, что лучше разделить интерпретатор g-code и генератор импульсов. Генератор импульсов сделать на отдельном МК. Получится контроллер на двух ядрах. На первом контроллере реализовать, обработку программы, хранение координат, обработку энкодеров обратной связи, функции ручного управления.

vadimxg писал(а):Коллеги, я бы тоже присоединился к этому проекту. Поясните, зачем вы хотите использовать Ethernet протокол. Есть ведь USB. Мне еще вот что думается, что лучше разделить интерпретатор g-code и генератор импульсов. Генератор импульсов сделать на отдельном МК. Получится контроллер на двух ядрах. На первом контроллере реализовать, обработку программы, хранение координат, обработку энкодеров обратной связи, функции ручного управления.

Вадим, интерпретатор g-code, как ни странно, есть в самом LinuxCNC, который будет работать на отдельной мат.плате или ARM платке. Поэтому для платы развязки достаточно одного МК, внутри которого будут генераторы, обработка энкодеров, конвертер и обычные входы/выходы.

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

vadimxg писал(а):Так вот я предлагаю выкинуть LCNC, как интерпретатор. Это решает и проблему интеграции между интерпретатором и генератором.

Я, возможно, так и сделаю, когда буду создавать собственный контроллер и софт. Но сейчас выбрасывать LinuxCNC - это непрактично. На его основе, можно собрать абсолютно любое ЧПУ. И я ещё не настолько умён, чтобы заменить его чем-то равноценным.

Если, нужен действительно отдельный контроллер на STM32 и софт, стоит обратить внимание на новую разработку Михаила Юрова - http://www.cnc-club.ru/forum/viewtopic. ... 73#p428162

vadimxg писал(а):Есть ведь USB

Лучше считать, что его нет. Помехозащищенность ethernet гораздо выше.

Я его пробовал, это не то, что хотелось бы.

Помехозащита реализуема и в USB, можно и CAN шину применить в решении. В моей архитектуре запас избыточности достаточно высок, чтобы передавать строки управляющей программы. На бытовом уровне у USB 2.0 преимущества перекрывают его недостатки, а есть ведь еще и usb 3.0. А если учесть, что вы планируете использовать UDP протокол то раз уж вы заговорили о зашумленной среде, то потеря пакетов гарантированная. Ethernet фреймы, которые не пройдут контроль честности будут отбракованы и сброшены.

vadimxg писал(а):Так вот я предлагаю выкинуть LCNC, как интерпретатор. Это решает и проблему интеграции между интерпретатором и генератором.

LCNC является продуктом длительного развития и отладки. Ничего сравнимого разработать силами одного-двух человек нельзя.
И кстати, собственно интерпретатор G-кода LCNC очень хорош, опять же что-то подобное сделать нереально.

Выкидывать хорошее, чтобы на его место всунуть кустарную поделку?

Есть еще идея ESP8266 как интерпретатор и STM32 как исполнитель. Обмен между ними по SPI.

vadimxg писал(а):Помехозащита реализуема и в USB

Сильно специальными средствами, стоимость которых совсем недемократична.
А у Ethernet изначально помехозащищённое кодирование, да ещё и гальваническая развязка.

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

Вы неправильно понимаете суть UDP протокола.

Притом что сбой в USB приводит в отвалу устройства, а сбой в Ethernet к потере пакета. Т.е. во втором случае проблема снимается правильным протоколом...
А CAN требует кучу лишней аппаратуры, так зачем?

MX_Master писал(а):В качестве проца должен полностью подойди STM32F407VET6.

Определился с железками?
Проверь сколько там входов энкодерных есть. думаю хватит, но лучше пересмотреть.

MX_Master писал(а):За физику Ethernet будет отвечать недорогая кроха LAN8720.

А сеть лучше сделать по совету UAVpilot на 5х00, разгрузишь процессор хорошо.

Если будешь свои платы делать можно заодно еще пару тригеров на них присобачить для хоминга по индексной метке - может пригодится.
как в этой теме к примеру: http://www.cnc-club.ru/forum/viewtopic. ... 0&start=40

alex1816 писал(а):Проверь сколько там входов энкодерных есть. думаю хватит, но лучше пересмотреть.

6

alex1816 писал(а):Если будешь свои платы делать можно заодно еще пару тригеров на них присобачить для хоминга по индексной метке - может пригодится.

Не надо триггеров, Z надо вешать на ногу с EXTI.

alex1816 писал(а):Определился с железками?
Проверь сколько там входов энкодерных есть. думаю хватит, но лучше пересмотреть.

Энкодерный вход - это один из режимов работы аппаратного таймера, где используются два его канала. Генератор STEP это тоже один из режимов работы аппаратного таймера. Поэтому кол-во энкодерных входов и генераторов STEP, грубо говоря, зависит от кол-ва этих таймеров (общих и продвинутых). У STM32F407VET6 имеется 12 аппаратных таймеров, которые подходят под это дело. Из них в режиме энкодера умеют работать 6 таймеров (как выше отметил Сергей). А в режиме STEP генератора умеют работать все 12. Так что, учитывая цены, выбор был не случайным. Единственное над чем я думаю - может взять такой же МК, но чтоб ножек было побольше. Например, STM32F407ZET6. Вдруг кто-то захочет целую панель из кучи отдельных кнопок подключить...

Что касается отдельной Ethernet микрухи.. у меня для тестов есть и W5500, и ENC28J60, и обычный физический LAN8720. Что покажет себя лучше, то и пойдёт в ход. Но начну я, всё-таки, с LAN8720.

MX_Master писал(а):Единственное над чем я думаю - может взять такой же МК, но чтоб ножек было побольше.

Лучше возьми с большей памятью.

MX_Master писал(а):Вдруг кто-то захочет целую панель из кучи отдельных кнопок подключить...

Поставишь ещё какой-нибудь f0 или f1 (прям в панель с кнопками)...

UAVpilot писал(а):Лучше возьми с большей памятью.

Тогда следующий, STM32F407ZGT6 (1 Mb). Но я, всё-таки, не планировал целый контроллер там размещать. Самое большое, что туда будет залито, это два Ethernet стэка - один для собственного загрузчика, другой для непосредственной работы устройства.

UAVpilot писал(а):Поставишь ещё какой-нибудь f0 или f1 (прям в панель с кнопками)...

Понял. И по какому-ньть SPI/UART связать.

28_60 гамно редкостное.

tooshka писал(а):28_60 гамно редкостное.

А не поделитесь ли своим опытом в области ENC28J60?

Много где читал, что лучше сразу на W5100 перейти, минуя ENC28J60. Даже не смотря на цены.