Контроллер ЧПУ

[malvin]

, расскажи, какие результаты есть? Работает девайс?
У тебя была проблема с одинаковыми значениями маски порта

Код: Выделить всё

15.11.2009-21:07:19 write Out32(): port=888 Value=194
15.11.2009-21:07:19 write Out32(): port=890 Value=10
15.11.2009-21:07:19 read Inp32(): port=889
15.11.2009-21:07:19 write Out32(): port=888 Value=194
15.11.2009-21:07:19 write Out32(): port=890 Value=10

Удалось решить? Расскажи как, похоже не только у тебя такая проблема есть...

Пока в этом направлении не работал - завал, вот только освободися. А в чем дело, собственно? Я пока не пойму.

По схеме

X9 - COM-порт с возможностью питания от переходника компа - опционально.
11058200 - частота кварца. чтобы не было искажений в скорости МК и компа
BF1 - маленький динамик, будет подавать сигнал в случае обнаружения контроллером нештатной ситуации, а так же от программы управления
C1, C2 - емкости на кварце - по 20 пикофарад. можно 30.
С3 - одна из емкостей обвязки ног питания контроллера
J2 - выход оптореле, например, для освещения или управления другим внешним устройством, возможно, питанием всего станка - в зависимости от конфигурации.
J1, J3 - пока зарезервированы для будущего применения. Могут работать как датчики, например, АЦП или как выходы для управления внешними устройствами.
Limit1-5 - просто там будут стоять кнопки нормально разомкнутые.
XS1 - это разъем для подключения питания
к мосту можно подключить 5 моторов.
MOTOR-DIR, MOTOR-SHIM - для мостового включения мотора шпинделя, можно будет переконфигурировать для 6 оси.

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

[spike]

А в чем дело, собственно? Я пока не пойму

Ну у тебя работает мост от GIGAMESH`а?
Дим, а ATMEGA 64-16AI подойдет? или для нее прошивка другая будет?

[malvin]

А в чем дело, собственно? Я пока не пойму

Ну у тебя работает мост от GIGAMESH`а?
Дим, а ATMEGA 64-16AI подойдет? или для нее прошивка другая будет?

Пойдет. Они должны быть совместимы. Хотя не парься, бери и паяй. Я все равно скоро усходник выложу - можно будет компилить под любой проц, если на С можешь писать.

А ты задержки сделал чтобы можно было убирать из проги?

[celladon]

Сделал платку для двигателей с током до 1А. Можно использовать для небольших станочков , пенорезок... А также для отладки программ как контроллера, так и для компьютера. На плате предусмотрел два разъема LPT и COM. Сейчас управление сигналами step/dir через LPT. А через СОМ заливаю прошивку посредством бутлоадера (кстати очень удобно, не нужен программатор). Хотелось бы попробовать мост. Теоретически возможно сделать такое на этой схеме?

[spike]

А ты задержки сделал чтобы можно было убирать из проги?

Сделал.

GIGAMESH 2H v.2.2.9 DL BT.zip

(842.81 КБ) 788 скачиваний

Если прога находит в библиотеке процедуру

Код: Выделить всё

procedure PulseTimes(PulseTime, TimeOut: integer); stdcall; external 'inpout32.dll';

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

Код: Выделить всё

PulseTime        - временные характеристики импульса
Out32              - первая половина маски импульса (PortAddr=BaseAddr) 
Out32              - вторая половина маски импульса (PortAddr=BaseAddr+2)
Inp32               - читает состояния (PortAddr=BaseAddr+1)
Out32              - первая половина маски исходного состояния(PortAddr=BaseAddr)
Out32              - вторая половина маски исходного состояния(PortAddr=BaseAddr+2)
Inp32               - читает состояния (PortAddr=BaseAddr+1)

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

Код: Выделить всё

unsigned int __stdcall CncCmd(char *uType, unsigned long int Val1, unsigned long int Val2)

- возвращает процент заполнения буффера, управляющая программа должна поддерживать заполненность в диапазоне (25-75%)
- uType - тип выполняемой команды:
'Step' - выполняет шаг по 32-битной маске Val1 (DSDSDSDSDSDSDSDSDSDSDSDSDSDSDSDS), D - направление, S - шаг (S=1 - выполняется шаг, S=0 - шага нет), индексация приводов: 1-й привод соответствует младшим битам, 16-й привод старшим; Val2 - период выполнения шага в микросекундах
'Control'- выполняет включение/отключение по маске Val1, 1 - включено, 0 - отключено, индексация устройств: 1-е устройство соответствует младшему биту, 32-е - старшему; Val2 - время паузы после выполнения команды включения в микросекундах
Делаем библиотеку lptbridge.dll, при загрузке программа ищет ее, если находит - пытается загрузить функцию CNCCmd. Если успешно - работаем дальше с ними, если нет - загружаем inpout32.dll, работаем с ней. При этом, если в библиотеке inpout32.dll есть процедура PulseTimes (считаем что библиотека -подменная) - в нее шлется время периода и таймаута.
Соглашение о вызовах:

Код: Выделить всё

procedure Out32(PortAddress: smallint; Value: smallint);stdcall; external 'inpout32.dll';
function Inp32(PortAddress: smallint): smallint; stdcall; external 'inpout32.dll';
procedure PulseTimes(PulseTime, TimeOut: integer); stdcall; external 'inpout32.dll';

только без контроля заполненности буффера, т.е. пусть он возвращается (ну так, навсяк случай), но управление заполненностью буффера пусть осуществляется усыплением потока самим мостом. Будем так делать?

А через СОМ заливаю прошивку посредством бутлоадера (кстати очень удобно, не нужен программатор).

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

[celladon]

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

Это разъем SV2, а не джампер. Он нужен для внутрисхемного программирования программатором. Покрайней мере один раз нужен для прошивки бутлоадера. Бутлоадер занимает 1к кода процессора. Распологается в конце памяти. Запускается при включении контроллера и запущенной программе на компьютере, находящейся в ожидании. Если интересно, бутлоадер и программа в приложении. Прошивка для Меги16 и кварц 16Мгц готова, если нужен другой проц и кварц, то нужно менять.

[celladon]

Собрал контроллер на макетной плате. Захотел попробовать как работает мост. Не понял на какой СОМ порт нужно вешать. Нужно гдето устанавливать номер порта .У меня USB переходник. Работать будет?. Пробовал монитором что шлется в СОМ порт. Ничего не обноружил. Пробовал с КСАМ

[spike]

Пропал наш соратник malvin, на связь уже как два месяца не выходит.... )ac( будем надеяться что вернется. Жалко исходник не оставил, а то можт кто подхватил бы знамя.

[spike]

Товарищ Horeen в продолжение темы писал:

Ню так мож продолжим "мучения"?

Допустим, есть железяка с интерфейсом RS-232, с встроенной машиной линейной интерполяции на четыре оси.

Потому как контроллер Horeen`а немного совсем другой, я отделил сообщение в новую тему: hCNC - Контроллер ЧПУ.

[koolhatcker]

Всем привет. Как успехи?

[spike]

koolhatcker, рад видеть у нас )ab(

malvin пропал, проект в замороженном состоянии. Поддержка в GIGAMESH работает, так что дело за реализацией LPTBridge.

[koolhatcker]

рад видеть у нас )ab(

Засчитано. )ag(
Да тут такое дело...
Есть мысль приспособить некоторые части автономника под какой-нить софт для ПК.
Начал искать кто из известного софта выдаёт данные в ком-порт (и чтобы протокол доступен был) )ab( .
Не нашёл. )ac(
Можно конечно тупо прикрутить к терминалке и слать файл через неё, но возникает неудобство при использовании: не видны например текущие настройки(та же глубина сверления и т.д.).
А вот если бы был софт под винду, в котором и настройки видны и управлять удобно и протокол открыт(или хотя бы мне известен )ab( ), то мог бы и к нему попробовать всё это дело приаттачить... )ab(
Если же у вас наработки только по LPT, но осей не более 3-х, то можно и через LPT попробовать.
С интересом бы рассмотрел архив, в содержимом которого была бы вся необходимая инфа - общий замысел, структурка, характеристики, протокол и т.д. В общем чтобы можно было сформулировать ТЗ для электронной части. )ab(

[spike]

Селаю сегодня вечером описание небольшое для той инфы, что на мой взгляд необходима, а там поглядишь, достаточна ли...

[Horeen]

Насколько помню, затея именно этой темы вкратце заключалась в следующем:
Прога знать не знала, что работает с COM-портом. Вместо штатной внешней библиотеки работы LPT-порта в винде подсовывалась самодельная (с тем же именем и теми же входными данными). Эта библиотека кэшировала параллельные данные якобы для LPT-порта в буфер, так же отслеживала временные интервалы прихода этих данный от проги. Потом отправляла данные в буфер МК в виде пачки данных, содержащих направление шага для каждой оси и время, через которое эти шаги должны выходить из МК. Т.е. интепроляции в МК не производилось, т.к. по сути, данные уже были "прямопотоковые" и отинтерполированные прогой на компе. Можно представить, что упрощенно это выглядит так - параллельный байт выводится не в LPT, а в последовательном виде (через последовательный же порт) передаётся в МК, который выводит полученный байт уже в параллельном виде на свой порт (с учётом тайминга).
Библиотека эта хорошо заменяла штатную и для KCam. В общем случае такой подход был хорош тем, что позволял не дорабатывать управляющее ПО, т.к. оно работало штатно, думая что отсылает данные в LPT-порт.
malvin, к слову, не совсем-то и пропал. Как сам сказал, пришёл к выводу, что это не совсем оптимальный подход (вобщем, не удивительно), и нужно делать своё управляющее ПО, чем вроде и начал заниматься, т.к. просить кого-то доработать своё уже готовое ПО под такой контроллер - не благодарная затея, из-за того, что неудобно работать в команде с разработчиком ПО дистанционно (ОС храмает, изменения в протокол вносить сложно, т.к. разработчик ПО часто занят чем-то другим, и приходится долго ждать изменений).

[Horeen]

кто из известного софта выдаёт данные в ком-порт (и чтобы протокол доступен был)

Тот же KCam. На оф.сайте есть и команды протокола и исходники той части KCama, которая отвечает за работу с внешним контроллером по COMу (для лучшего понимания сути процесса). Вроде всё хорошо, но запутанно как-то.. неспроста ещё никто так и не написал своей прошивки для работы с KCam по именно их протаколу.
Вобще, тема благодатная, и бесспорно заслуживает внимания (это не про KCam, а вообще).

[spike]

...
Прога знать не знала, что работает с COM-портом. Вместо штатной внешней библиотеки работы LPT-порта в винде подсовывалась самодельная (с тем же именем и теми же входными данными). Эта библиотека кэшировала параллельные данные якобы для LPT-порта в буфер, так же отслеживала временные интервалы прихода этих данный от проги. Потом отправляла данные в буфер МК в виде пачки данных, содержащих направление шага для каждой оси и время, через которое эти шаги должны выходить из МК. Т.е. интепроляции в МК не производилось, т.к. по сути, данные уже были "прямопотоковые" и отинтерполированные прогой на компе. Можно представить, что упрощенно это выглядит так - параллельный байт выводится не в LPT, а в последовательном виде (через последовательный же порт) передаётся в МК, который выводит полученный байт уже в параллельном виде на свой порт (с учётом тайминга).

Совершенно верно.
ПО, которое использует сторонние драйвера работы с портами по определению не знает что работает с каким-то конкретным портом. Все что ей нужно знать, это адрес, который она сообщает драйверу. Вот собственно на том что РС ПО не рулит конкретно портом, а рулит драйвером (в данном случае это inpout32.dll) и сделало возможным такой подход.

Библиотека эта хорошо заменяла штатную и для KCam. В общем случае такой подход был хорош тем, что позволял не дорабатывать управляющее ПО, т.к. оно работало штатно, думая что отсылает данные в LPT-порт.

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

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

А вот насчет неблагодарности затеи, особо по доработке ПО )bl(
Во-первых изначальная идея, как ты правильно сказал, была в том чтобы не дорабатывать ПО. Однако, после того как я не смог убедить malvina в том, что полученный потолок частоты весьма невелик, потому что не используется QueryPerfomanceCounter в dll-ке, мы решили внести изменения в ПО, что, кстати, и было сделано. Был добавлен вызов еще одной процедуры (PulseTimes - описание см. выше). Я не знаю на чем остановился malvin, сделал ли он обработку ее вызова или нет, но эта процедура тоже присутствует в вызовах GIGAMESH`а, если программа определяет наличие LPTBridge (собственно по наличию этой процедуры в библиотеке и определяет). О том что совместимость с другими программами полностью теряется было понятно всем и неоднократно было озвучено.

Наверное, malvin, действительно, понял что так делать не надо, потому что привязывается к моей разработке и решил соскочить с темы. Но разве так делается? ну написал бы что к чему, неужто я б не понял.

[Horeen]

Наверное, malvin, действительно, понял что так делать не надо, потому что привязывается к моей разработке

Скорее наоборот, т.к. он вообще отказался от совместимости и принялся писать свой софт, а не просто драйвер LPT. Ню, насколько мя понял, конечно..

изначальная идея, как ты правильно сказал, была в том чтобы не дорабатывать ПО

Так и хорошо, в общем случае, что отказались от этой идеи, т.к. в ней много минусов. Но, правда, был один существенный плюс - внешний МК автоматически "наследовал" все фичи и способности управляющего ПО, т.к. являлся по сути простым "повторителем" выводных данных. Та и прошивка простейшая, не требующая большого кода и сложной математики. Но дальше этого уже идуть сплошные минусы..
Лучше было бы решить вопрос написанием к имеющемуся ПО какого-либо плагина или модуля, позволяющего напрямую общаться проге с контроллером через COM-порт. Это кажется не универсально, но на самом деле универсальным должно быть не конкретное решение, а протокол. А там как бы вы уже не сделали - всегда найдутся умельцы написать прошивку для своего контроллера, который будет понимать, что от него хочет управляющее ПО. Отсутствие такого ПО с хорошо документированным протоколом и останавливает развитие любительских конструкций в этой сфере.

[spike]

Лучше было бы решить вопрос написанием к имеющемуся ПО какого-либо плагина или модуля, позволяющего напрямую общаться проге с контроллером через COM-порт

Проблем нет, об этом тоже говорили:

Код: Выделить всё

unsigned int __stdcall CncCmd(char *uType, unsigned long int Val1, unsigned long int Val2)

- возвращает процент заполнения буффера, управляющая программа должна поддерживать заполненность в диапазоне (25-75%)
- uType - тип выполняемой команды:
'Step' - выполняет шаг по 32-битной маске Val1 (DSDSDSDSDSDSDSDSDSDSDSDSDSDSDSDS), D - направление, S - шаг (S=1 - выполняется шаг, S=0 - шага нет), индексация приводов: 1-й привод соответствует младшим битам, 16-й привод старшим; Val2 - период выполнения шага в микросекундах
'Control'- выполняет включение/отключение по маске Val1, 1 - включено, 0 - отключено, индексация устройств: 1-е устройство соответствует младшему биту, 32-е - старшему; Val2 - время паузы после выполнения команды включения в микросекундах.

Нужно всего-то написать dll-ку с этой единственной функцией и задачей ее останется лишь пересылка контроллеру данных. Протокол простейший, документировать особо нечего... Расширять? - пожалуйста! Есть что улучшить - тоже велкам!
Это что касаемо передачи данных в контроллер, для передачи данных обратно нужна еще одна процедура, типа

Код: Выделить всё

unsigned int __stdcall CncState(char *uType) 

возвращает значение состояния или код (вот тут есть что обсудить)
- uType - запрос на вид получаемых данных

[Horeen]

Проблем нет, об этом тоже говорили

Как-раз таки, тут и есть проблема.
Первая в том, что как можно понять, сам ты не работал с COM-портом, поэтому и работали через dll-ку, написанную сторонним разработчиком. Сможешь ли ты сам освоить COM-порт и работу с ним? (приём и отправка данных)
Во вторых, предложенный протокол, гм.. действительно прост, и обсуждать там нечего. И мало того, его даже как бы и не хочется обсуждать... Большой, почти непрерывный поток данных с неслабой скоростью. Наличие большого буфера в оперативке МК для более-менее устойчивой работы и т.п. Это всё сплошные минусы и ограничения. Но может можно подумать и оптимизировать как-то... но протокол изначально не ахти какой (не смотря на предельную простоту).

[spike]

Первая в том, что как можно понять, сам ты не работал с COM-портом, поэтому и работали через dll-ку, написанную сторонним разработчиком. Сможешь ли ты сам освоить COM-порт и работу с ним? (приём и отправка данных).

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

Во вторых, предложенный протокол, гм.. действительно прост, и обсуждать там нечего. И мало того, его даже как бы и не хочется обсуждать... Большой, почти непрерывный поток данных с неслабой скоростью. Наличие большого буфера в оперативке МК для более-менее устойчивой работы и т.п. Это всё сплошные минусы и ограничения. Но может можно подумать и оптимизировать как-то... но протокол изначально не ахти какой (не смотря на предельную простоту).

Тоже хых. Есть у меня и другое, летом я разработал алгоритм своеобразного архивирования данных. Идея в том, что для кривых траекторий каждого привода во времени вычисляются коэффициенты полиномов - вот их-то можно и передавать. Но! Можно разровнять ровным слоем усилия по целой куче задач и не получить на выходе нихрена. А можно начать с простого и постепенно идти к сложному.