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

Параметры инструмента в 840D


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

В программе используется параметр $TC_DP3[$P_TOOLNO,1]. 

В Tool Table загружены инструменты с произвольными номерами. Макрос AutosetToolManLength840DVars сохраняет все длины инструментов в параметры $TC_DP3[N,1], при этом N принимает значения порядкового номера инструментов в таблице (от 1 до общего количества инструментов в таблице). А нужно, чтобы N принимала значения фактических номеров инструментов в таблице. Т.е. если в таблице есть только 3 инструмента с номерами 15, 27, 31, то на выходе нужно получить только три параметра

$TC_DP3[15,1],

$TC_DP3[27,1],

$TC_DP3[31,1],

вместо 

$TC_DP3[1,1],

$TC_DP3[2,1],

$TC_DP3[3,1].

 

Как это можно реализовать?

Можно, конечно, вставить инструменты-пустышки, чтобы инструменты с нужными номерами стояли на правильных местах, но это не выход.

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


8 часов назад, DJ Astro сказал:

В Tool Table загружены инструменты с произвольными номерами.

Так может нужен номер в магазине?

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

$P_TOOLNO разве определяется не как идентификатор инструмента текущий?

В стойке sin840d.ctl по крайней мере так.

Если у меня в УП

T11

или

T="11"

то он видит параметр $P_TOOLNO равный номеру этого инструмента.

На всякий случай попробуйте прописать в настройках стойки так, как на картинке.

Ну или проект кидайте - будет время, погляжу.



2019-03-04_121807.PNG

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

$P_TOOLNO разве определяется не как идентификатор инструмента текущий?

В стойке sin840d.ctl по крайней мере так.

Если у меня в УП

T11

или

T="11"

то он видит параметр $P_TOOLNO равный номеру этого инструмента.

На всякий случай попробуйте прописать в настройках стойки так, как на картинке.

Ну или проект кидайте - будет время, погляжу.

 

Да, всё правильно, $P_TOOLNO работает и определяется как ID текущего инструмента. Но загрузив, например, в таблицу единственный инструмент с номером "15", я ожидаю получить значение его длины в параметре $TC_DP3[15,1] (как это происходит в реальном станке), но Vericut это значение сохранит в $TC_DP3[1,1], а $TC_DP3[15,1]=0.

Если у вас будет возможность, попробуйте на стандартной 840й стойке из библиотеки vericut'a.

 

В хэлпе про макрос есть такая инфа

-2--1.thumb.jpg.51e162c4d096a268e10d5a0156037b9c.jpg

 

у меня и Tool Chain'a нету и все методы смены инструмента перепробовал в "Tool Change By..." - всё равно эти переменные нумеруются подряд не зависимо от номера инструмента.

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

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

Сделать так у меня уже не получится, у нас версия 8.2.1

 

В версии 7.4.2 появился макро, который отвечает за автоматическую расстановку оффсетов.

 

AutosetToolManOnOff

Function — VARIABLES

Status — ACTIVE

Comment — Added V7.4.2

Inputs 

Text: Not used

Value: 0 = Off, 1 = ON

 

This macro enables (ON) and disables (OFF) the AutosetToolMan macros.

 

Currently we are seeing a performance hit during load time associated with the AutosetToolMan macros.  Until the performance issue can be address, this macro can be used to disable these macros if the variables are not being used.  It should be called during the Reset event.  When performance improves, this macro will be OBSOLETE.

Может подобный есть макро в версии 7.1.3?Если его создать и присвоить значение равное единице, то в переменные $TC_DP значения будут занесены автоматически из активного инструмента. И тогда все будет работать.

В сочетании с AutosetToolManLength840DVars и значением: $TC_DP3 Z про который Вы писали это проставит значения в таблицу нужным образом (см картинку).

 

Чтобы это реализовать иначе, нужно думать, каким образом создать такую переменную. Или писать какую-нибудь подпрограмму, которая будет вызываться при смене инструмента.

2019-03-06_092907.PNG

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

вы используете версию 7.1.3.

Нет, это из хэлпа от 7.4.1.

 

Проблема в том, что в 7.4.1 нет связи между номером инструмента (ID) и номером строки (Index) в которой он находится в ToolManager'e.

В 8.2.1 это уже работает: в SetDynamicVars вместе с параметром CurTool теперь есть CurToolIndex.

 

***************

CurToolIndex # — The current tool index will be set in the specified variable. The tool index is defined as the nth tool within toolman. If the current tool is the 5th tool listed within toolman, the specified variable will be set to 5.

Example:

Override Text value = CurToolIndex $P_TOOLNO

 

CurTool # — The current tool number will be set in the specified variable. The tool number will be as defined before any tool indirection, such as can occur when a Tool List is in use.

***************

 

И я не смог в 8.2.1 добиться такого же результата, как на вашем примере. Вызываю 18-й инструмент, который стоит в 6-й строке таблицы инструментов.

AutosetToolManOnOff уже был прописан в 840й стойке, которая идёт с этой версией вериката, но почему-то в ветке Start of Processing. Хотя в мануале пишут, что должно быть в Reset. Добавил и туда - не помогло. 

 

 

2221.jpg

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

Кидайте проект. Можете в личку ссылку прислать на скачивание. Сделаю, думаю что. Только что прикрутил измеряшку для цикла CYCLE974 токарного станка, которого пока еще нет в стандартном пакете VERICUT, попа пляшет =)

Ссылка на сообщение
Поделиться на других сайтах
В 07.03.2019 в 09:17, s_liam сказал:

Кидайте проект. Можете в личку ссылку прислать на скачивание. Сделаю, думаю что.

Отправил в ЛС.

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

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

Автоматически, получается, в данный момент это дело не расставить.

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

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

Хотя, может и верное описание макро.

Сейчас еще поглядел.

Переменная системная CurToolindex равняется порядковому номеру в библиотеке инструмента.

Надо подумать, как сделать так, чтобы все было как нужно.

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

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

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

Я предлагаю Вам следующее решение.

В файл подпрограмм станка dixi_dhp80.spf в самый конец добавляете следующее:

 

PROC D_SPEC
$TC_DP3[CurrentToolNum,$P_TOOL] = $P_TOOLL[1]
RET

 

В стойку в регистр D добавляете вызов подпрограммы D_SPEC (смотри картинку).

После вызова активного корректора произойдет вызов подпрограммы, в которой параметр $TC_DP3 с индексом активного номера инструмента и номером активного корректора станет равным длине этого инструмента.

 

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



2019-03-11_153436.PNG

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

$TC_DP3[CurrentToolNum,$P_TOOL] = $P_TOOLL[1]

Я уже думал о таком, но Vericut ругается на попытку переопределения таким образом этих сименсовских параметров среди макросов в G-code processing. ("Error: Invalid array index for variable $TC_DP3").

А, вот, запихнуть это в spf стойки, как процедуру, я не сообразил. Теперь буду знать, что так тоже можно.

 

Да, конечно же, этот вариант работает.

@s_liam, Спасибо!! :clapping:

 

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

Да, тут вся сложность в том, что переменная имеет два адреса. И нужно каким-то образом их предопределить. Самый простой - взять активный ID адрес инструмента и корректора. Я сначала хотел предопределить это сразу в подпрограмме L300 после M106 - внутренней команды смены инструмента, но здесь еще неактивен корректор D. Поэтому пришлось это перенести в D регистр, после того, как определится номер активного корректора и инструмента, а вместе с этим и текущие значения соответствующих переменных.

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

Нашёл ещё более простое решение - в разделе Substitute просто заменил $TC_DP3[$P_TOOLNO,1] на $P_TOOLL[3], и всё.:biggrin:

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

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

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

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

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

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

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

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

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

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

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




  • Сообщения

    • Anat2015
      Какой станок, какое ЧПУ, какой магазин, и т.д. и т.п.? Задаете вопросы, как будто здесь все экстрасенсы.
    • Fedor
      верхняя линия это если не учитываем давления воздуха, а нижняя если учитываем.  То есть если не учитываем то считаем грунт более прочным чем на самом деле ...  
    • maxx2000
      @asd выводит нормально, с постпроцессором что-то  
    • Orchestra2603
      Это уже больше похоже на конструктивный разговор.   Я это понимаю. Мой тезис заключается в том, что когда мы ищем собственные вектора, мы вообще не решение ищем. Ну, не совсем решение, если хотите. В терминах СЛАУ можно сказать, что мы ищем базисные вектора фундаментальной системы решений. Нам не нужно что-то фиксировать и вводить какие-то точки отсчета. Нам нужно установить все пространство возможных решений однородной системы целиком, и потом из него просто выделить некоторый базис. Это не то же самое, что найти решение СЛАУ.   Про факторизацию... В моем понимании факторизация (в частоности, матрицы) - это разложение на множители (здесь на матричные множители), так чтобы получились какие-то другие матрицы, которые обладают какими-то выгодными свойствами (разложение Холецкого для положительно определенных матриц, LU, QR, QZ, сингулярное разложение и т.д.) В моем понимании это обычно нужно для повышении эффективности последующих операций, ускорения работы алгоритмов, для лучшей сходимости итерационных методов, где-то для эффективной параллелизации и т.д. Ничего не слышал раньше о ситуациях, когда факторизация жизненно необходима, и без нее задача не решается. Как я это вижу, существует много различных способов факторизации матрицы. Я просто не могу понять про какую конкретно факторизацию вы говорите и не могу понять, как она должна помочь, и почему ее невозможно сделать для вырожденной матрицы? Я бы, честно говорю, хотел разобраться в этом. Возможно, я что-то вообще неправильно понимаю.
    • asd
      Надеюсь, это то, что вы имели в виду.   TOOL PATH/THREAD_MILLING_1_COPY,TOOL,STD_DRILL TLDATA/TCUTTER,10.0000,0.0000,0.0000,80.0000,10.0000,8.0000 MSYS/0.0000,0.0000,0.0000,1.0000000,0.0000000,0.0000000,0.0000000,1.0000000,0.0000000 $$ centerline data PAINT/PATH PAINT/FEED PAINT/SPEED,10 PAINT/COLOR,186 FROM/0.0000,0.0000,50.0000,0.0000000,0.0000000,1.0000000 LOAD/TOOL,1 RAPID GOTO/0.0000,0.0000,3.0000 PAINT/COLOR,181 FEDRAT/MMPM,500.0000 GOTO/0.0000,0.0000,-33.0211 PAINT/COLOR,6 FEDRAT/250.0000 GOTO/21.6792,-1.2470,-33.0211 CIRCLE/21.7509,0.0000,-33.0000,0.0000000,0.0000000,-1.0000000,1.2491,0.0100,0.5000,10.0000,0.0000 GOTO/23.0000,0.0000,-33.0000 PAINT/COLOR,31 CIRCLE/0.0000,0.0000,-4.5000,0.0000000,0.0000000,-1.0000000,23.0000,0.0100,0.5000,10.0000,0.0000,TIMES,19 GOTO/23.0000,0.0000,-4.5000 PAINT/COLOR,1 CIRCLE/21.7509,0.0000,-4.4789,0.0000000,0.0000000,-1.0000000,1.2491,0.0100,0.5000,10.0000,0.0000 GOTO/21.6792,1.2470,-4.4789 GOTO/0.0000,0.0000,-4.4789 PAINT/COLOR,103 RAPID GOTO/0.0000,0.0000,50.0000 PAINT/FEED,NOMORE PAINT/SPEED,10 PAINT/TOOL,NOMORE END-OF-PATH  
    • gudstartup
      @Aiche если у вас осталасть на столе привязанная деталь  то можете выставить нули так чтобы значения совпали и ничего снимать не придется к тому же от того что вы снимите ничего не поменяется ведь под кожухами у вас нет никаких 0 меток ни направляющих ни на станине очень неприятные. надо было оставить режим принудительного обнуления @Aiche и срочно сделайте нормальный бэкап в вашем кроме программ ничего нет. хотябы копию памяти надо иметь а то может и в чпу батарейка сесть и тогда будет очень плохо
    • Fedor
      То есть грунт физически находится в сжатом состоянии на поверхности земли. И при вычислении связности грунта логично бы учесть это при построении предельного графика сигма - тау... 
    • maxx2000
    • gudstartup
      нет ранее абсолютные можно было обнулять в любом месте и не надо было никуда ехать а сейчасбывает что система выдает ошибку о невозможности установить 0 пока не сделаешь оборот датчика. особенно это достает при обнулении рев.головки приходится датчик снимать и крутить
    • nicomed
      @alek77 Если еще интересно, то вот код, который рисует два сегмента эскиза поверх выбранной кромки. Первый сегмент от начальной точки кромки до точки выбора, второй сегмент - от конечной точки выбранной кромки до точки выбора. При этом учитывается: положение компонента в сборке; поворот чертежного вида относительно пространства модели. Код как обычно - лишь бы работало - все в одном методе.   Вот что не пробовал, так это многоуровневые сборки. Боюсь что бы не приходилось делать  пересчет положения выбранного компонента столько раз, на каком уровне вложения находится выбранный компонент.   Upd: Нашел глюк (точнее свою недоработку с которой еще предстоит разбираться) - если вид с разрывом - то точка выбора смещается ...
×
×
  • Создать...