cnc-club.ru

Схему срисовать не смог - придется все выпаивать. Не стал рисковать. Линейка нужна в работе.

Если еще раз разберу - проверю, как светятся.

Последовательно с подстроечником на 1 кОм стоял резистор на 510 Ом. Подстроечник был выключен на минимум (0 Ом).
Заменил 510 Ом на 240 Ом. Стало значительно лучше. Поставил 160 Ом. Стало еще лучше (заполнение около 30%). Дальше уменьшать боюсь.
Сейчас линейка работает стабильно. Этого достаточно для беспроблемного использования. Если не сгорит - хорошо.
Все же закажу еще одну для запаса.

А почему на линейке 4 светодиода + 1 для метки?
Почему 4, а не 2?

Так вот я думаю - все ли 4 фотодиода у меня используются, если выход только A B?
Может быть 2 из них для красоты стоят?
Или все же сигнал одного вычитается из второго?

michael-yurov писал(а):все ли 4 датчика у меня используются, если выход только A B?

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

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

в этом случае - маловероятно, для этого интерполятор нужен, не думаю что у китайцев полно дешевых ИС интерполяторов.

michael-yurov писал(а):все ли 4 датчика у меня используются, если выход только A B?

сложно сказать что там у нее внутри, обычно фотодиоды включаются встречно и дают "двухполярный" синус, который уже пот ом интерполируется 1х...nх

Обычно шаг растра не больше двух соток, соответственно учитывая 2-битный код Грея разрешение линейки - 5мкм. Если больше - тогда наверняка стоит интерполятор.
Ну а по диодам здесь китайцы сэкономили. Обычно 6 штук. Попарно-встречно. Тогда это позволяет откинуть постоянную составляющую. 4 основных диода стоят на растровых окнах. У Z-канала один на растровом, второй на прозрачном.

Как китайцы завернули здесь - сказать сложно...

И это, я не понял, там на фотодиодах грязь какая-то белая, или бликуют они так?

Это их спины, они на стекло через отверстия в плате смотрят

michael-yurov писал(а):Этого достаточно для беспроблемного использования. Если не сгорит - хорошо.

Вряд ли сгорит, это выходы операционников или опора компараторов...

После перехода на OpenPNP значительно упала скорость работы.
В основном из за пауз между движениями:
https://youtu.be/QfS9wJodjvw

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

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

https://youtu.be/PqzqK8iLBqc

Вот поэтому я и подумываю о собственной программе...
ЗЫ: и еще когда он несет компонент к нижней камере, то мог бы сразу и поднимать по Z пока едет к ней. Ну и опускать тоже по дороге от камеры к месту посадки.

Написание собственной управляющей программы - дело не быстрое... Может, проще подправить генератор траектории в OpenPnP?
Убрать паузы, например, добавить перемещение по Z при переносе элемента к месту установки.
Хотя последнее может быть чревато зацеплением за уже установленные высокие элементы и проч. выступающие вверх части конструкции.
По-крайней мере, ускорить движение наверняка можно, если конструкция не развалится.

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

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

Возможно, Джон инсправит проблему, если о ней сообщить.

Т.е., если это не паузы, а время на посылку-прием-обработку квитка, то получается, что такие задержки - это проблема медленной работы Java интерпретатора?
А почему в траектории одновременное перемещение только по XY, а Z (и поворот? не разглядел) после прихода в координаты установки? Можно перемещаться одновременно по XYZA? А в в координате установки останется только немного по Z.

Жесть конечно длительность задержек..... По идее если этот косяк поправить, то скорость работы станет пулемётной?

bolek4321 писал(а):Т.е., если это не паузы, а время на посылку-прием-обработку квитка,

Я такого не говорил.
Я не знаю, из за чего происходят задержки.

bolek4321 писал(а):то получается, что такие задержки - это проблема медленной работы Java интерпретатора?

Скорее всего - нет.
Раскладчиком управляет компьютер с топовой конфигурацией из доступных для бытового использования.

Полагаю, задержки происходят из за неправильно настроенного мной обмена текстовыми командами.
Программа предполагает получение текстового подтверждения после каждого действия, вроде слова «ok».
Но я не смог настроить TinyG так, чтобы он отправлял подтверждение сразу после каждого перемещения.
Сейчас настроено так, что после каждой команды перемещения контроллеру отправляется запрос его статуса. И когда текст ответа соответствует состоянию выполнения всех команд и ожиданию следующей - OpenPNP понимает, что можно отправлять следующую команду.
Как настроить правильно / лучше - я не знаю.

bolek4321 писал(а):А почему в траектории одновременное перемещение только по XY, а Z (и поворот? не разглядел) после прихода в координаты установки?

Потому что высота безопасных перемещений фиксирована.

Раздражает не это, а, например, то, что когда я отправляю голову станка посмотреть камерой на питатель, или элемент на плате - OpenPNP не только по XY перемещается в нужные координаты, но и по Z, и в итоге втыкается соплом в питатель или плату (при чем не в то место, куда смотрит, а в то место, которое находится в данный момент под соплом).

bolek4321 писал(а):Можно перемещаться одновременно по XYZA?

Кто же запрещает то? Разве что высокие детали тогда легко "снести" и сопло согнуть.

selenur писал(а):Жесть конечно длительность задержек..... По идее если этот косяк поправить, то скорость работы станет пулемётной?

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

michael-yurov писал(а):Раздражает не это, а, например, то, что когда я отправляю голову станка посмотреть камерой на питатель, или элемент на плате - OpenPNP не только по XY перемещается в нужные координаты, но и по Z, и в итоге втыкается соплом в питатель или плату (при чем не в то место, куда смотрит, а в то место, которое находится в данный момент под соплом).

В новой версии Джейсон доработал этот момент. Я сейчас исправил настройки, проверил - помогло.
Эта проблема с тыканием соплом многих давно раздражала.

Залил GRBL в ардуину, повесил светодиоды на выходы STEP по трем осям.
Проверил работу с помощью Grbl Controller (скорость 115200) - пауз между выполнением команд не заметил: в самом деле, получить квиток от GRBL на такой скорости обмена - глазом не успеешь моргнуть.
Скачал свежую версию OpenPnP - хотел посмотреть, заметны ли паузы. Не вышло - задания то нету... Может, кто сбросит JOB для попробовать?