Просто ИМХО заголовок "Делаем" означает что это не первая поставка ) Ну и если вы только отправили первую партию - у вас пока прототип, ибо робот для произодства, без обкатки на этом самом производстве, это, извините, прототип и ничего более - до реального робота ему еще как до луны пешком.
Окей, что насчет сравнения с мировыми брэндами? В чем лучше? В чем хуже? В чем преимущества? Насколько сопоставима математика? Стоимость для примерно одинаковых по спекам устройств?
Тут ведь тех. ресурс, уж извините - джинсу тут не любят, для этого есть другие ресурсы типа VC и тд.
Реальное видео работы вашего манипулятора рядом с реальным станком можно посмотреть (туже загрузку болванки)? Того же M13? Ибо на сайте я вижу только 3D-рендеры и все.
На какиех предприятиях внедрено? Как в плане конкуренции с FANUC / ABB / Kuka?
Пока у меня впечатление, что у вас что-то возможно есть, возможно как-то связано с роботами, но по тому что я вижу - только на бумаге, либо 1 тестовый образец.
Приведите пример такой транзакции, чтобы понять точно о чем разговор.
Так как обычно данные описаны именно на уровне данных и бизнеса, и они просто протягиваются через слои, которые с ними работают. От языка там только названия, никакой доп. сложности ни инструменты, ни слои к данным не добавляют. К общей архитектуре - да, ибо каждый слой - это отдельный сервис.
Т.е. грубо говоря как у вас есть сейчас, и к чему вы хотите прийти на примере. После этого можно будет поговорить предметно.
Дело не в языке, а в сложности того, что им описывают, а язык вообще можно хоть какой использовать, если верно сложность понять - хоть на 1C писать, хоть на асме.
Зоопарк протоклов не от того, что там матрешка, а от того что данные, которые пытются формализовать очень сложные + ограничение каналов связи + ограничение клиентов - оттуда и вложенность и указание только нужных полей и тд.
Вы гуманитарий? - ибо очень похоже - им постоянно такие идеи приходят в голову, но они, к сожалению, не более чем от не понимания того, что происходит и как это работает.
Реально, по номеру телефона? )))))) Вобщем, очередной коммерческий и бесполезный пост из цикла "Я СДЕЛАЛЪ!" не проанализировав нормально рынок, т.к. бесплатного очень много и все работает, часть вообще в докер завернута, нужно только стянуть и запустить.
Из быстрого без головняка это AMMY (кторому пророчили смерть бесчетное количество раз) и ASPIA от нашего соотечественника (очень много именно нужных функций без мишуры и свистелок, малый размер файлов, есть linux/mac/win).
ASPIA вполне пригодна для энтерпрайза, исходники открыты, бесплатна и вообще без своих сервреров, для пробивки NATa в комлекте есть утилитка, разворачивающаяся в полпинка.
И я работаю и ни разу не было необходимости в переносе по словам. Ни у меня, ни у коллег по цеху. Все решается либо wordwrap-ом, либо стрелками.
Там, где нужно больше, нужно использовать IDE с предпросмотром того же MD, а не консольный инструмент, абсолютно не проходящий для данной задачи, насиловать.
А зачем нужно в техническом редакторе фича из полновесного текстового редактора?
Оно и висело 9 лет, потому что технарям оно не нужно от слова "совсем". А остальные не в курсе про FAR :)
Фича это еще и производительность жрет, так как и навигация и выделение становится не тривальной задачей, а редакором FAR можно открывать многомегабайтные файлы - он должен быть прост, как валенок и быстр настолько, насколько он может быть.
Давайте туда еще карту навигации засунем, висящие переносы и ударения :)
Как раз переносы по словам в JSON - это будет дикая боль, говорю как бэкэндер, который JSON-портянки каждый день смотрит. Редактор в FAR - это быстро пробежаться по JSON, причем обычно с word-wrap и вообще без скроллинга, а если надо изучать - открывать надо в соответствующем редакторе, с возможностью скрывать узлы и тд - текстовый редактор вообще не для этого.
Логи точно также отлично смотрятся с word-wrap, а также с помощью ctrl+стрелочки во вьювере, которые сразу скроллируют куда нужно.
Вобщем, каждому инструменту свое, не надо из любого редактора текста пытаться сделать IDE.
А вот что реально не хватает - это форматтеров, как раз того самого, минимизированного до одной строки JSON, у меня для этого бьютификатор прикручен через LUA, а вот нативный был-бы удобнее.
Во-первых рок - очень плохой выбор для неокрепшего ума, поскольку очень эмоционально заряжен, и смысл содержит в словах и образах, а то и вообще скрытый и его необходимо понять. В языках подобная конструкция называется матом. Вобщем, для ребенка очень не очень.
Во-вторых зачем тут MP3? MicroFAT и WAV-out через PWM за глаза - композиций-то чуть-чуть, SD меньше 8 гигов уже и не достать, кратко - ATMEGA/ATTINY + SD + усилок (возможно даже и без него, если негромко и динамик правильный). Алго - композиция доиграла или книжку закрыли - упали в глубокий сон. Для минимизации размера я бы вообще ATTINY85 взял, но там есть проблема с количеством ножек и определением страницы, в вашем случае 1 ножки в режиме ADC + нескольких сопротивлений хватило бы за глаза.
А кто-то может сказать кратко, как сейчас обстоят дела с LTO7/8? Потому что нормальный интерфейсы начинаются только с этих версий, а мучаться с FC (LTO5/6) никакого желания нет вообще.
Когда я смотрел пару лет назад, стоимость одного привода болталась где-то около 2000$, какие-то подвижки появились в плане цены? И еще сразу - если брать БУ, то где лучше? EBAY?
Кастомизировать можно через переменные/классы и это будет праильно, нативно и без костылей. Человек выше все праавильно написал.
И чтобы не быдь голословным и чтобы отстали от человека выше:) вот тотже шейп, что и в статье (правда абсолютно непонятно, где такую всрат..ю форму можно применить):
Чтобы получить заготовку, можно, например, в Inkscape (бесплатно) отрисовать любую форму или заготовки форм, материлизовать все трансформации и сохранить как "Optimized SVG", затем открываете SVG текстовым редактором и то что в path переносите в cli-path: path( "вот сюда" ), используя CSS-пременные, можно сделать любой конструктор.
Это следование стандартам, лучшая оптимизация и не изобретение своего велосипеда. Читать документацию иногда реально полезно.
Запрос должен быть представлен одной функцией, и абсолютно все равно, откуда она будет вызвана.
Если реально устройство очень тяжёлое по количеству модулей и сами модули самостоятельные, то может и есть смысл делать очередь PM, но тогда надо учитывать то, что модули могут иметь разное время обработки этих событий, и надо дожидаться их статуса, вплоть до того, что модуль сможет отменить уход в сон или что-то ещё (из-за ошибки или из-за того что-то обрабатывает).
Но в 99% эмбедеда этого нет, и решается централизованной фй, а все модули ведомые. Никчему переусложнять это дело.
Вроде очевидно, что данные нужно хранить там, где они не должны теряться, и в качестве защиты crc хранить, не сходится - нулевой ресет и переинициализация.
Для этого для каждого самостоятельного модуля заводится статус в массиве статусов, так кроме этого ещё какая-то телеметрия может для конкретного модуля храниться - например чем модуль в данный момент инициализирован.
Модем - типичный модуль, мало того - основной цпу - такойже модуль и там тоже хранится его текущее состояние - например сон, или глубокий сон или вообще обесточка.
Не понял, в чем проблема по наступлению любого пробуждения, просто проверить состояние кнопки/зарядки/чего-то ещё и согласно приоритету на каждое действие решить что делать?
Если нужна последовательность действий типа показать, что заряд на 0 и упасть в сон - для этого есть очереди (на томже ESP), если их нет, то примитивно они реализуются на массиве и 2х функциях - потребителе, и поставщике.
Ага, а у меня другие карты, может быть с этим связано, а вы разбирали этот кейс? Нет фоток внутренностей? Может там термопад можно засунуть между корпусом и картой? Я, конечно, тоже еще поковыряю его, но я его не открывал, так как проблем не было с ним.
Вот это уже по делу, ИМХО, с этого и надо было статью начинать. Благодарю.
Просто ИМХО заголовок "Делаем" означает что это не первая поставка )
Ну и если вы только отправили первую партию - у вас пока прототип, ибо робот для произодства, без обкатки на этом самом производстве, это, извините, прототип и ничего более - до реального робота ему еще как до луны пешком.
Окей, что насчет сравнения с мировыми брэндами? В чем лучше? В чем хуже? В чем преимущества? Насколько сопоставима математика? Стоимость для примерно одинаковых по спекам устройств?
Тут ведь тех. ресурс, уж извините - джинсу тут не любят, для этого есть другие ресурсы типа VC и тд.
Начиналось с прикольной невозможной фигуры, а кончилось все безликой п..й, простите.
Ну и конечно, новое лого и слоган - это главное для облака, от щас заживем!
Реальное видео работы вашего манипулятора рядом с реальным станком можно посмотреть (туже загрузку болванки)? Того же M13? Ибо на сайте я вижу только 3D-рендеры и все.
На какиех предприятиях внедрено? Как в плане конкуренции с FANUC / ABB / Kuka?
Пока у меня впечатление, что у вас что-то возможно есть, возможно как-то связано с роботами, но по тому что я вижу - только на бумаге, либо 1 тестовый образец.
Биографию Альтушки прочтите - и все встанет на свои места )
Божечки! Вот код для любого устройства с микрофоном)
Приведите пример такой транзакции, чтобы понять точно о чем разговор.
Так как обычно данные описаны именно на уровне данных и бизнеса, и они просто протягиваются через слои, которые с ними работают. От языка там только названия, никакой доп. сложности ни инструменты, ни слои к данным не добавляют. К общей архитектуре - да, ибо каждый слой - это отдельный сервис.
Т.е. грубо говоря как у вас есть сейчас, и к чему вы хотите прийти на примере.
После этого можно будет поговорить предметно.
да, да, никогда такого не было и вот опять )))
Дело не в языке, а в сложности того, что им описывают, а язык вообще можно хоть какой использовать, если верно сложность понять - хоть на 1C писать, хоть на асме.
Зоопарк протоклов не от того, что там матрешка, а от того что данные, которые пытются формализовать очень сложные + ограничение каналов связи + ограничение клиентов - оттуда и вложенность и указание только нужных полей и тд.
Вы гуманитарий? - ибо очень похоже - им постоянно такие идеи приходят в голову, но они, к сожалению, не более чем от не понимания того, что происходит и как это работает.
Реально, по номеру телефона? ))))))
Вобщем, очередной коммерческий и бесполезный пост из цикла "Я СДЕЛАЛЪ!" не проанализировав нормально рынок, т.к. бесплатного очень много и все работает, часть вообще в докер завернута, нужно только стянуть и запустить.
Из быстрого без головняка это AMMY (кторому пророчили смерть бесчетное количество раз) и ASPIA от нашего соотечественника (очень много именно нужных функций без мишуры и свистелок, малый размер файлов, есть linux/mac/win).
ASPIA вполне пригодна для энтерпрайза, исходники открыты, бесплатна и вообще без своих сервреров, для пробивки NATa в комлекте есть утилитка, разворачивающаяся в полпинка.
Речь идёт о том, что при вордврапе в вашем случае отрезается не ровно а по границе слова, это понятно.
Я же говорил про стандартный вордврап.
И я работаю и ни разу не было необходимости в переносе по словам. Ни у меня, ни у коллег по цеху. Все решается либо wordwrap-ом, либо стрелками.
Там, где нужно больше, нужно использовать IDE с предпросмотром того же MD, а не консольный инструмент, абсолютно не проходящий для данной задачи, насиловать.
А зачем нужно в техническом редакторе фича из полновесного текстового редактора?
Оно и висело 9 лет, потому что технарям оно не нужно от слова "совсем". А остальные не в курсе про FAR :)
Фича это еще и производительность жрет, так как и навигация и выделение становится не тривальной задачей, а редакором FAR можно открывать многомегабайтные файлы - он должен быть прост, как валенок и быстр настолько, насколько он может быть.
Давайте туда еще карту навигации засунем, висящие переносы и ударения :)
Как раз переносы по словам в JSON - это будет дикая боль, говорю как бэкэндер, который JSON-портянки каждый день смотрит. Редактор в FAR - это быстро пробежаться по JSON, причем обычно с word-wrap и вообще без скроллинга, а если надо изучать - открывать надо в соответствующем редакторе, с возможностью скрывать узлы и тд - текстовый редактор вообще не для этого.
Логи точно также отлично смотрятся с word-wrap, а также с помощью ctrl+стрелочки во вьювере, которые сразу скроллируют куда нужно.
Вобщем, каждому инструменту свое, не надо из любого редактора текста пытаться сделать IDE.
А вот что реально не хватает - это форматтеров, как раз того самого, минимизированного до одной строки JSON, у меня для этого бьютификатор прикручен через LUA, а вот нативный был-бы удобнее.
Все, что скажу дальше - мое ИМХО)
Во-первых рок - очень плохой выбор для неокрепшего ума, поскольку очень эмоционально заряжен, и смысл содержит в словах и образах, а то и вообще скрытый и его необходимо понять. В языках подобная конструкция называется матом. Вобщем, для ребенка очень не очень.
Во-вторых зачем тут MP3? MicroFAT и WAV-out через PWM за глаза - композиций-то чуть-чуть, SD меньше 8 гигов уже и не достать, кратко - ATMEGA/ATTINY + SD + усилок (возможно даже и без него, если негромко и динамик правильный). Алго - композиция доиграла или книжку закрыли - упали в глубокий сон. Для минимизации размера я бы вообще ATTINY85 взял, но там есть проблема с количеством ножек и определением страницы, в вашем случае 1 ножки в режиме ADC + нескольких сопротивлений хватило бы за глаза.
В-третьих - картинки, ну про них уже сказали.
А кто-то может сказать кратко, как сейчас обстоят дела с LTO7/8? Потому что нормальный интерфейсы начинаются только с этих версий, а мучаться с FC (LTO5/6) никакого желания нет вообще.
Когда я смотрел пару лет назад, стоимость одного привода болталась где-то около 2000$, какие-то подвижки появились в плане цены? И еще сразу - если брать БУ, то где лучше? EBAY?
Оно реально и делается за 5 минут.
Кастомизировать можно через переменные/классы и это будет праильно, нативно и без костылей. Человек выше все праавильно написал.
И чтобы не быдь голословным и чтобы отстали от человека выше:) вот тотже шейп, что и в статье (правда абсолютно непонятно, где такую всрат..ю форму можно применить):
clip-path: path( "m14.065 2.4e-4c-7.7921 0-14.065 6.2732-14.065 14.065v27.491c0 7.7921 6.2735 13.997 14.065 14.065l62.031 0.54156c18.869 0.15509-1.4926-18.141 22.957-17.76 19.856 0.3092 19.105-4.2759 19.002-9.8528l0.18552-14.485c0.0998-7.7914-6.2732-14.065-14.065-14.065z" );Чтобы получить заготовку, можно, например, в Inkscape (бесплатно) отрисовать любую форму или заготовки форм, материлизовать все трансформации и сохранить как "Optimized SVG", затем открываете SVG текстовым редактором и то что в path переносите в cli-path: path( "вот сюда" ), используя CSS-пременные, можно сделать любой конструктор.
Это следование стандартам, лучшая оптимизация и не изобретение своего велосипеда. Читать документацию иногда реально полезно.
Запрос должен быть представлен одной функцией, и абсолютно все равно, откуда она будет вызвана.
Если реально устройство очень тяжёлое по количеству модулей и сами модули самостоятельные, то может и есть смысл делать очередь PM, но тогда надо учитывать то, что модули могут иметь разное время обработки этих событий, и надо дожидаться их статуса, вплоть до того, что модуль сможет отменить уход в сон или что-то ещё (из-за ошибки или из-за того что-то обрабатывает).
Но в 99% эмбедеда этого нет, и решается централизованной фй, а все модули ведомые. Никчему переусложнять это дело.
Вроде очевидно, что данные нужно хранить там, где они не должны теряться, и в качестве защиты crc хранить, не сходится - нулевой ресет и переинициализация.
Для этого для каждого самостоятельного модуля заводится статус в массиве статусов, так кроме этого ещё какая-то телеметрия может для конкретного модуля храниться - например чем модуль в данный момент инициализирован.
Модем - типичный модуль, мало того - основной цпу - такойже модуль и там тоже хранится его текущее состояние - например сон, или глубокий сон или вообще обесточка.
При таком подходе понять, что делать элементарно.
Не понял, в чем проблема по наступлению любого пробуждения, просто проверить состояние кнопки/зарядки/чего-то ещё и согласно приоритету на каждое действие решить что делать?
Если нужна последовательность действий типа показать, что заряд на 0 и упасть в сон - для этого есть очереди (на томже ESP), если их нет, то примитивно они реализуются на массиве и 2х функциях - потребителе, и поставщике.
Ага, а у меня другие карты, может быть с этим связано, а вы разбирали этот кейс? Нет фоток внутренностей? Может там термопад можно засунуть между корпусом и картой? Я, конечно, тоже еще поковыряю его, но я его не открывал, так как проблем не было с ним.