Edit tormach post to include a tool call whether it has the same tool or not.

[Anonymous]

I have a couple tools that use the same tool number, but not the same tool offset. If I use them consecutively I don't get a tool call in the next operation so the new tool offset does not become active. They are set as Tool 7 offset 7, Tool 7 offset 20, Tool 7 offset 21, in the tool library.

I want to know how I would go about making the tool calls be forced for every operation. Right now I am manually putting them in, in the editor before loading at the machine, but I would like this to be automated so its not forgotten in the future.

thanks! 

[SpammersDeserveDeath · Accepted solution]

If you have the same post as the one I just downloaded from here...

http://cam.autodesk.com/posts/

... there is a section that looks like this...

  var insertToolCall = isFirstSection() ||
    currentSection.getForceToolChange && currentSection.getForceToolChange() ||
    (tool.number != getPreviousSection().getTool().number);

It is probably immediately after the line that says this "function onSection() {".

This line makes "insertToolCall" "true" if any of the conditions listed are true. You can override this by making "insertToolCall" always true by adding this line below it...

  insertToolCall = true;

This way, when the post processor is checking whether insertToolCall is true or not, it'll always be true. I believe making this change will have the effect you want, but I'm not totally sure (prehaps it'll change other things too, but I doubt it). Look over the output as well as you can before running it.

You could also add a comment to the line so that it's easier to remember why you made the change. Adding your name (or something) makes edits easier to find. So, the line you add would be slightly better if it looked like this...

  insertToolCall = true; // edit 2018/02/15 - override the line(s) above to make insertToolCall always true

When you're done, the beginning part of the "onSection" could look like this...

function onSection() {
  var insertToolCall = isFirstSection() ||
    currentSection.getForceToolChange && currentSection.getForceToolChange() ||
    (tool.number != getPreviousSection().getTool().number);

  insertToolCall = true; // edit 2018/02/15 - override the line(s) above to make insertToolCall always true

 Remember to test. Good luck!

[Anonymous]

First- Thanks! that was a huge help. 

That did exactly what I was hoping but it did add a couple unwanted things that I'm hoping I can get rid of.

1. On the stock post (I downloaded the lastest from the HSM post library yesterday for the start of this) It posts the approach with the Z move first then the X. Its now flipped. 

2. It outputs an M0 at the start of every op before the tool call

3. It outputs an M5 at the end of every op. 

2&3 are fixable with a find and replace and not detrimental if forgotten but I can see scenarios where 1. could potentially cause issues. Anyone have any thoughts on what could change these?

Im including a screen shot of the output for the XZ swap and also my post that Im editing. You can find the insert tool line by searching JMS

[SpammersDeserveDeath]

I'm glad that you caught the other changes that were being made. Who would have thought that variable would change so many things?

Phew, that is one complicated post! (at least for an amateur like me)

OK, I've looked at it much harder, and I'm thinking changing a line in the following section...

  if (properties.sequenceNumberOperation) {
    showSequenceNumberNext = true;
  }

  if (insertToolCall) {
    if (!retracted) {
      goHomeZ();
      retracted = true;
    }

    if (tool.number > 99) {

... so that it matches the following...

  if (properties.sequenceNumberOperation) {
    showSequenceNumberNext = true;
  }

//  if (insertToolCall) {
  if (1==1) { // 2018/02/17 - above line commented out and replaced so this section is always executed
    if (!retracted) {
      goHomeZ();
      retracted = true;
    }

    if (tool.number > 99) {

... is probably a better way to force the tool change every time. If it were me, I'd remove the first change and try this new one.

It looks, to me, like this is the section that writes the tool change. Before this stuff is ran it checks if "insertToolCall" is "true" first. This change removes that check and replaces it with "does 1 equal 1", so that section should always be run. (Unless something higher up is stopping it or something...) Unfortunately, I don't currently have a way to test a turning post so I can't check it myself.

Though, I suppose having an M0 before and an M5 after every op, when it also thinks the tool is being changed for every op, makes sense. If this change doesn't work (or effects more than we bargained for) maybe the next step would be to make the post check the tool offset at the start of each operation and make a tool call if it finds that it has changed. That would probably work even better. I've been staring at my own post for too long today already, but I'm thinking this would be entirely possible. If this change here doesn't do what you want, lemme know and I'll take one more stab at it. 🙂

In the attached image the proposed change is highlighted in pink. Also, in blue is one of the only instances of "M0" output that I could find. Commenting that line out might stop the there are too many M0s problem, but it might also make a new there aren't enough M0s problem!

[Anonymous]

Alright. That actually worked quite well. 

  if (properties.sequenceNumberOperation) {
    showSequenceNumberNext = true;
  }

  //if (insertToolCall) { JMS
  if (1==1) { // 2018/02/17 - above line commented out and replaced so this section is always executed JMS  
    if (!retracted) {
      goHomeZ();
      retracted = true;
    }

    if (tool.number > 99) {
      warning(localize("Tool number exceeds maximum value."));
    }
    
    if ((toolingData.tooling == QCTP) || tool.getManualToolChange()) {
      var comment = formatComment1(localize("CHANGE TO T") + tool.number + " " + localize("ON") + " " +
        localize((toolingData.toolPost == REAR) ? "REAR TOOL POST" : "FRONT TOOL POST"));
      //writeBlock(mFormat.format(0), comment);
    }

commenting the M0 Line worked for removing the tool call M0's and that doesnt seem to be negatively affecting anything else.

The tool call is now outputting the XZ coordinates on the same line, which I actually think is preferable to flip flopping the calls like it was doing before, But I still think that its interesting the tool call should be affecting the coordinate output in anyway. Is there a way to tag the autodesk guys to see if there is anything they should know about in this?