Сообщений в теме: 51

[tecnocat]

Отправлено Вчера, 17:28 preps сказал(а) 29 Июл 2015 - 14:55: интересно как увязать всю эту хренотень с валидатором... Во всяческих "КИВИ-терминалах" самый обычный писюк как-то с ним увязан. Полагаю, на этот вопрос имеются давно уже готовые (причем даже сертифицированные) решения.

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

[T-Rex]

Arduino GRBL

Кстати, да (к стыду своему, о нем-то я и  позабыл). Топикстартеру стоит присмотреться: GRBL позволит управлять приводами на обычных шаговых движках (то есть изрядно сэкономить на покупке сервоприводов), и при этом избавит писюк от реалтаймовых задач, связанных с генерацией импульсов Step/Dir. "Люто, бешено плюсую".

 

Mach3 - "фтопку". Ничего не имею против этого (весьма достойного) софта, но в данном случае он совершенно не к месту.

Сообщение отредактировал T-Rex: 30 Июль 2015 - 13:37

[alexf]

при этом избавит писюк от реалтаймовых задач, связанных с генерацией импульсов Step/Dir.

Я тоже думал об использовании стороннего контроллера типа arduino для генерации битов.

 

А разве это так сложно - посылать несколько тысяч импульсов в секунду даже для celeron/pentium?

[T-Rex]

А разве это так сложно

Это очень непросто, поскольку ни Windows, ни Linux не являются системами реального времени (впрочем, как и аппаратная платформа, на которой они крутятся - то есть "писюк", архитектура которого отродясь не была заточена на гарантированное время обработки прерываний).

В любом случае, не рекомендую собственноручно изобретать альтернативу известным "велосипедам" (программным генераторам импульсов), над которыми с переменной степенью успеха бьются разработчики Mach3 и LinuxCNC. 1000-рублевый Arduino Uno с прошитым GRBL будет простейшим решением. Управлять им вы сможете откуда угодно, чем угодно и с минимальной затратой вычислительных ресурсов, посылая команды в текстовом формате (обычный G-code) через COM-порт. В наличии будет "Step/Dir" для трех осей (можете привод конвейера координатным сделать, если вопрос с пробуксовкой решите ), плюс еще несколько дискретных сигналов (запуск шпинделя, подача СОЖ...), которые можно включать и выключать через соответствующие М-коды (тоже может куда-нибудь пригодиться - например, шторку в отсеке выдачи товара открывать).

[vv92]

Черт! Как просто можно организовать фрезерный бизнес. Клиент сунул купюру в манетоприемник, умный контроллер вколол нужную порцию гормона гениальности дизайнеру (если к нему суперклеем на полгода фрезеровщика присобачить-сростутся). А дальше все совсем просто.

Пошел искать инвесторов.

[preps]

Зачем такие сложности. Предлагаю исключить всех посредников из цепочки получения бабок :-)

Сразу печатать бабло, как это делают СШП :-)

 

Вот только за это есть статья :-)

[alexf]

Мужики, кажется я всё понял...

 

 

в то время как точность позиционирования требуется не выше, чем "плюс-минус лапоть".

 

Он должен обеспечивать безукоризненно надежную стыковку и работу даже при довольно значительных промахах (плюс-минус несколько миллиметров).

 

Тогда в сто первый раз повторю: в вашем задумываемом агрегате ТОЧНОСТИ В ИДЕОЛОГИЧЕСКИ НЕТ из -за размеров и хлипкости конструкции, особенно если вы решите делать чисто математически покоординатно от точки дома привязывая положение ячеек...

 

может сместиться от своего теоретического положения на миллиметр "влево, вправо и во все другие стороны"?

Вестимо, для вас и ваших ЧПУ, работающих с очень маленькими деталями, +/- несколько миллиметров - это огромная пропасть.

 

Насколько я понял, для моего решения с шд и ременной передачей оклонение не более 2 миллиметров - достижимая величина.

Просьба поправить, если не прав.

[3D-BiG]

Насколько я понял, для моего решения с шд и ременной передачей оклонение не более 2 миллиметров - достижимая величина.

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

Мной предложенный метод  позволит:

1. использовать более дешевые коллекторные двигатели даже по сравнению с шаговыми приводами, не говоря о серво.

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

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

4. проще в настройке и в обслуживании: т.к. нет системы абсолютных координат, а вся работа по флажкам, то допустим большой разброс по установке полок в рядах, при этом не надо перепрограммировать контроллер управления, а это и удешевляет и производство и ремонт, т.к. в полевых условиях при ремонте НЕ надо тонкой настройки...

Сообщение отредактировал 3D-BiG: 31 Июль 2015 - 13:03

[T-Rex]

Насколько я понял, для моего решения с шд и ременной передачей оклонение не более 2 миллиметров - достижимая величина.

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

 

после загрузки ожидаемым грузом в 15кг

Внушительный такой "Сникерс", не только с легким голодом бороться сможет...

 

Таки лимит грузоподъемности (отдельно для манипулятора, отдельно для стеллажа с ячейками) надо изначально определить. От него все остальное плясать будет, и изменение этих лимитов может привести к переработке проекта с нуля.

Сообщение отредактировал T-Rex: 31 Июль 2015 - 15:04

[alexf]

 

Таки лимит грузоподъемности (отдельно для манипулятора, отдельно для стеллажа с ячейками) надо изначально определить. От него все остальное плясать будет, и изменение этих лимитов может привести к переработке проекта с нуля.

Лимит и есть 15 кг - это если рука, массу которой я оцениваю в 5кг проедет по нескольким полкам и соберёт сразу несколько товаров, скажем, бутылки двухлитровые с газировкой

[T-Rex]

Лимит и есть 15 кг

Это лимит для руки-автопогрузчика. Деформацию товарного стеллажа тоже рассчитывать надо - там на несколько центнеров товара может лежать...

рука, массу которой я оцениваю в 5кг

Собственную массу руки-манипулятора - всего в 5 килограмм? Да вы, батенька, оптимист...

[3D-BiG]

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