Ограничение массива R-параметров на SINUMERIK и отлов DEF команд посредине программы.

[s_liam 65]

Всем привет.
Столкнулся вроде как с простой проблемой, но быстро решить не получается.
В общем, нужно ограничить количество R-параметров до 100. (Ну то есть чтобы при R100=23 выдавалась ошибка о неверном индексе массива).
Вроде как всё просто должно быть. Удаляем из определений Word переменную R, заданную как Siemens840DRCond.
В *.def  файле стойки прописываем определение массива, как DEF REAL R[100].
Но переменные работают только при присваивании им значения. Любые математические функции перестают работать. Возникает ошибка массива.
Как это победить пока не пойму.
И также, если определять массив R-переменных через DEF REAL R[100], то пропадает предупреждение в проекте, если идёт обращение к R-переменной, значение которой не было заранее определено.

Также ещё одна проблема. В SINUMERIK на стойке станка переменные можно задавать с помощью команды DEF только вначале программы (и подпрограммы). Если переменная будет определена через DEF после любой другой команды, то на станке возникает синтаксическая ошибка. В VERICUT это никак не ограничивается.
Как прописать проверку по этой штуке тоже не могу пока придумать. А то не все программисты это помнят и хорошо бы отлавливать это при симуляции.
Кто-то делал такую отловку у себя в проекте?

[mr_Voden 96]

4 часа назад, s_liam сказал:

В SINUMERIK на стойке станка переменные можно задавать с помощью команды DEF только вначале программы (и подпрограммы). Если переменная будет определена через DEF после любой другой команды, то на станке возникает синтаксическая ошибка. В VERICUT это никак не ограничивается.

Можно попробовать написать, только будет несколько макросов.

Первый в start of block processing - проверяет что записано в обрабатываемой строке. Если это не DEF (или какие-то другие разрешенные команды), то запрещаем работу DEF в этой программе.

Второй в описание DEF, который будет выдавать сообщение об ошибке, если первый это запретил.

Третий в PROC и М17, например. Будет наоборот, разрешать работу DEF при вызове подпрограммы и восстанавливать предыдущее состояние "запрета" после выхода из подпрограммы.

Возможно есть решение проще)

4 часа назад, s_liam сказал:

В общем, нужно ограничить количество R-параметров до 100. (Ну то есть чтобы при R100=23 выдавалась ошибка о неверном индексе массива).

Предварительно зарегистрировать все переменные от R1 до R100 через CGTechVarDefMacro или DEF, а word R удалить? Тогда, например, при отработке R102=5 переменная R10 получит значение 2, но не выдаст сообщение об ошибке. Тоже так себе решение.

[s_liam 65]

Да, тоже подумывал про примерно такие решения, которые Вы описали про Def. Но, трудоёмко для всех и стоек такое прописать, хотя и можно. А вот с R-переменной не могу решения нормального найти. Можно кто ещё чего подскажет. Сам подумаю посижу.

[s_liam 65]

Пробовал и "псевдоним" переменной назначить через CGTECH_MACRO "VariableArrayAlias" "1,____R,100". Думал, будет создан массив переменных, связанных с переменной R, но, похоже, это просто описание дополнительное существующей переменной даёт. Так что применимость этого макро пока не могу понять.

Почему VERICUT не понимает математические функции с использованием R-переменных, если определить её как VariableName - мне тоже не понятно. Так бы, как я писал ранее, можно было бы назначить массив переменных и использовать его, или использовать уже какую-то проверку в G-code processing на номер переменной. Пришлось бы смириться с отсутствием предупреждения, если переменная заранее не предопределена (как это происходит, если задать R как VariableTag или как Siemens840DRCond), но даже это не работает.
Думал создать ещё одну переменную (____R, например), которой бы приравнивалось значение при вызове R-переменной и проверять уже её. Но проблема в том, как сопоставить эти переменные, чтобы когда идёт объявление R-переменной автоматом обновлялась и ____R переменная? В VERICUT R-переменная, если она задана через VeriableTag имеет лишь порядковый номер. Например R1 будет в системе как переменная 1. И как это прописать в G-code Processing - не пойму.

Какого-то макро на ограничение массива VariableTag переменных не нашёл. А по другому через G-Code Processing не ограничить никак, поскольку если переменная определена через VariableTag, то VERICUT не глядит, что прописано в G-Code Processing, работает с ней напрямую.
Или что-то где-то я упускаю. В общем, думаю далее.
В общем, простая задача какой-то муторной выходит.

Edited April 12 by s_liam

[mr_Voden 96]

@s_liamVariable tag или CGTechVarDefMacro + анализ строки в Start of block processing на превышение номера переменной.

[s_liam 65]

19 минут назад, mr_Voden сказал:

@s_liamVariable tag или CGTechVarDefMacro + анализ строки в Start of block processing на превышение номера переменной.

А примерно как анализ этот выполнить?

[mr_Voden 96]

@s_liamПолучаем текущую строку, ищем R, проверяем ее значение. Если это переменная, то проверяем значение. Если вне разрешенного диапазона то сообщаем об ошибке. Могу попробовать реализовать.

[s_liam 65]

Я просто не совсем понимаю, как это в Start of block processing  реализовать в окне G-code Processing. То есть с помощью какого макро найти переменную (кстати, сложность еще в том, что фактически R-переменная это просто переменная с именем 1, как простая цифра). И как проверить. Ищу макрокоманды пока, какими можно что-то сделать.
Или же в Start of block processing нужно прописывать вызов подпрограммы и уже в ней каждый блок проверять на R-переменную и уже там проверять?

[mr_Voden 96]

@s_liamПисать макрос свой, больше никак.

[s_liam 65]

С этим я пока ещё не знаком. В том плане в чём макро свой писать итд.
Свой макро пишется как обычный текст подпрограммы (ну на подобии def и spf файлов) или что-то надо компилировать?

[mr_Voden 96]

@s_liamdll на c++ подключается к проекту

[s_liam 65]

Только что, mr_Voden сказал:

@s_liamdll на c++ подключается к проекту

Понял. Спасибо! Далёк от этого пока что.

Вообще, давно интересно было что-то изучить дополнительно: или VBA скрипты, которые для CATIA можно использовать, или на C++ что-то научиться делать, но самому с нуля всё это начинать ковырять как-то не решаюсь до сих пор. Пугают масштабы, там вроде как целая вселенная, а спросить под рукой не у кого. Хватало до сих пор IMSPost и VERICUT с их внутренними языками программирования повозиться. Плюс текущая работа. Надо голову лошади приделать себе, у ней она больше, туда много влезет знаний.

[mr_Voden 96]

@s_liamЭто совсем не сложно на самом деле) В соседней теме я выкладывал dll-ку с самописным макросом.

[s_liam 65]

Только что, mr_Voden сказал:

Это совсем не сложно на самом деле) В соседней теме я выкладывал dll-ку с самописным макросом.

Это я видел. Само тело макроса.
А вот код dll не поглядеть, она ж скомпилирована.
Наверное для простых вещей это несложно, но надо вообще хотя бы базовые знания иметь по программированию, по знанию языка, как сам компилятор использовать, как в нём определения и функции описывать, как их вызывать итд. Пока что не развивался в этом направлении.

[Sergey___1978 34]

Изучение любого языка программирования начинается с вывода на экран строки "Hello Word!".

А дальше уже дело техники и курение форумов.

[s_liam 65]

19 часов назад, mr_Voden сказал:

@s_liamПолучаем текущую строку, ищем R, проверяем ее значение. Если это переменная, то проверяем значение. Если вне разрешенного диапазона то сообщаем об ошибке. Могу попробовать реализовать.

А выглядит это примерно как?

То есть в Start of block processing после макро BlockInit вставляется самописный макро? А далее уже идёт обработка строки, которую можно получить каким-то образом в своём макро (строка в какой-то переменной VERICUT хранится)? И после этого вызываются подпрограммы, которые прописываются в .spf файле, например и отрабатывается уже подпрограмма через PROC?
В Start of block processing нельзя прописать сразу вызов подпрограммы, и в ней уже проверять, есть ли в строке R-параметр?
Просто суть хочу уловить, что можно такое в самописном макро сделать, что нельзя сделать в подпрограмме VERICUT.
Просто много всяких подпрограмм уже писал, там также можно работать с переменными и макросами VERICUT.

Edited April 13 by s_liam

[mr_Voden 96]

47 минут назад, s_liam сказал:

в Start of block processing после макро BlockInit вставляется самописный макро? А далее уже идёт обработка строки, которую можно получить каким-то образом в своём макро (строка в какой-то переменной VERICUT хранится)?

Обработка прямо в макросе идет. Никаких вызовов подпрограмм. Я вчера попробовал сделать. В 8.1 почему-то не удается получить обрабатываемую строку при вызове макроса из start или end of block processing, хотя в других event удавалось без проблем. Падает с ошибкой. С этим моментом я еще поразбираюсь. А в 9.2 тот же макрос в том же проекте работает корректно. Так что идея вполне рабочая.

 

52 минуты назад, s_liam сказал:

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

Просто не встречались с такими задачами. При работе с с++ больше нет ограничений, обусловленных доступным инструментарием в vericut по работе со строками, переменными, структурами данных и пр. Особенно это заметно при реализации контроллеров и их команд, никак не представленных в vericut.

[s_liam 65]

25 минут назад, mr_Voden сказал:

Просто не встречались с такими задачами. При работе с с++ больше нет ограничений, обусловленных доступным инструментарием в vericut по работе со строками, переменными, структурами данных и пр. Особенно это заметно при реализации контроллеров и их команд, никак не представленных в vericut.

Я вот это и хотел узнать, каким образом вытаскиваются переменные из VERICUT. То есть вызывается самописный макро, который написан на c++. И вот каким образом там выхватываются переменные VERICUT? По этому есть какая-то документация?
И опять же, если я в c++ могу выхватить эту переменную, то вероятно я смогу это же самое сделать в подпрограмме без программирования в c++? Условие-то прописать не проблема. Проблема, как считать строку и узнать, где что храниться и как это выхватить.

Поясню
Вот, например, я пересчитываю точку корректора инструмента в центр радиуса (необходимо для станка при активации точения с поворотной осью резца). То есть даже если в корректоре 1 была задана привязка резца от нижней точки на радиусе пластины, то по команде включения точения с поворотной осью, она сместится в центр радиуса. Параметры выхватываются из переменных VERICUT.

PROC _UPD_DRV_POINT()
    DEF INT _T_NUM, _D_NUM, _R_VAL, _NUM1, _NUM2
    _T_NUM=GETT(ToolInSpindle)
    _D_NUM=$P_TOOL
    IF(_TURN_B_FUNC==1)
        CGTECH_MACRO "DrivenPointOffsetDirect" "X" #$TC_DP14[#_T_NUM,#_D_NUM] - #$TC_DP14[#_T_NUM,9]
        CGTECH_MACRO "DrivenPointOffsetDirect" "Y" 0
        CGTECH_MACRO "DrivenPointOffsetDirect" "Z" #$TC_DP12[#_T_NUM,#_D_NUM] - #$TC_DP12[#_T_NUM,9] + #$P_TOOLR
        CGTech_Macro "AdjustToolOffset" "" 1
    ELSE
        CGTECH_MACRO "GageOffsetDrivenPoint" "" #$P_TOOL
        CGTech_Macro "AdjustToolOffset" "" 1
    ENDIF
RET

Так вот как выхватить значения переменных здесь понятно. Например #$TC_DP14[#_T_NUM,#_D_NUM] - переменная хранит значение смещения привязки инструмента по одной из трех линейных осей станка. К ней можно обратиться и манипулировать с ней. Она есть в таблице переменных VERICUT.
Как вытянуть строку программы? Где посмотреть переменные, в которых хранятся данные? Её в перечне переменных нет.
Но при этом в окне статуса есть такая информация. Значит это сидит в какой-то переменной. Но как найти в какой?

Edited April 13 by s_liam

[mr_Voden 96]

@s_liamДело в том что при вызове подпрограммы при обработке текущего блока вы попадете в рекурсию, тк подпрограмма так же состоит из блоков. Я уже пытался такое сделать)

8 минут назад, s_liam сказал:

Я вот это и хотел узнать, каким образом вытаскиваются переменные из VERICUT. То есть вызывается самописный макро, который написан на c++. И вот каким образом там выхватываются переменные VERICUT? По этому есть какая-то документация?

Есть, она в справке находится, в моем случае. Если не найдете, могу прислать.

Еще есть макрос GetBlockString. Он помещает текущий блок в заданную переменную.

[s_liam 65]

1 минуту назад, mr_Voden сказал:

Есть, она в справке находится, в моем случае. Если не найдете, могу прислать.

Еще есть макрос GetBlockString. Он помещает текущий блок в заданную переменную.

Про макро понял, спасибо.
А в справке - это который help по F1 который вызывается? В каком разделе? Там есть перечень переменных, доступных для использования или где-то в какой-то из тем? Или ещё какая-то специальная справка есть?