My guess is that Masso lost its lead (sole) developer at some point and has had us all sitting tight for the past year. I can't think of another plausible explanation.
My gut feeling is the founder would have been dragged into help sort out the cutter compensation. Two years ago I posted the following with respect to cutter compensation:
Can you pass on my deepest sympathies to the unfortunate developer who is tasked with implementing cutter compensation. There are a couple of corner cases (no pun intended) which are technically infeasible to implement. Specifically the case for a concave G02/G03 move where the arc radius is smaller than the tool offset as this results in a negative cutter movement radius.
Is it likely that tool nose radius compensation will be introduced in the foreseeable future? I'm referring to G40, G41, G42.
forums.masso.com.au
Further down in the same thread:
If you read through the documentation for cutter compensation there is a number of quirks out there with the different vendors. One of descriptions of cutter compensation mentioned "undesired gouging".
This linear move must be longer than the offset amount, if it is not there will be an error. Also, if there are any segments of the tool path shorter than the offset amount a gouge is likely, see figure 31.
From a previous post from
@breezy , it sounded like they needed to rewrite the main motion control engine of the firmware. That is not a trivial task as this handles the delicate task of sending step pulses to the axis motors in a carefully choreographed fashion to get the cutter to dance around the work piece.
As a spectator I suspect that as MASSO sold more controllers (probably exploded with the MASSO Touch) that the support load increased dramatically. This would a driving force for "stability" over "new features", this leads to the need for increased testing of the code before it is released upon the world. I have seen a software development group reach a point where they were spending 90% of their time testing and 10% of their time implementing new code. That group is now running about 60% testing / 40% new coding due to automated test suites. This is a potential bottleneck that MASSO could have run into or may have already be ahead of the curve - I just don't know.
Is this a conversation we want to do in public?
You might see in the next newsletter an article about the lengths MASSO goes to ensure their software is robust and error free as possible. Never underestimate marketing's ability to turn a negative into a positive.
I am an engineer who wrote software for 40 years for a jet engine manufacture. Primarily GUI based plugins for CAD packages such as UG-NX.
Internal software development or software for external paying customers?
One results in a colleague tapping you on the shoulder with the comment "something is really odd with the latest version", the other requires you to decipher cryptic e-mails and incomplete logs (sometimes it is not what is in a log file but what isn't there...).
I have done my share of "Internal software development" but I had a software product manager sell one of my tools to an external customer and then came asking for the source code to "productise" the tool.
Case in point look up "United Airlines Flight 232" ... that one hurt real bad, but you don't know what you don't know.
If you had said "Sioux City crash" I would of recognized the event. That should of been a "no survivors event" but due "factors beyond human understanding" (hand of god?) half the people survived. Probable cause(s) -
shakes head in disbelief [vintage "safety swiss cheese"]