cnc-club.ru

iMaks-RS писал(а):

UAVpilot писал(а):ты первый с этим столкнулся

Учитывая объём/стоимость памяти 15 лет назад , эта проблема решалась только разбиением УП на несколько файлов? Т.е. так, как сделал zaxalex? И связано это с тормозным, по отношении к памяти интерфейсом IDE? Сейчас, при наличии NVMe интерфейса... эта проблема может быть закрыта... ведь скорость на уровне DDR2-400... Или я не прав?

Как думаешь, какой объем ОЗУ нужен чтобы открыть УП 25Мб? был ли он доступен 15 лет назад

UAVpilot писал(а): Я б просто на этапе создания сгруппировал бы все операции в несколько отдельных УП..

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

UAVpilot писал(а): Думаешь за почти 2 десятка лет существования LinuxCNC/EMC2 ты первый с этим столкнулся?..

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

Ты ни тут, ни где-то ещё не получишь готового 100%-ого рецепта, только предположения, которые надо проверять. Поэтому сам решай как далее поступить - ждать непонятно сколько возможного решения своей проблемы кем-то программным путём и всё это время мириться с простоями станка, либо например попробовать добавить памяти...

Лайфхак при подготовке УП для древесных панно - ставьте в CAM'e точность обработки на уровне 2-3 десяток, а не 2-3 соток. Файлы УП заметно похудеют.

А если требуется детализация на порядок превышающая возможности станка/материала?..

MX_Master писал(а):Лайфхак при подготовке УП для древесных панно - ставьте в CAM'e точность обработки на уровне 2-3 десяток, а не 2-3 соток. Файлы УП заметно похудеют.

Тогда движение станка превратится в дёрганное

MX_Master писал(а):Лайфхак при подготовке УП для древесных панно - ставьте в CAM'e точность обработки на уровне 2-3 десяток, а не 2-3 соток. Файлы УП заметно похудеют.

Так же сэкономить размер файла УП можно убрав нумерацию строк

UAVpilot писал(а):Как думаешь, что будет, если в момент вращения шаговика с некоторой скоростью импульсы step вдруг перестанут поступать, а спустя некоторое время появятся с прежней частотой?..

если jitter выйдет за допустимые пределы вывалится сообщение, но его же нету у автора, да и остальные оси все приезжают туда куда надо, а так статистически произвольная ось теряла бы шаги.
плюс как это объясняет проблемы автора, у которого шпиндель внезапно уезжает на приличные расстояния по Z, вдруг сходит с ума планировщик да так, что показания на DSO корректны а единственному степгену каждую мс. уходят некорректные задания?

MaksSavchuk писал(а):если jitter выйдет за допустимые пределы вывалится сообщение

Не сразу и не всегда.

MaksSavchuk писал(а):да и остальные оси все приезжают туда куда надо, а так статистически произвольная ось теряла бы шаги.

Она не статистически произвольная, а самая "активная".

MaksSavchuk писал(а):вдруг сходит с ума планировщик да так, что показания на DSO корректны а единственному степгену каждую мс. уходят некорректные задания?

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

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

zaxlex, это и есть железобетонные костыли.

С учётом лимита 1Гб~500к строк, получается что лучше ставить одну плашку максимального объёма, поддерживаемые платой/процессором?

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

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

Реально. Копать со стороны углублённого изучения документации на LinuxCNC и до кучи про режимы обработки и режимы работы фрез...

тогда предложу сделать скрипт "умным".. получал данные об установленной памяти и её количестве.. в данном случае брать минимальный размер и исходя из 450к=1Гб уже резать файлы... только вот на пайтоне этот скрипт наверное будет долго очень колбасить...

evgenymcp писал(а):ОЗУ нужен чтобы открыть УП 25Мб? был ли он доступен 15 лет назад

лог файлы Squid и Samba должны были на мертво вешать машину с 256Мб ОЗУ... про логи ipchains и Apache я тогда промолчу..

iMaks-RS писал(а): лог файлы Squid и Samba должны были на мертво вешать машину с 256Мб ОЗУ... про логи ipchains и Apache я тогда промолчу..

логфайлы потому и файлы, что лежат на диске, а не в ОЗУ...

iMaks-RS писал(а):

evgenymcp писал(а):ОЗУ нужен чтобы открыть УП 25Мб? был ли он доступен 15 лет назад

лог файлы Squid и Samba должны были на мертво вешать машину с 256Мб ОЗУ... про логи ipchains и Apache я тогда промолчу..

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

evgenymcp писал(а):Никогда не наблюдал каких-то проблем с открытием тяжелых текстовых файлов.

Потому что они открываются посредством mmap(2).

Вот тут https://forum.linuxcnc.org/38-general-l ... -very-slow тоже разбирается проблема загрузки больших файлов, правда, в плане тормозов интерфейса, а не сбоев координат.