Allow users to write their own auto tool change logic.

[ohsnapfit]

Now that I think about it, I can use this to solve my issue, which is both my left and right linear type 2 tool changers are mirrored and require an approach from opposite directions. Nice

Getting the current tool isn't the issue. The problem in this case is telling the controller what tool it should be on if I were to write my own tool change logic without using an M06 command, which would attempt to perform a tool change of it's own.

Basically I can write gcode to drop off and pickup a new tool. But currently there is no way to let the controller know the new tool that's been picked up.

Ah

 

[ohsnapfit]

Ah

Pretty sure they are going to tell you no manual tool changes, and all tool changes need to go to a real or dummy location.

Worse, all tool changes need to happen at the same Z height, even dummy ones

 

[ohsnapfit]

If we could use macros, you would take the M6, rename it, delete everything except the command to update controller, and be done. We need macros!

 

[zombieengineer]

Yes - Macros would resolve the issue. The challenge is that macros opens a "Pandora's Box" of issues which includes:

• Ensuring that "restart from line" works correctly as the state of the machine could be unknown due to variables being defined by machine inputs.
• Developing an appropriate parser algorithm to provide enhancements / extensions beyond "industry standard g-code" (any macros you have seen are likely to be vendor specific implementations)

Disclaimer - I do not work for MASSO, however at my day job of simulating chemical processes for operator training I have had to replicate equipment sequences which has significant similarities to the macros required for CNC.

Fundamentally macros are a programming language and there are two different paths to implement this:

• Novice method where you split strings and the code is hand crafted to react to each fragment (also known as a token) as it appears
• Pro method is where you use a tool to take the programming language grammar to generate the code to handle the parsing

The novice method appears to work for simple cases but as additional functionality is added the complexity of the code increases exponentially.

The pro method uses a tool similar to YACC (Yet Another Compiler Compiler) which requires defining the grammar in such a way that there can be no ambiguity (the dreaded "Shift-Shift Reduce" error which means that for a particular sequence of tokens there is at least two different pathways that the code could be interpreted). Once it is working the resulting parser "just works" as any issues are generally nailed during the development checks.

Historically the rule of thumb has been "Writing operating systems is twice as difficult as normal programs, writing compilers is twice as difficult again". The code for MASSO would probably be in the "operating system" level of difficulty (embedded system where the code is effectively the operating system).

Yacc - Wikipedia

en.wikipedia.org

 

[ohsnapfit]

@zombieengineer as always, thank you for dropping some knowledge.
I'll make the case that it's my machine, and my evenings and weekends, and I at least want the opportunity to try, seeing as personal technical growth is a large part of what brings me joy in this adventure and rabbit hole.
Are you aware of anything I can do with the current masso firmware to write a macro it will accept?

In the mean time, off for some light reading on yacc

 

[ohsnapfit]

Also, engineering time isn't cheap. Why wouldn't masso want to enable people around the world to develop additional functionality for their product on their own dime, like the post I just shared for free on another thread today?
Not saying it has any value, but time will tell, maybe it will for someone

 

[zombieengineer]

The YACC stuff is what MASSO potentially needs to implement to support macros. The challenge of "add macro support" is there is likely to be more work than what people initially think (unless you have been there before).

Expecting end users to "code their own" macros is likely to be a difficult ask, I have problems finding engineers who know how to program let alone someone from a trade background.

 

[breezy]

Expecting end users to "code their own" macros is likely to be a difficult ask, I have problems finding engineers who know how to program let alone someone from a trade background.

Which is why MASSO placed MACROs very low on their list of improvements to the G3 software, but things may have changed since I retired from MASSO.

The challenge of "add macro support" is there is likely to be more work than what people initially think

And it is extra work in support of users writing their own macros, where the macro could cause unforeseen problems with the existing G3 software.

 

[ohsnapfit]

Which is why MASSO placed MACROs very low on their list of improvements to the G3 software, but things may have changed since I retired from MASSO.

And it is extra work in support of users writing their own macros, where the macro could cause unforeseen problems with the existing G3 software

I don't expect masso to support my tool paths or posts, why would I expect them to support my macros?

"Expecting end users to "code their own" macros is likely to be a difficult ask, I have problems finding engineers who know how to program let alone someone from a trade background."


Fanuc macro B is used by many many people, so what if not every masso user uses it? The programmer, hobbyist, OEM, or integrator does it once and then the company uses it for years.
Isn't it in Masso's business plan to sell to OEMs, who would have the resources to find the right person if that is what they needed for their business? Their in-house macros are their IP, so long as they can actually push it to the controller.

Or they get shared on the forums by capable people and masso and the whole community benefit, both in experience and profit.

Some people need it to fill in the gaps that haven't been released by masso yet.

Personally, I can't use Masso on the next prototype; what machinist would buy a mill that can't find the center of the stock? Do I tell them to sharpie the side and be careful which way they flip it? What a nightmare the setup sheet would be for production..

 

[breezy]

I don't expect masso to support my tool paths or posts, why would I expect them to support my macros?

But there are users out there who do expect that.

what machinist would buy a mill that can't find the center of the stock?

That was one of the high priorities on the software upgrade TODO list, before I departed. It most likely will be in the next Beta.

Please be aware that this version is one of 2 Beta software versions being worked on at present.
The other version contains new features and will be released after this one has passed the Beta phase.

 

[zombieengineer]

Providing the tool change does not require any axis movement then probably the best solution is to use an Arduino controller (see below for a DIN rail mount version that can be powered by 24V) to perform the tool change and link the Arduino controller back to MASSO.

The advantage of this solution is:

• Ardunino Integrated Development Environment (IDE) provides debugging functionality
• It allows the end user to develop / troubleshoot their own system independently of MASSO
• Can use the IEC 61131-3 Sequential Function Charts (SFC) which are equivalent to flow charts for sequences

The last point is likely to go over the heads of 99.9% of people on this forum. IEC 61131-3 is the standard that covers programming languages for Programmable Logic Controllers (PLC). Sequential Function Charts is the variant language to use for programming sequences, as mentioned before it is basically a flow chart where you drag-and-drop chart elements and link them together to configure a sequence.

Sequential function chart - Wikipedia

en.wikipedia.org

Arduino has a PLC specific IDE:

Arduino PLC IDE | Arduino Documentation

The Arduino solution to program PLC compatible Arduino devices using IEC 61131-3 standard languages (Windows only). Downloadable for free.

docs.arduino.cc

Industrial versions of the Arduino controller are available:

Arduino Opta Lite

Arduino Opta is a secure, easy-to-use micro PLC with Industrial IoT capabilities. Designed in partnership with Finder – leading industrial and building automation device manufacturer – Opta allows professionals to scale up automation projects while leveraging the Arduino ecosystem. Supporting...

store-usa.arduino.cc

 

[tmtoronto]

Providing the tool change does not require any axis movement then probably the best solution is to use an Arduino controller (see below for a DIN rail mount version that can be powered by 24V) to perform the tool change and link the Arduino controller back to MASSO.

The advantage of this solution is:

• Ardunino Integrated Development Environment (IDE) provides debugging functionality
• It allows the end user to develop / troubleshoot their own system independently of MASSO
• Can use the IEC 61131-3 Sequential Function Charts (SFC) which are equivalent to flow charts for sequences

The last point is likely to go over the heads of 99.9% of people on this forum. IEC 61131-3 is the standard that covers programming languages for Programmable Logic Controllers (PLC). Sequential Function Charts is the variant language to use for programming sequences, as mentioned before it is basically a flow chart where you drag-and-drop chart elements and link them together to configure a sequence.

Sequential function chart - Wikipedia

en.wikipedia.org

Arduino has a PLC specific IDE:

Arduino PLC IDE | Arduino Documentation

The Arduino solution to program PLC compatible Arduino devices using IEC 61131-3 standard languages (Windows only). Downloadable for free.

docs.arduino.cc

Industrial versions of the Arduino controller are available:

Arduino Opta Lite

Arduino Opta is a secure, easy-to-use micro PLC with Industrial IoT capabilities. Designed in partnership with Finder – leading industrial and building automation device manufacturer – Opta allows professionals to scale up automation projects while leveraging the Arduino ecosystem. Supporting...

store-usa.arduino.cc

View attachment 6561

Thank you for sharing this. I purchased my first Arduino a few months ago when trying to get a joystick to work with Masso vs my pendant. It was a great learning experience and opened my eyes to the capability of this hardware and software.

I would like to understand the tool change use case you are suggesting this for - I don't have the experience to know what tool changes do not require axes movements. If time permits, could you give an example? I'd like to learn more about this.

 

[zombieengineer]

When I said "doest not require any axis movement" I was referring to the "pick and place" style changers (mill "linear" tool changers).

The Arduino solution would be suitable for umbrella and/or lathe tool changers which are dependent on sensors (proximity / switches) to determine when the correct tool has been rotated into place.

There is a class of lathe tools changers which use a ratchet system, some use stepper motors while others use a DC motor. Once the tool head goes past a sensor it needs to rotate back to lock the tool into place.

Some systems require the spindle to be correctly aligned to perform a tool change (such as the BT series collets which have drive lugs that need to be aligned)

 

[ohsnapfit]

+1 for the opta.

Let's not forget the portenta for those who need more inputs and outputs. The arduino PLC IDE is wonderful, full-fledged, and free.

 

[ohsnapfit]

At present I believe it's possible to use G/M codes to affect a tool change with the exception of telling the controller what the current tool is. Unfortunately the only way I can see is to use the M06 command preceeded by the T#.
T# M06 or M06 T#.

It would be nice to have the ability to perform a tool change using a combination of G/M codes, but be able to tell the controller which tool has been loaded.

At this time I can't auto change my probe since the pick and place configuration could damage the probe due to it's size and how it is built (the force excerted on the probe could break it). I would like the ability to be able to change certain tools using a sliding action while others are configured for a pick and place. I could write code to effectively do this for me after posting with F360. But I have no way of telling the controller which tool is set without running M06 which will attempt to unload the last tool that it knows about and then load the requested tool.

I'm requesting the ability to provide my own tool change logic, with a means to tell the controller which tool in the tool library has just been loaded.

Perhaps it could work like this.

Tool change logic - Custom
1. Call T# M06
2. followed by M98 P# (I can program the previous tool unload based off of the gcode file, since it specifies the previous tool, or perhaps have a way to fetch the previous tool from the tool library?)
3. Sub command handles tool change (using g53 coordinates)
4. Tool change takes affect if controller receives feedback from tool in place sensor or clamped.
5. Otherwise, stop/alarm
6. Tool offset if configured

I'm still working though this but that's the idea.

Unless Masso can provide a way to mix the different tool change configs on a per tool basis.

@kingwoodcraft
Just a thought
1) If you set your probe tool location to a dummy x,y location and M6 to it, you can end up in a state where you have no tool loaded but Masso think the probe is loaded.
2) Run an Auxiliary output in parallel to the output you've defined as your spindle clamp output. Put a diode in series with both of these.
3) Then go and run your subprogram to go an pick up the probe however you want, toggling the air with M63 and the auxilliary output

 

[kingwoodcraft]

@kingwoodcraft
Just a thought
1) If you set your probe tool location to a dummy x,y location and M6 to it, you can end up in a state where you have no tool loaded but Masso think the probe is loaded.
2) Run an Auxiliary output in parallel to the output you've defined as your spindle clamp output. Put a diode in series with both of these.
3) Then go and run your subprogram to go an pick up the probe however you want, toggling the air with M63 and the auxilliary output

Thanks for the suggestion but ideally I'm looking for a turn key solution. I would be ok if we were just given the option to just set the tool via gcode without needing to run M06. I could take care of the rest.

 

[safeairone]

+1 for the opta.

Let's not forget the portenta for those who need more inputs and outputs. The arduino PLC IDE is wonderful, full-fledged, and free.

I don’t want to distract from this topic’s subject, but I would absolutely love it if someone using a PLC for their tool changer made a YouTube video showing their process from start to finish. This thread opened my eyes to PLCs and how easy they are to program using ladder logic.

 

[zombieengineer]

For a video of using ladder logic, see the following for LinuxPLC:

Ladder logic dates back to the dawn of Programable Logic Controllers (PLCs) and the programming of these devices has moved forward since then.

The IEC 61131-3 standard defines the current set of programming methods for PLCs:

• IL - Instruction List (looks like machine code, stay well away from this)
• LD - Ladder Logic (good for simple systems, perhaps tool changers fit here)
• FBD - Function Block Diagrams (Boolean logic diagrams with user definable blocks, this is where >95% of PLC programming is done today)
• SFC - Sequential Function Charts (Flow Chart based diagrams, best suited for complex sequences)
• ST - Structured Text (When you need to write a program in a PLC that needs stuff such as arrays)

Ladder logic is probably fine when you are only dealing with a handful of variables at a time (5 or less is optimal, at 10 variables the complexity starts to overwhelm people). For complex sequences (such as a gas drier having 2 beds online with 1 being regenerated, 15 valves that need to be operated) Ladder Logic is simply truly evil to decipher, FBDs can be made to work for complex sequences but SFCs are designed for that sort of stuff.

The question is probably more of mindset - if you think about a problem from a cause-effect approach then FBD would be recommended approach. If you think about your problem as a series of steps that need to be performed then SFC would the most appropriate method.

Ladder Logic is really only useful for small systems (a tool changer is a relatively small system).

---

For my day job the various PLC programming methods can be collapsed down to Structured Text. I have written a tool to convert the IEC 61131-3 Structured Text into another programming language (FORTRAN - in my defence it was nearly 25 years ago when I did it) and support simulation features (save / restore snapshots of the machine state). Hence why whenever someone asks "can't we just add macro support" I have a fairly good idea of the effort involved (*twitch*).

 

[safeairone]

The question is probably more of mindset - if you think about a problem from a cause-effect approach then FBD would be recommended approach. If you think about your problem as a series of steps that need to be performed then SFC would the most appropriate method.

Been messing around with OpenPLC and an Arduino Uno yesterday; Ladder logic just has a familiar, sensible look to me. FBD is similar to LD in my eye, I just need to be able to decipher the blocks and their connections more quickly. I need just a little more time at the University of YouTube with SFC.

You can keep IL and ST.

Now I really want to make a tool changer of some sort, just to use a PLC!

 

[tmtoronto]

My apologies if I/we should be starting a new thread for this.

I am looking at designing a new automatic dust shoe for my Masso G3 controlled CNC router. I have already have solutions other than removing the dust shoe to a docking station, but would consider this option due to the challenge of adding a dust shoe to my ATC build. I am also interested in designing an automatic coolant nozzle. I am researching using an Arduino - such as the Opta Lite - for these projects. Using a PLC I feel would open up greater possibilities for controlling both of these.

The solutions I have seen shared online are mostly interfacing with software such as Mach.

I wanted to confirm that there is no direct way of getting G/M code, or tool table (tool #/offsets) data etc... from the Masso G3 controller to an Arduino. Right now I can only think of using a configured output, Step/Dir signals for a particular axis, or sensors (as mentioned in discussions above) as inputs to the Arduino.