Массив датчиков

[Gromov]

Сообщение от dp38

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

На fbd для контроллера 2010, вероятнее всего, не хватит скорости реакции, чтобы адекватно читать показания энкодера и оперативно срабатывать на датчики, либо система будет работать медленнее покрасочного манипулятора. В случае с 2010 такое можно на си провернуть "играючи" в плане производительности и запаса скорости. Но вот с кодом там придётся "попотеть".

[Arsie]

Сообщение от Gromov

На fbd для контроллера 2010, вероятнее всего, не хватит скорости реакции, чтобы адекватно читать показания энкодера и оперативно срабатывать на датчики, либо система будет работать медленнее покрасочного манипулятора. В случае с 2010 такое можно на си провернуть "играючи" в плане производительности и запаса скорости. Но вот с кодом там придётся "попотеть".

Дима, ты ещё задачу-то не знаешь, как и я, а уже вердикт выносишь.

Особенно сравнение с манипулятором, скорости работы которого мы тупо не знаем.

[Gromov]

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

[Arsie]

Сообщение от dp38

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

Мозги на изнанку, насколько я могу судить, от недостаточности входных данных.

Я уже вижу проблемы планирования, а ведь задача ещё и решаться-то не началась. "Дано" бы выяснить толком.

Надеюсь, вы понимаете, насколько далеко мы с вами вышли за рамки технической поддержки?

[Arsie]

Сообщение от Gromov

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

А вот я пока ничего страшного не вижу.

[dp38]

Сообщение от Arsie

Нужны конкретные ответы, без всяких "по моему" и так далее.

Вы думаете одно, программист манипулятора - другое. В итоге - нерабочая система.

Количество шагов тоже важно, как же двумерную матрицу составлять, не зная одного из измерений?

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

Исходим из того, что шаг будет равен расстоянию между датчиками.

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

[Arsie]

Сообщение от dp38

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

А я вот программировал манипуляторы и знаю, что робот нихрена сам не сделает.

Нужны координаты и сигналы на включение/выключение распылителя - это если робот по линейной схеме.

Либо блоки координат объектов, если робот умный и умеет трассировать карту, самостоятельно выстраивая трассы.

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

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

[Gromov]

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

[dp38]

Сообщение от Arsie

Мозги на изнанку, насколько я могу судить, от недостаточности входных данных.

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

Сообщение от Arsie

Я уже вижу проблемы планирования, а ведь задача ещё и решаться-то не началась. "Дано" бы выяснить толком.

Да, задача из разряда "сделай то..", но ведь и я не обращаюсь к Вам за готовым решением на блюдечке.

Сообщение от Arsie

Надеюсь, вы понимаете, насколько далеко мы с вами вышли за рамки технической поддержки?

Поддержка, скорее, Моральная. Пока только одни вопросы и назидания.

[Arsie]

Сообщение от dp38

Да, задача из разряда "сделай то..", но ведь и я не обращаюсь к Вам за готовым решением на блюдечке.

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

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

[dp38]

Сообщение от Arsie

А я вот программировал манипуляторы и знаю, что робот нихрена сам не сделает.

Нужны координаты и сигналы на включение/выключение распылителя - это если робот по линейной схеме.

Либо блоки координат объектов, если робот умный и умеет трассировать карту, самостоятельно выстраивая трассы.

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

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

Я ж говорю: всё, что касается манипулятора, меня не касается (это не мой каприз). От меня нужны координаты точек.

Система координат будет синхронизирована с системой робота (в этом тоже уверил программист робота)

Какое значение имеет суточная нагрузка, если известен цикл в 12 поддонов? Единственный момент - это начало и завершение работы. Но это другой вопрос. Сейчас мне нужно "научиться" распознавать детали и сохранять информацию.
Ну и процесс наладки никто не отменял. Само собой, что это не "сел, и поехал". Всему своё время.

[Arsie]

Сообщение от dp38

Я ж говорю: всё, что касается манипулятора, меня не касается (это не мой каприз). От меня нужны координаты точек.

Система координат будет синхронизирована с системой робота (в этом тоже уверил программист робота)

Какое значение имеет суточная нагрузка, если известен цикл в 12 поддонов? Единственный момент - это начало и завершение работы. Но это другой вопрос. Сейчас мне нужно "научиться" распознавать детали и сохранять информацию.
Ну и процесс наладки никто не отменял. Само собой, что это не "сел, и поехал". Всему своё время.

Ок. Что перемещает штангу с датчиками?

[Gromov]

Сообщение от dp38

Какое значение имеет суточная нагрузка, если известен цикл в 12 поддонов?

Ресурс энергонезависимой памяти - вот что важно. Вы же не хотите каждый месяц ставить новый контроллер?

[dp38]

Сообщение от Arsie

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

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

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

[Gromov]

Вам знакомо понятие о времени цикла (тике) системы в контроллерах smh2010(и не только в них)?

[dp38]

Сообщение от Gromov

Ресурс энергонезависимой памяти - вот что важно. Вы же не хотите каждый месяц ставить новый контроллер?

Так я об этом ещё в самом начале спрашивал: как всё это реализовать, не убив память контроллера? В процессе, пришёл к выводу, что нужно использовать Pixel с модулем памяти FRAM. Отсюда и главный вопрос: возможно это ТЕХНИЧЕСКИ реализовать на ваших контроллерах?

[Gromov]

Память контроллера здесь ни причём. Например, сигнал с энкодера с частотой 1кГц вы не сможете измерить контроллером "просто так". Либо код на си, либо специальные модули, но быстродействие всё равно ограничено.

Рассчитывайте, что время цикла системы 100мс. Будет быстрее - хорошо.

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

Я согласен с Арсением в том, что нет ничего невозможного, но я не могу ответить на ваш вопрос, так как вы по прежнему не даёте данные, что будет двигать датчики и какой сигнал будет с энкодера и прочих исполнительных механизмов/датчиков.

Память - она нужна только для хранения ЭНЕРГОНЕЗАВИСИМЫХ данных. В вашем случае - можно сохранять данные о последних 12 поддонах в конце каждого измерения. На случай, если сбой питания произойдёт - чтобы не возвращать конвейер на 12 шагов назад. (в зависимости от массы деталей - это может занять целый день). Здесь уже нужно знать поток. Если конвейер делает поддон за 10 секунд - это одно, если за 5 минут - совсем другое.

[dp38]

Сообщение от Arsie

Ок. Что перемещает штангу с датчиками?

Честно: не знаю.
Вся линия находится в другом городе, за тридевять земель. Информации минимум, что знал - рассказал. Программист робота - в Москве. Приедет на следующей неделе для "мозгового штурма". Каждый день пытает меня вопросом "Как успехи?" Успехи более, чем скромны, но Надежда умирает последней.
Уже пришлось купить Pixel, так как никакого эмулятора у SMLogix нет. С памятью пока не экспериментирую. Вместо датчиков - набор микропереключателей, роль энкодера выполняет кнопка "Esc" - вот такая "компиляция", а Вы говорите "исходных данных мало".

[dp38]

Сообщение от Gromov

Память контроллера здесь ни причём. Например, сигнал с энкодера с частотой 1кГц вы не сможете измерить контроллером "просто так". Либо код на си, либо специальные модули, но быстродействие всё равно ограничено.

Рассчитывайте, что время цикла системы 100мс. Будет быстрее - хорошо.

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

Я согласен с Арсением в том, что нет ничего невозможного, но я не могу ответить на ваш вопрос, так как вы по прежнему не даёте данные, что будет двигать датчики и какой сигнал будет с энкодера и прочих исполнительных механизмов/датчиков.

Память - она нужна только для хранения ЭНЕРГОНЕЗАВИСИМЫХ данных. В вашем случае - можно сохранять данные о последних 12 поддонах в конце каждого измерения. На случай, если сбой питания произойдёт - чтобы не возвращать конвейер на 12 шагов назад. (в зависимости от массы деталей - это может занять целый день). Здесь уже нужно знать поток. Если конвейер делает поддон за 10 секунд - это одно, если за 5 минут - совсем другое.

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

Про скорость потока могу только догадываться, но одно знаю точно: робот красит не очень быстро. А координаты точек ему нужны именно для того, чтобы отдельно прокрашивать торцы деталей. То есть, каждую деталь он ещё дополнительно будет обходить по периметру. Если учесть, что размер поддона примерно 5х1м, то за это время можно хоть три раза просканировать поддон.

[dp38]

К вопросу о памяти: где же тогда хранить данные? Вероятно, у меня неправильное представление о принципе работы памяти, но я не понимаю, куда "складывать" информацию о четырёх точках десяти деталей двенадцати поддонов.

[Gromov]

Сообщение от dp38

К вопросу о памяти: где же тогда хранить данные о 12-ти поддонах?

В eeprom, для этого специальные блоки есть. Только записывать данные туда надо разумно.

[Arsie]

Сообщение от dp38

Честно: не знаю.
Вся линия находится в другом городе, за тридевять земель. Информации минимум, что знал - рассказал. Программист робота - в Москве. Приедет на следующей неделе для "мозгового штурма". Каждый день пытает меня вопросом "Как успехи?" Успехи более, чем скромны, но Надежда умирает последней.
Уже пришлось купить Pixel, так как никакого эмулятора у SMLogix нет. С памятью пока не экспериментирую. Вместо датчиков - набор микропереключателей, роль энкодера выполняет кнопка "Esc" - вот такая "компиляция", а Вы говорите "исходных данных мало".

Поздравляю, у вас всё на руках, чтобы "завалить" ваше дело))

Т.к. вы не знаете количества деталей на поддоне, вам придётся хранить весь массив данных о поддоне, итого 12 массивов. На этапе запроса разбирать эти данные и отдавать роботу.

Было бы известно заранее - вы бы сразу разбивали массив на детали и хранили только данные о деталях.

Был бы известен режим работы конвейера, можно было бы подобрать правильный контроллер.

Была бы известна степень равномерности работы конвейера, можно было бы вообще обойтись без использования энергонезависимой памяти. Циклические алгоритмы постоянного шага на ФБД создаются "как два пальца об асфальт".

И так очень и очень много таких "было бы".

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

На схеме два датчика, но вроде понятно, как расширить до 10 и более. Шагов на полный скан может быть до 255. На выходе получаете массив данных о поддоне.

[Arsie]

Сообщение от Gromov

В eeprom, для этого специальные блоки есть. Только записывать данные туда надо разумно.

Вообще пока не вижу смысла что-либо писать в ЕЕПРОМ.

[dp38]

Сообщение от Gromov

В eeprom, для этого специальные блоки есть. Только записывать данные туда надо разумно.

Спасибо. У меня уже есть один SMH с убитой памятью, поэтому испытываю некоторый страх (по неграмотности своей) к этим блокам. Вот и уповаю на внешнюю память. Полагаете, в модуле FRAM нет необходимости?

[Arsie]

Сообщение от dp38

Спасибо. У меня уже есть один SMH с убитой памятью, поэтому испытываю некоторый страх (по неграмотности своей) к этим блокам. Вот и уповаю на внешнюю память. Полагаете, в модуле FRAM нет необходимости?

Есть и SMH2010 с этой памятью. Пиксель в вашем случае не лучший выбор. Память на SMH2010 можно заменить, кстати, так что контроллер ещё не труп))

[dp38]

Сообщение от Arsie

Поздравляю, у вас всё на руках, чтобы "завалить" ваше дело))

Т.к. вы не знаете количества деталей на поддоне, вам придётся хранить весь массив данных о поддоне, итого 12 массивов. На этапе запроса разбирать эти данные и отдавать роботу.

Было бы известно заранее - вы бы сразу разбивали массив на детали и хранили только данные о деталях.

Был бы известен режим работы конвейера, можно было бы подобрать правильный контроллер.

Была бы известна степень равномерности работы конвейера, можно было бы вообще обойтись без использования энергонезависимой памяти. Циклические алгоритмы постоянного шага на ФБД создаются "как два пальца об асфальт".

И так очень и очень много таких "было бы".

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

На схеме два датчика, но вроде понятно, как расширить до 10 и более. Шагов на полный скан может быть до 255. На выходе получаете массив данных о поддоне.

Как говорил Мойдодыр: "Вот теперь тебя люблю я!"
Преогромнейшее Мерси! Всё-таки есть на свете Справедливость! Наконец-то свершился переход Количества в Качество!
И насчёт Добра и Зла тоже всё верно!
С пристрастием изучу Вашу посылочку! И ещё раз выражаю Искреннюю Признательность за участие и потраченное время. Ничего не проходит зря.

[Arsie]

Сообщение от dp38

Как говорил Мойдодыр: "Вот теперь тебя люблю я!"
Преогромнейшее Мерси! Всё-таки есть на свете Справедливость! Наконец-то свершился переход Количества в Качество!
И насчёт Добра и Зла тоже всё верно!
С пристрастием изучу Вашу посылочку! И ещё раз выражаю Искреннюю Признательность за участие и потраченное время. Ничего не проходит зря.

Погодите радоваться. Может и не пригодится))

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

[dp38]

Сообщение от Arsie

Есть и SMH2010 с этой памятью. Пиксель в вашем случае не лучший выбор. Память на SMH2010 можно заменить, кстати, так что контроллер ещё не труп))

Может быть и так, но в SMH я не запихну 20 датчиков+энкодер+сигналы "старт/стоп"+сигнал на запрос данных+ещё чего-нибудь (по ходу действия), а к Пикселю можно этого добра навешать, и ещё останется.
И ещё, оказалось, что SMH не понимает блок PRCD, которым я идентифицирую сработавшие датчики.

[Arsie]

Сообщение от dp38

Может быть и так, но в SMH я не запихну 20 датчиков+энкодер+сигналы "старт/стоп"+сигнал на запрос данных+ещё чего-нибудь (по ходу действия), а к Пикселю можно этого добра навешать, и ещё останется.
И ещё, оказалось, что SMH не понимает блок PRCD, которым я идентифицирую сработавшие датчики.

Надо было SMH2G(i) брать.

[dp38]

Сообщение от Arsie

Погодите радоваться. Может и не пригодится))

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

Пока, конечно, туго доходит, но попытаюсь разобраться.

Вот чего удалось добиться на данный момент: я ловлю фронты на входах, сравниваю с состоянием соседних входов (слева и справа), и определяю точку (левая верхняя, правая верхняя, и т.д.) Привязываю к номеру строки (Y) порядковый номер датчика(X), и получаю координаты точки в формате YYYXX. Рассовываю по четырём блокам памяти (по количеству углов). На этом пока всё. Ещё нужно будет определять наличие второй (третьей) детали в каждой строке, и проделывать с ней такую же процедуру. Затем, дифференцировать детали и к каждой привязывать свои координаты. Потом всё это куда-то складывать на хранение.

Сообщение от Arsie

Надо было SMH2G(i) брать.

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

На сегодня вынужден откланяться - рабочий день закончился)
Смею надеяться на дальнейшее "сотрудничество")
Доброго Вечера.