Call variables from another tool

[David_Lelen01]

Is it possible to call variables in the post from a tool other than the active tool?

I am setting up a post for our laser now and the only way i can figure to make this work easily is to use a different tool for each different material. I have a tool set for each different thickness material with custom parameters like power, frequency, duty cycle, feed rate, gas type, nozzle size, pierce dwell, etc. I really need a material table separate from the tool table, but just using the tool table works... until i need to etch something before i make a cut.

The etch tool always uses the same parameters regardless of material. Problem here is, my post initializes the machine with the parameters from the first tool called. When this tool is the etching tool, all the parameters to cut the material later are wrong and cannot be reset.

I see in the documentation that there is a variable "tool" which is the current tool number and "nextTool" which is the next tool to be called. Is it possible to call a variable from the next tool? something like post.NonModalNumber("M134 P", tool21.power, "0000")

Thanks,
David

[Les Newell]

Unfortunately not. It should be possible to get the standard values such as feed rate, pierce delay etc but not custom values defined in the post.

[David_Lelen01]

Ok. Perhaps something to consider adding in the future, though its probably not worth the development. What i am doing is likely a very limited application of SheetCAM.

As a work-around, i created a post variable that tells the post if the operation is an etch or cut. Just requires an additional step in the operations sequence, but no big deal at all.

[Les Newell]

Can you use the plate marker tool for the scriber? You can detect the tool is a scriber like this:

Code: Select all

if toolClass == "ScriberTool" then
end

You can also add parameters in the same way as for other tools.

[David_Lelen01]

I dont believe i can because the scriber is another tool. I am using the tools as a material database instead of as actual tools. That is why i was saying it would be beneficial to have a separate material database with customizable parameters just like the tool database.

The way our machine (Mitsubushi ML3015ex plus) works is there are numerous cutting conditions. There is a separate file for each material thickness and gas and nozzle configuration. These files have 11 separate cutting conditions detailing power, frequency, feed rate, etc. One of the 11 is the pierce condition and another is the etch condition. the other 9 are cutting conditions.

[Les Newell]

There are a few options.
Instead if using the normal functions to write to the post file (post.Text, post.ModalNumber etc) you could stuff everything in a text string. Append each line to the string. When you hit the tool with the settings, stick that data at the start of the string. It's a bit ugly and you lose the useful functionality of ModalNumber etc.

Another option is to use a two-pass technique. Keep most of your post as-is but don't output the tool information in OnToolChange. Now in OnFileClosed() read in the contents of the file, add the settings and write it out again. Take a look at the Biesse Rover XNC post for an example of that trick.

[David_Lelen01]

I am not fully comprehending what is going on in that post right now. It seems to be a little over my head for the time being. I do not see what exactly is being replaced and what it is being replaced with. Perhaps i can just generate some gcode and figure it out, but that will have to wait for another day with more free time.

The set post variables method i came up with seems to be working well for now. Hopefully i can revisit this soon though.

[Les Newell]

The biesse Rover XNC controller uses a bastardized version of g-code where some values at the start of the file need to point to the byte offsets of parts of the g-code. These values can only be known once the file has been created. The Italians are experts at mangling g-code and this horrible mess is a prime example.

In that post take a look at OnFileClosed(). It reads the g-code file into a string. It then plays around with that string to replace dummy values with the actual values then writes it back out.

In your case you could write the post to only output the stuff after the tool configuration data. Then in OnFileclosed you could read the g-code file in, add your settings to the start of the string and write it back out. Lua is a general purpose programming language so at this point you are just doing normal string manipulation.

[David_Lelen01]

Ahhh, i see now. That makes a little more sense. I was trying to picture what was being written without actually writing a code and it did appear to be a jumbled mess. Ill take a closer look later this week. Thank you Les