Рад резонансу )ab(
Хотя цель была другой, но лишний азарт в достижении цели ещё никому не помешал...
Архива так и не увидел и весь форум читать некогда, поэтому позволю себе ограничиться тем, что пробегусь по высказываниям сегодняшнего дня..
Прога знать не знала, что работает с COM-портом. Вместо штатной внешней библиотеки работы LPT-порта в винде подсовывалась самодельная (с тем же именем и теми же входными данными). Эта библиотека кэшировала параллельные данные якобы для LPT-порта в буфер, так же отслеживала временные интервалы прихода этих данный от проги. Потом отправляла данные в буфер МК в виде пачки данных, содержащих направление шага для каждой оси и время, через которое эти шаги должны выходить из МК. Т.е. интепроляции в МК не производилось, т.к. по сути, данные уже были "прямопотоковые" и отинтерполированные прогой на компе. Можно представить, что упрощенно это выглядит так - параллельный байт выводится не в LPT, а в последовательном виде (через последовательный же порт) передаётся в МК, который выводит полученный байт уже в параллельном виде на свой порт (с учётом тайминга).
Помимо того, что скорость упадает в 9 раз(при той же частоте вывода в порт), так ещё и передаётся избыточная инфа("время, через которое эти шаги должны выходить из МК"). Т.е. передали направление, а следом ещё 1-2 байта с инфой о скорости? Если я неправильно воспринял, то будьте добры не спешить и излагать ваши мысли так, чтобы они были поняты однозначнго всеми без исключения )ab( .
Тот же KCam. На оф.сайте есть и команды протокола и исходники той части KCama, которая отвечает за работу с внешним контроллером по COMу
Ссылочки будьте добры пожалуйста. Обе две. И на описание протокола и на исходники. Я не нашёл. И не только на их сайте, но и во всём интернете. Нашлись только цены на ту железку, что может транслировать данные от Kcam в S/D.
неспроста ещё никто так и не написал своей прошивки для работы с KCam по именно их протаколу.
Именно потому никто и не написал, что протокол закрыт. Сами посудите - список команд известен, времянки передаются, транслировать в S/D при таком раскладе сможет любой школьник старших классов. Тем не менее никто до сих пор не сделал. Включая китайцев.
Вобще, тема благодатная, и бесспорно заслуживает внимания (это не про KCam, а вообще).
Спору нет. Только вот есть одно "НО". Раз уж речь идёт не о универсальной железяке, а о связке комп+железо, то отсюда вытекают как минимум 2 следствия: 1)Софт должен быть как минимум не хуже того софта, к которому все привыкли и которым все пользуются. 2)Железо будет совместимо только с этим софтом.
Наверное, malvin, действительно, понял что так делать не надо, потому что привязывается к моей разработке и решил соскочить с темы.
Если так и есть, то зря имхо. Ведь есть много связок софт+железо и все они несовместимы. То есть производитель бьёт 2-х зайцев - Sale(Soft && Hard) )ab( .
И им невыгодно раскрывать свои протоколы чтобы например железо для их софта делали другие фирмы. Банально теряется монополия и падает цена. Поэтому тут всё просто - либо делать свою связку либо реверсинжинирить чужую(вместе со всеми недостатками реализации обмена и недостатками софта). А оно надо?
внешний МК автоматически "наследовал" все фичи и способности управляющего ПО, т.к. являлся по сути простым "повторителем" выводных данных.
Horeen, неужели вы не видите, что это не совсем правильно? Ведь при таком подходе узким местом быстродействия железа будет являться интерфейс связи его с ПК.
на самом деле универсальным должно быть не конкретное решение, а протокол. А там как бы вы уже не сделали - всегда найдутся умельцы написать прошивку для своего контроллера, который будет понимать, что от него хочет управляющее ПО. Отсутствие такого ПО с хорошо документированным протоколом и останавливает развитие любительских конструкций в этой сфере.
А вот тут поддерживаю. Мне например достаточно строки из файла по ком порту(до CR/LF). А уж что с ней делать - контроллер разберётся )ab( .
Это что касаемо передачи данных в контроллер, для передачи данных обратно нужна еще одна процедура, типа
Код: Выделить всё
unsigned int __stdcall CncState(char *uType)
возвращает значение состояния или код (вот тут есть что обсудить)
Вы отдаёте себе отчёт в том, насколько упадёт быстродействие(с учётом медленных интерфейсов), если гонять данные в обе стороны, а не в одну? Я о том, что допустим двигатель находится в стадии разгона и после КАЖДОГО шага контроллер передаёт значение состояния текущей скорости например )ab( .
Но может можно подумать и оптимизировать как-то... но протокол изначально не ахти какой (не смотря на предельную простоту).
Нафиг )ab( .
Шлём в ком порт строку Г-кода и курим... пока железяка не рапортует об успешном выполнении этой строки и готовности к выполнению следующей.
При начале работы (т.е. всего один раз на один файл g-кода):
- начальная скорость движения (в герцах)
- длинна участка разгона до максимальной скорости (в шагах)
ВАЩЕ не согласен с обоими пунктами. )ab(
Скорость нужна не начальная, а общая. Связывающая время перемещения из точки А в точку Б со временем, в течение которого это перемещение происходит. А начальная скорость всегда будет равна нулю )ab( .
Длина участка разгона(равно как и торможения) будет величиной переменной и напрямую связанной с расстоянием от точки А до точки Б. )ab(
При каждом кадре:
- координаты цели для каждой участвующей оси (в шагах)
- рассчитанный на компе тайминг выдачи импульсов для каждой участвующей оси (в мкс)
Координаты цели содержатся в кадре ПО ОПРЕДЕЛЕНИЮ.
Тайминг будет изменяться для каждого шага в процессе разгона(торможения). Предлагаете передавать ВСЮ таблицу таймингов для каждого разгона/торможения?
способен выдать огромную частоту (хватит хоть на 256кратное дробление шага при 100 оборотах в секунду).
При наличии обратной связи с ПК - тупо не успеет из-за низкой скорости интерфейса.
Уф. Вроде хватит для первого раза. )ab(
Прошу понять правильно - это всего лишь вопросы, которые возникли в ходе чтения сегодняшних сообщений.
