Forum Navigation
Forum breadcrumbs - You are here:ForumForums: Tool ChangersUmbrella Tool Changer
You need to log in to create posts and topics.

Umbrella Tool Changer

done.  Thanks.

I e-mailed support about this 5 days ago and still haven't received the configured code.  The tool changer is advertised in the documentation as working.  There is no mention of it being an untested or alpha/beta test item.  Does anyone have a setup where the Masso recognizes the correct number of slots?  Is there anything I can do on my end to get this working?

as there had been so much communication going on regarding your spindle index pulse issue from the encoder, we could not proceed before the proper I/O signals could be established. anyways, we have emailed you the new updated logic as per your new VFD indexing/locking signals, please try the software and let us know.

Awesome.  Thanks!  I am sending over another video of some initial testing.  One thing we are seeing that I think would be useful for customers is some odd timing issues with the tool count and the home sensor.  On our system these don't occur at the same time so various scenarios around homing and advancing to the current tool result in getting to the wrong position.  Our system uses magnetic proximity switches for these sensors so we have adjusted when and where the tool count is read, but now the same problem occurs just at a different place in the process.  The controller reads the home switch just fine, but the tool count switch is phased behind the home switch and the system thinks it advanced a tool when in fact it did not.  Maybe a setting could be added to recognize a leading or trailing tool count switch?  Are other systems configured with perfectly in sync tool changer switches?  I was trying to work through how other users may avoid this issue.

can you please try inverting the tool count input on MASSO as that might fix the issue.

@jonunder were you able to try the new software on the machine?

Hello.  I was able to test again today with the counter signal inverted and had the same issue.  If we are at tool 1 and home the machine, the tool changer counts to home and then attempts to advance 1 tool, but it doesn't recognize that the tool count hasn't tripped past the home switch.  Therefore it reads a count and doesn't actually advance.  I am e-mailing over a video I recorded last Friday detailing a lot of this.  Because the count switch is a proximity switch, we tried to use a screw instead of the original cam, to shorten the pulse and offset it from the home switch without any luck.  I have tried the inverted signal with both the screw and the original cam setup without luck.

The only other issue I found was the spindle stopping logic which is shown in the video.  If the spindle is running, the spin down delay seems to be ignored and the index timing is very very close to when the umbrella extends.  It would be nice if the spin down and indexing occurred before moving the Z into position.  More importantly, the machine errors out if the spindle is running at the time of the tool change command.  If the spindle is stopped there is no issue which would be easy for us to fix in the post processor but since the documentation claims to stop the spindle and wait for the delay I figured you would want to know.


thanks for the great video and feedback, we have emailed you v3.41.12a with below changes:

  1. Changed logic and now spin down delay is added to the logic.
  2. Now the system first tries to index the spindle and then moves the Z-axis in position, this also gives more time to the system to stop the spindle and index.


Regarding the sensor position question, lets first understand the issue. The main reason for having a geneva mechanism is that when using those cost-effective AC/DC motors which cant stop on the exact position, mechanically the geneva mechanism provides some room for the positioning of tools as the motor shaft will not always stop at the same position. As can be seen in your video the motor stops sometimes in front of the sensor and other times miss it, again this can be due to a lot of reasons but one is that if the motor had to only run, lets say for a single sensor pulse while its still picking up speed and gets the signals to stop so it stops in front of the sensor but if the motor has to stop after 10 sensor pulses then the motor has gained more speed and by the time it gets the signal to stop on 10th pulse it will pass the sensor. This explains that sometimes on homing there are no issues as its already so close to the required position.

The problem here is the small pickup point on the shaft, it's very small and by the time motor stops its already passed the sensor and then MASSO takes it as the next pulse. The right way to have the sensor is that the pickup metal part is much larger so that even if the motor takes time to stop then still its in front of the sensors, basically it should never pass the sensor when stopped.

please see the attached diagram and hope we are able to explain the process



Uploaded files:
  • Pickup-Sensor-Diagram.jpg

Hello.  Thanks for the support!  It's evening here so just a quick message here.  I thought I mentioned it in the video I sent but maybe not.  In the video you can see the screw we used in an attempt to shorten the pulse since we don't know what logic the MASSO is running.  Normally, there is a cam that is used for the pulse which is hemispherical, resulting in a long pulse. In the previous comment I mentioned that I tested a non-inverted and an inverted signal with the full hemispherical cam with no luck.  I can take another video with the cam operation and send it over if you would prefer.  As for stopping, the tool changer does stop immediately as I have configured it with the proper braking resistor. So far I haven't had any drift on the motor and I can provide some footage of that too. 


After all of my testing, it seems that the MASSO is only looking at the homing sensor and not watching the pulse count as it homes.  So it seems to just hold the run signal high until home is tripped instead of counting positions and waiting for home to come high while at a tool position.  In our old system we effectively advanced 1 position at a time and waited for home to go high.  In practice it wasn't stopping at each position but was using both the counter and the home simultaneously.  Just my 2 cents!


Thanks in advance!

I checked the logic again and when homing we wait for the home signal to go HIGH, then the system tries to bring the tool into the position that was loaded.

In case if tool 0 was loaded and we home the machine, at this stage the logic thinks that it does not need to move or count pulses after homing, I think this is where the issue is. what are your thoughts?