cnc-club.ru

UAVpilot писал(а):Не надо триггер, надо просто выбрать частоту, чтоб не пропадало при "плавании".

А если комп глюканул? Ну вот шла прога шла и вдруг БАЦ непредвиденная задержка RT ядра. Ведь LinuxCNC в этом разе рисует красное предупреждение и продолжает колбасить, но, как моя практика показала уже не там и не то. Круги не круглые, прямые не той длины и т.п. "Приколы".

UAVpilot писал(а):А если питание пропадёт на чуть-чуть, тоже попытаешься какой-нибудь триггер прикрутить? Или просто постараешься сделать так, чтоб не пропадало?

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

nanthony писал(а):непредвиденная задержка RT ядра.

Тут первая половина фразы противоричит второй.
RealTime ядро - это такое ядро, которое обеспечивает гарантированное время реакции на события.

nanthony писал(а):Ведь LinuxCNC в этом разе рисует красное предупреждение и продолжает колбасить

А надо в конфиг прописывать реальные значения latency-test, а не то, которое больше нравится.
А то часто слышно примерно такое: "тест в основном показывает 10000, но очень редко прыгает до 80000, в конфиг прописал 15000".
Нужно понимать что тут не пиписьками меряются, а указывают системе реальные возможности железа.

UAVpilot писал(а):RealTime ядро - это такое ядро, которое обеспечивает гарантированное время реакции на события.

Спасибо Это как раз "моя" тема, так что кое-что понимаю.

UAVpilot писал(а):А надо в конфиг прописывать реальные значения latency-test

Делаем LattencyTest все ставим как сказано (никаких измерений пиписек, только суровые цифры) - раз в день выскакивает "непредвиденная задержка", станок сбивается и глючит после этого. Т.е. одного сбоя достаточно чтобы что-то шло не так уже до самого перезапуска. Ставим задержку больше - не выскакивает или выскакивает реже. (про то как поборол не буду, а то опять писанины будет тонна)
Я думаю, что в момент этой задержки пропадет или собъется сигнал chargepump (поставил цифирку заведомо меньше lattency-тестовой так и есть, сбивается). И надо сей момент уловить и отреагировать чтобы дальше материал не портить.

Хотя может Вы и правы. "Если бы он вез патроны" не про эту тему.

nanthony писал(а):Делаем LattencyTest все ставим как сказано

И пяток фильмов запускается на полный экран?..

UAVpilot писал(а):И пяток фильмов запускается на полный экран?..

И пяток фильмов и куча всякого. Поверьте. В этой части я правда разбираюсь. "Пиписьками", как Вы изволили сей процесс назвать, "померился", конечно, но лишь в целях тестирования и для себя. Глупый тест, но понимать что будет если совсем плохо надо.
К слову сказать, RealTime kernel в Linux не делает из Linux RTOS. Это лишь попытка. RTAI тоже. На писюковом железе вообще сложно сделать что-либо RT. Скорее невозможно.
Но гарантировать что будет "не хуже" можно. Эту гарантию и дает lattency test. Но только в том случае, когда "все что можно произошло в момент тестирования". И фильмы, хоть 5, а хоть 10 не дадут такого "эффекта" как опрос ddns или USB железяка случайно решившая что ей пора спать или проснуться или WiFi адаптер решивший переключиться на другую станцию базовую (Вы скажете "надо все отключать". Знаю, но хоть одно средство связи и переноса данных надо оставить и надо понять какое меньше влияет).
События по времени микроскопические, по происхождению малоконтролируемые, а по вреду для задержек - кастратофические.
Я, например, протестировал и понял, что Core I7 и т.п. на новых матерях - категорически хуже чем старый PIII или P4 без HyperThreading (это и в описании написано, но руками оно яснее). Может и не быстрее, а стабильнее. В новых матерях некоторые приколы вообще не отключаются. А на старых - запросто.

nanthony писал(а): На писюковом железе вообще сложно сделать что-либо RT

Значит нужно уменьшать зависимость от РТ. Переходите на управление положением и внешние привода.

nanthony писал(а):На писюковом железе вообще сложно сделать что-либо RT. Скорее невозможно.

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

nanthony писал(а):И фильмы, хоть 5, а хоть 10 не дадут такого "эффекта" как опрос ddns или USB железяка случайно решившая что ей пора спать или проснуться или WiFi адаптер решивший переключиться на другую станцию базовую (Вы скажете "надо все отключать".

Ни в какой современной реализации RT Linux (RTAI в том числе) подобные катаклизмы не приведут к лагам RT.
C RTAI на ядрах 2.6.x могут случаться лаги, но только при проблемах с доступом к SATA/IDE дискам, но те, кто использует проблеммные диски или запускают во время работы станка какие-то проги, желающие активно общаться с дисками - ССЗБ. Кстати, пользующие ядра 2.6.x при наличии работающей сборки LinuxCNC на ядре 3.4 тоже попадают в эту категорию.

nanthony писал(а):Я, например, протестировал и понял, что Core I7 и т.п. на новых матерях - категорически хуже чем старый PIII или P4 без HyperThreading (это и в описании написано, но руками оно яснее). Может и не быстрее, а стабильнее. В новых матерях некоторые приколы вообще не отключаются. А на старых - запросто.

Включается и отключается практически всё, если не через BIOS, то через /sys.

Доброго здравия, Господа!
Дал себе зарок: не писать если нет ничего созидательного, конструктивного или конкретного вопроса. Таковой появился.
(Ниже отвечу на Ваши ценные (без шуток) замечания.)

Итак. Долго макетировал. (Уж простите, навык потерял). И пришел к выводу, что нужно все-таки сделать нечто, что могло бы анализировать поток chargepump, хотя бы. До процессоров с анализом step/dir мне пока как до Китая на оленях задним ходом. Так что за неимением кесарева - буду пользоваться слесаревым.

Наваял (ну, из даташита взял, конечно, чуть "поиграл", правда это 5 схема, остальные забраковал, файл приаттачен) схемку Missing Pulse Detector. Вместо одновибратора для запуска пока поставил кондер (одновибратор тоже сделал, но корявый пока какой-то). При подаче напруги на макетку кондер очень даже заменяет кнопку ручную и одновибратор.
Настроил ChargePump на частоту от 60 до 100кГц (собрал генератор для тестов с резюком переменным, пока без LPT, зато можно помехи "рисовать" любые ).
Эта штука детектит пропадение несучьей на "раз-два", ровно как и понижение частоты ниже порога, определяемого кондером который транзистор шунтирует. Но есть вопросы:

1. Частота не великовата? Нагрузка все-таки будет на генератор Charge сигнала.
2. Если отбросить "это без надобности" и "так никто не делает": такая схема жизнеспособна?
3. Появление схемы ChargePump+MissingPulseDetector вроде понижает надежность за счет числа элементов, но повышает уровень обратной связи от станка. Вот тут я в замешательстве.

Теперь ответы. Надеюсь кто-то дочитает до здесь

UAVpilot писал(а):Но они вполне успешно обходятся, если не хотеть чудес.

Чудес не бывает

UAVpilot писал(а):....или запускают во время работы станка....

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

UAVpilot писал(а):Включается и отключается практически всё, если не через BIOS, то через /sys.

Практически, но не все. Скажем, я нашел мать асус и еще пару других, у которой хайперовые ядра не отключаются вообще, а на другой - запросто (с тем же процом и всем железом, только мать иная). И /sys не помогает.
Вообще-то все эти /sys с отключениями и прочими модулями - это все от лукавого. Если уж и делать на писюке нечто приближенное к RT - то собирать всю ось статикой и ядро исключительно с нужными фичами. Тогда можно чего-то добиться. А пока все из пакетов... не.

UAVpilot писал(а):Ни в какой современной реализации RT Linux (RTAI в том числе) подобные катаклизмы не приведут к лагам RT.

Странные вещи Вы говорите. Конкретный тест. Бибика показывает (в течении 6 часов) lattency test 8200. Я сижу рядом и админю. Решил перегрузить базовую станцию (веером, у меня их 20 штук, апдэйт), смотрю на lattency test - а там 21000. Проверяю. Действительно. При перескоке со станции на станцию и обратно вылетает задержка. Это разве не катастрофа?
Второй тест. Сижу пилякаю (пылесос из другой темы) на комп подключил диск USB на котором код принес, перелил код на внутренний SSD, диск не отключил, но размонтировал. Диск засыпает посередине прямого участка (вырезал квадрат из оргстекла). На компе вылетает "непредвиденная задрежка РТ, это сообщение выдается один раз за сессию... бла-бла-бла" и станок, поворачивая на 90 градусов промахивается на миллиметр. Это не катастрофа?
Клянусь чем хотите, что и в том и в другом случае я результат lattency test'а умножал на 1.5 и ставил значение заведомо больше.

А вообще, как мне кажется, в этой области, мы говорим одно и тоже, только словами разными. Заставить работать и за пивом бегать можно все. Вопрос с какой надегой и какими средствами.

Impartial писал(а):Значит нужно уменьшать зависимость от РТ. Переходите на управление положением и внешние привода.

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

Но, если тема про LPT (а тут у многих именно он), то значит и управление и прочие "примочки" дорогостоящие это не совсем целевая тема. Я, например, пока с шаговиками сижу и радуюсь. Думаю как их по-круче использовать. Хотя сервы уже заказаны. Но ведь это не означает, что нынешний станок сразу полетит в помойку? Надо и таким устройствам работу давать.

Прошу простить, в схеме не разобрался. Просто спрошу:
Если прекратить подачу импульсов, сигнал на выходе CargePump пропадает, это понятно,
а если остановить генерацию импульсов в высоком состоянии?

michael-yurov писал(а):а если остановить генерацию импульсов в высоком состоянии?

Хм. Щя проверю......
Спасибо за вопрос. Косяк. Не срабатывает. Пошел дальше думать......
(Процессор что ли городить на все подобные условия? Или счетчик просто?)

nanthony писал(а):Процессор что ли городить на все подобные условия? Или счетчик просто?

Используй 74HC123
Там все проще простого - понадобится еще конденсатор и резистор для задания частоты.

Голубой - минус (GND)

Красный +5 В

Первая ножка (1A) - вход сигнала.

13 и 14 (1Q и 1Q) - выходы прямой и инверсный.

С1, R8 - задающие время.

nanthony писал(а):1. Частота не великовата? Нагрузка все-таки будет на генератор Charge сигнала.

Великовата, редкий комп её сгенерит. 500-1000 Гц вполне достаточно.

nanthony писал(а):И /sys не помогает.

Сомнительно... Надо в живую смотреть...

nanthony писал(а):Вообще-то все эти /sys с отключениями и прочими модулями - это все от лукавого. Если уж и делать на писюке нечто приближенное к RT - то собирать всю ось статикой и ядро исключительно с нужными фичами. Тогда можно чего-то добиться. А пока все из пакетов... не.

Глупости. Начиная с 2.4 ядра Linux полностью модульные, на незагруженный модуль не расходуется ни бита памяти, ни такта процессора.

nanthony писал(а):Странные вещи Вы говорите. Конкретный тест. Бибика показывает (в течении 6 часов) lattency test 8200. Я сижу рядом и админю. Решил перегрузить базовую станцию (веером, у меня их 20 штук, апдэйт), смотрю на lattency test - а там 21000. Проверяю. Действительно. При перескоке со станции на станцию и обратно вылетает задержка. Это разве не катастрофа?

Что за адаптер? Скорее всего из "современных тряпочных", которые обделены собственными мозгами и юзают ЦП. Надо смотреть код драйвера, вероятно автор использует приёмы типа "задержа в виде пустого цикла" и т.п.
Я уже тут много раз писал, что RTAI - тупиковый путь и из современных ядер постепенно убирают механизмы, которыми он пользовался. Так что не стоит надеяться, что новые драйвера и другие компоненты будут хорошо работать с RTAI. Нужно перебираться на Xenomai и т.п.

nanthony писал(а):Уж лучше быть богатым и здоровым.....

Нельзя так однозначно оценивать влияние задержек ОС на работу системы ЧПУ.
Для примера возьмем схему управления станком по степ/дир через ЛПТ порт.
В данном случае от стабильности отработки временных интервалов будет зависеть только скорость обработки. Даже не точность. Даже если предположить задержку в 1с то эта задержка для всех осей. Это чревато только пропуском шагов так как возникнут перегрузки механики по ускорению.
Если учесть что это любительская система то вполне допустимы задержки в пределах (в пересчете) максимальных ускорений.
Как показывают расчеты болтанка базового потока в пределах 50% вообще не оказывает никакого влияния на точность. (с оговоркой на малые скорости обработки)

Господа! Помогите тупому разобраться.
Хочу сделать charge-pump (схемку вроде на макетке отладил, теперь полевые тесты). Включаю на 17 пине (ну, хотел на 1, сразу не заработало) "пульс" (charge-pump). В конфигурации все зашибись, как в мануале написано один к одному. И дуля. На пине нишиша. Причем, если повесить на 1 или 17 пин что-то еще из выходов - все работает. Хоть Enable, хоть Step, хоть Dir. А чардж-помпы нет как нет. По-всякому уже делал. И как в мануале и как StepGen делает (выше как раз так). Что-то ничего не помогает. Если вешать пульс на 1 пин, вместо Enable, то там, почему-то 1ка все время, а если на 17 вместо реле - там 0 свисает.

Явно я что-то упускаю, но вот что ни ясень ни гугл не подсказывают.

А halscope что показывает?

Приветствую. Уже разобрался. Благодарю.
Причина была в моем непонимании. Как я и предполагал.
Halscope всегда показывал что разрешения чарджпамп - FALSE. Т.е. она была привязана к естопу (если я правильно понимаю).

Теперь все как у Маркса и Энгельса.
Другое дело, что надо теперь бы отдельный поток создать.... чтобы полкГц-кГц этот чардж памп сделать...

Stepconf generates a HAL line
net estop-out charge-pump.enable iocontrol.0.user-enable-out

This binding of charge pump and estop was preventing the charge pump working, even when I re-configured my Estop back to a pin on my first Par Port

Substituting
net estop-out iocontrol.0.user-enable-out
net charge-pump <= charge-pump.out

solved the problem and I can now jog axes.

nanthony писал(а):Halscope всегда показывал что разрешения чарджпамп - FALSE. Т.е. она была привязана к естопу (если я правильно понимаю).

для отладки его вообще "привязывать" не нужно ...
у него enable True по дефолту...

Вот уж не соглашусь. Не, я не спец. ТочнЯк. Скорее лох. Но у меня без привязки не работало. Когда сделал к кнопарю привязку - начал генерить.

Вот такое: Теперь зашибись выдает 501Гц сигнала ChargePump, а при периоде в 2м - 250Гц (что вполне закономерно).
Как выяснилось, нити (thread) можно запускать исключительно уменьшая частоту (увеличивая период) каждой следующей. Посему, если где-то есть нить с частотой ниже, то новую с частотой выше уже не создать. Все наверняка это знают, а для меня новость
И еще один нюанс, если две нити имеют одинаковый период - частенько выскакивает ошибка выполнения. Разведение периодов во времени убирает ошибку нафек. (что тоже объяснимо вполне)

nanthony писал(а):Другое дело, что надо теперь бы отдельный поток создать.... чтобы полкГц-кГц этот чардж памп сделать...

А чем штатный servo-thread плох?