Silly behaviour maybe? return to last tool position too helpful

[johnharvey]

So after a tool change, MASSO decides going to the last known position before a Tx M6 command is normal?

I wonder if this is trying to be too helpful?

On any given g-code following a tool change, the code will 99.9999% of the time have the next needed XY position for that next operation. Which may or may not be where it last left off, unless perhaps it was one drilled hole then a C-Bore bit.

So in my case say, I just finished milling a large sheet of material ending at Y 1000mm X 2500mm, then a tool change to a drill a single hole. Z pops up, moves to the predefined change position (X200 Y300), sets new tool offset, the away it goes to Y1000 X2500, then sees, opp's I need to drill the hole at Y8mm X2mm then all the way back again!

is this the preferred behavior or maybe could be changed? A lot of air cutting time otherwise

j

 

[evermech]

@johnharvey

I find this sort of thing is common in most machine conversational programming setups. It's not so bad if you are only making a small number of parts and if I am doing multiples I just manually edit those moves out to save some machine time. I often edit feeds and speeds and such this way also. I think it's important for everyone to remember that we are running our machinery, the machinery is not running us no matter how we get the Gcode on there



Guy

 

[breezy]

Quote from johnharvey on December 13, 2019, 11:11 pm

So after a tool change, MASSO decides going to the last known position before a Tx M6 command is normal?

I wonder if this is trying to be too helpful?

is this the preferred behavior or maybe could be changed? A lot of air cutting time otherwise ?

John,

Think of it this way. MASSO reads one line at a time and processes it

• So it completes the last commanded move
  
• Reads next line - its a tool change command
  
• OK stop reading Gcode
  
• Goto tool change routine
  
• Tool change routine does the tool change & tool measure
  
• Return to where it was - as part of the tool change
  
• Read next line of code
  
• Move to new location.
  

When MASSO goes into the tool change routine it moves its current variables into temp memory and loads the tool change position into its working memory and moves to that location, etc until it gets to the end of the routine, returns the working variables from temp memory and continues from that point. This is standard computer code processing.

So as Guy said if you want to stop MASSO travelling all over your work table because of a tool change, you need to modify the g-Code to move to next cut position and then have the tool change command, that way MASSO moves into the next cut after the tool measure.

Regards,

Arie.

 

[johnharvey]

Arie,

all my other machines do not behave like this. To go in and manually edit a potentially significant number of lines of code to do as you suggest is a new time killer and rife for introducing error. That is not something one could easily modify their post to accomplish by itself.

So based on your description of the logic flow, I suggested this change

• So it completes the last commanded move
  
• Reads next line - its a tool change command
  
• OK stop reading Gcode
  
• Goto tool change routine
  
• Tool change routine does the tool change & tool measure
  
• Return to where it was - as part of the tool change remove this from the logic of the tool change, it is not helpful
  
  
• Read next line of code
  
• Move to new location.
  

simple really. I don't know of any other controller that does this. If it needs to be back where it was prior to the tool change it will already be in the posted code after the tool change call anyway.

It should be,

1. read tool change
   
2. run tool change routine (with no extraneous unproductive moves after measuring)
   
3. execute next line of code
   

So maybe MASSO should add in a little standard programming such as "dump current XY variable" or "issue new XY variable form tool change position" as the replacement for the XY prior to the tool change call. It really needs to be done.



j

 

[breezy]

John,

I agree that returning to the previous position after a tool change is a redundant move.

In my previous post I was listing MASSO's logic as I had observed it. I don't know or understand the reasoning behind that.

The first time I used a tool change in a program I was surprised to see it return to the previous location when expecting it to start at the location for the new tool that had just been inserted. And even now after using MASSO for several months it still catches me out.

Regards,

Arie.

 

[cncnutz]

I understand what you are saying but what happens if someone writes their Gcode efficiently and moves to where the next tool is needed and then changes the tool?

Instead of moving back to that original position and drilling the hole it picks up the next X & Y location it finds in the Gcode and starts drilling holes there. Because people write their Gcode using various methods by hand, various CAM software packages using different post processors etc there is no guaranteed standard Gcode that Masso will receive. As a manufacture of a product do you write your logic to ensure it works every time or just sometimes?

The way it is now ensures that there will no ruined machined parts or broken tools no matter how you write your Gcode and if users want to write their Gcode for more efficient machining they can do so.

Maybe modifying the post processor to be more efficient would be the way to go.

Cheers

Peter

 

[johnharvey]

Hey Peter, love your videos,

To keep it short, this is just not industry standard for the reasons described.

Quote from CNCnutz on December 15, 2019, 1:15 am

I understand what you are saying but what happens if someone writes their Gcode efficiently and moves to where the next tool is needed and then changes the tool?

Instead of moving back to that original position and drilling the hole it picks up the next X & Y location it finds in the Gcode and starts drilling holes there. Because people write their Gcode using various methods by hand, various CAM software packages using different post processors etc there is no guaranteed standard Gcode that Masso will receive. As a manufacture of a product do you write your logic to ensure it works every time or just sometimes?

The way it is now ensures that there will no ruined machined parts or broken tools no matter how you write your Gcode and if users want to write their Gcode for more efficient machining they can do so.

I would expect the vast majority of people that have a CNC will leverage a CAM and POST to use it. As such the POST will always take care of the next tools XY position. (I've never seen one "not do this") If a hand coded program fails and crashes, well that's the writers responsibility, not MASSO's, or FANUC's etc.

I think the example is one that is not really plausible in the real world of machining. Unless one is a bad hand programmer of course.

Maybe modifying the post processor to be more efficient would be the way to go.

I disagree, editing a POST file is a daunting task and not for the faint of heart. Nor have I ever run across a POST option to have it take the next tools XY coordinate and pre-write it before the next tool call. Even this is not efficient because MASSO would be making a stop along the way to the tool change position.

The most efficient way of handling this is to let the user "option out" of this feature to avoid "cutting air" and let their POST do the work they paid for it to do. $$$

If I have a part with many features, roughing, finishing, boring, drilling, etc, I can confidently say the next tool would never share the previous tools prior XY position before the tool change call, and even if it did, the POST will send it there.

On the other hand, as it is now, everyone is forced to watch the machine traverse to a position that is 99.99999999% of the time never going to be the exact same XY coordinate for the next tool to start, only then to watch it traverse back to where it should have been from the beginning. Time waste / money loser.

So in a manufacturing environment where time is money, IE retrofits in shops out there, this is non-standard practice and can add up to a lot of lost productivity.

With the ability to "opt out" of this feature in the Tool Change settings for professionals it would make MASSO more readily adoptable by reflecting current industry practice. This is just one issue.



Cheers,

j