cnc-club.ru

1240 писал(а):В это время я могу открыть(отредактировать, удалить) файл.
Сообщений о запрете таких действий не будет.
Вывод:
Станок загружает всю программу в ОЗУ.

Вывод преждевременный.
У меня на станке (не linuxcnc) можно удалить файл во время обработки, но через некоторое время станок уткнется в отсутствие продолжения файла.
Т.е. он держит в памяти примерно пол минуты будущей УП.
Если изменить выполняемый файл - изменения повлияют на последующую обработку.
Сам не проверял, но, вероятно, можно дописывать файл по ходу обработки, и система управления будет подхватывать новые части фала УП.
Правда я не знаю, можно ли удалять уже отработанную часть УП, и как вообще это можно сделать.

да - keystick шпарит и без файла...
посмотрим далее - но минут 10 работает...
--------
а вообще команда на том же питоне для файла open что обозначает?
наверно полную загрузку в оперативку...
тогда что тут гадать )))

1240 писал(а):В это время я могу открыть(отредактировать, удалить) файл.
Сообщений о запрете таких действий не будет.
Вывод:
Станок загружает всю программу в ОЗУ.

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

P.S. В описании сделано много упрощений, чтобы можно было понять суть без изучения структуры FS.

michael-yurov писал(а):но через некоторое время станок уткнется в отсутствие продолжения файла.
Т.е. он держит в памяти примерно пол минуты будущей УП.

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

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

Скорее всего, в ОС имеется буфер, куда при чтении загружается кусок файла. Минимум блок (512 байт), а скорее всего кластер (обычно несколько десятков килобайт). Оттуда и берутся данные (побайтно, построчно или как угодно прикладной программе). Еще один буфер имеет право быть в самом LinuxCNC. Возможно, чтение УП происходит так:

1. открыли файл УП в режиме read-only. (fopen())
2. спозиционировались на нужное место файла (fseek())
3. прочитали сколько-то строк УП
4. закрыли файл. (fclose())
5. выполнили прочитанные строки УП
6. если не было конца УП или конца файла, повторить с 1.

При этом файл между обращениями свободен для изменения сторонними программами.
Всякие GUI типа axis читают тот же файл независимо от ядра LinuxCNC (все забываю, как оно там называется )

nkp писал(а):а вообще команда на том же питоне для файла open что обозначает?

open только открывает файл read() - читает.
При этом то, что читается в keystick - это далеко не то, что будет выполняться LinuxCNC, у него должен быть свой парсер, у gui свой (gremlin или что-то еще).

Nick писал(а):что читается в keystick - это далеко не то, что будет выполняться LinuxCNC

хотелось бы конечно разобраться - если верить тому - что сам емс берет код из файла порциями - тогда бы можно было на лету вносить изменения в "неиспользуемую часть"

Serg-tmn писал(а):Возможно, чтение УП происходит так

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

nkp писал(а):а вообще команда на том же питоне для файла open что обозначает?
наверно полную загрузку в оперативку...

на питоне не знаю, а на Си традиционно было не так. Еще не так давно память стоила достаточно дорого и ограничивать размер обрабатываемого файла размером ОЗУ было бы безрассудно (мягко говоря).

Торможение (ограничение) при загрузке больших файлов вызвано необходимостью отображения большого количества линий соединяющих характерные точки G0(1)XYZ.
Если отображать каждую десятую (сотую или тысячную) точку (и возможно, точки изменения направления движения) можно ли разгрузить компьютер и получить визуализацию больших программ.
Дополнительно ввести команду "РАМКА" (название условное) внутри которой LinuxCNC должен отображать все точки.

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

Так можно пропустить что-то важное...
По идее можно попробовать добавить скриптом в код строки (AXIS, hide) (AXIS, show)
Можешь скинуть на какой-нибудь обменник пример большого кода?
(лучшк всего http://disk.yandex.ru/)

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

1240 писал(а): Хотелось бы понять какой объем ОЗУ необходим для выполнения УП допустим на 100Мб?

у меня при загрузке доходило примерно до "за три гига" и вылетало.

Поправил
(Когда выбирал вопрос я выкидывал из сообщения всё остальное и запутался)

Некоторые редакторы (я пользовался редактором из FAR 3) при создании файла в начало пишут несколько байт, обозначающих текущую кодировку. Другие программы эти байты обычно либо используют, либо просто игнорируют.
Но только не LinuxCNC! Вот от подобной "программы" я долго пытался добиться взаимности, пока не открыл ее двоичным редактором и не увидел в начале символы EF BB BF, которые и сбивали с толка интерпретатор G-кода.

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

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

Nick писал(а):А есть где-то стандарт по этому поводу?

Да, есть.
Собственно, вот http://ru.wikipedia.org/wiki/Byte_order_mark
gedit, например, их никак не показывает, зато при записи файла бережно сохраняет

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