Перейти к публикации

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


s_liam

Рекомендованные сообщения

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

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

Ссылка на сообщение
Поделиться на других сайтах


UnPinned posts
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, но не выдаст сообщение об ошибке. Тоже так себе решение.

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

Пробовал и "псевдоним" переменной назначить через 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, работает с ней напрямую.
Или что-то где-то я упускаю. В общем, думаю далее.
В общем, простая задача какой-то муторной выходит.

Изменено пользователем s_liam
Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах
19 минут назад, mr_Voden сказал:

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах
Только что, mr_Voden сказал:

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах
Только что, mr_Voden сказал:

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах
19 часов назад, mr_Voden сказал:

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

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

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

Изменено пользователем s_liam
Ссылка на сообщение
Поделиться на других сайтах
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.

Ссылка на сообщение
Поделиться на других сайтах
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.
Как вытянуть строку программы? Где посмотреть переменные, в которых хранятся данные? Её в перечне переменных нет.
Но при этом в окне статуса есть такая информация. Значит это сидит в какой-то переменной. Но как найти в какой?

Изменено пользователем s_liam
Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
1 минуту назад, mr_Voden сказал:

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.




×
×
  • Создать...