Any new beta updates?

CandL

Member
The chemical process simulation software I use at the day job the build numbers increments by 1000 for major releases, customers who use it for designing chemical processes use build numbers like 17003, while the version used for the software for building operator training simulators has an offset of 500 (17507). The release of builds between the design software group and the training simulator group are otherwise independent.

The numbering convention makes it easy for the support people to know what variant you are using at a glance rather than trying to memorise which of the builds is a stable build. At the end of a major release everything is merged back into one master software code base before starting a new major release.

One of the challenges that MASSO could potentially face is regression testing of the software.
Regression testing is perform checks that stuff that used to work in the old version still works in the latest release. There are software packages to assist with that in the Windows world but what do you do for an embedded system?
Is the regression testing question a serious or rhetorical question?
 

zombieengineer

ZombieEngineer
@CandL - serious question.

Over the last 5 years I have seen MASSO "streamline" the available software offerings such that there is only really 2 different software images for each release.

Previously there were additional (paid) options for:
  • Wireless connectivity (G2 era)
  • Touch screen
  • Plasma (merged into the mill configuration)
  • USB Scanner (for selecting jobs)
  • Multi-spindle
  • 3 / 4 / 5 axis configuration (now everyone has 5 axis)
This merging of optional features into the base product is something I see as products matures. The "stable" and "beta / development" branch is also another sign that the software development process is maturing (down side is new features take longer to be added to the product but the "stable" version will just work).

If you start going the path of quality (such as ISO 9001, for software development there are other standards) there are three things that need to be done:
  • Document your work flow (processes and procedures)
  • Keep documented evidence that you are following your documented processes and procedures
  • Have some process of continuous quality improvement
The question then is how do you prove (provide documented evidence) that a stable release does not have any significant software bugs?
For Windows applications there are software tools that replicate keyboard and mouse actions and the final output can be compared against a reference case (for example open a file, make some edits, save file under a new name, compare result).

With a CNC system the keyboard / mouse are a little more difficult to emulate (not impossible but can be done), but there is a material component to the testing that would be consumed with every test run (perhaps MASSO has a couple hundred kilos of engineering wax which can be melted down and recast for the next test run).


If you were MASSO, how would you test a new software release to ensure that there was no unintended side effects due to a software change?
 

breezy

Moderator
If you were MASSO, how would you test a new software release to ensure that there was no unintended side effects due to a software change?
Lots of testing of small alpha software changes/additions, before combining them into a large alpha then a beta for wider range testing.
Even today a new bug was found in v5.100b when it was used in plasma mode.
Over the last 5 years I have seen MASSO "streamline" the available software offerings such that there is only really 2 different software images for each release.
Previously there were additional (paid) options for:
Part of the reason those options were dropped was that it was time consuming to maintaining the different versions dependant on what was paid for and also storage on the servers was being consumed keeping more than two versions for each controller.
 

CandL

Member
Is this a conversation we want to do in public? 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. I also just worked on the Masso post processor for FreeCAD. Let me say that everything has risk associated with it ... as a Mechanical Engineer, I can't guarantee your car will not explode when you turn the key. Case in point look up "United Airlines Flight 232" ... that one hurt real bad, but you don't know what you don't know.
 

Espressomatic

Active member
Is this a conversation we want to do in public?

No one conversing is writing any code for Masso, and this is a public forum?

I didn't mean to start a conversation about software development lifecycle management, I was just pointing out that I found it odd, and that in all my life have never seen a final release pushed with a number lower than the beta used for testing its features. We're not talking build numbers, but software release version numbers here. x.n BETA means it's the beta of x.n. When the version is released, it is typically version x.n. There might even be x.n beta2, beta3, etc. and even rc1, rc2, etc. before the final version. Sometimes you bump the release, so it might be x.n+1 (like 5.101 for instance) But going backwards? Just not something I see and for good reason - it's confusing AF. Then again, not having a single beta update in over a year is also strange.

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.
 

CandL

Member
My comments were regarding:
"If you start going the path of quality (such as ISO 9001, for software development there are other standards) there are three things that need to be done:
  • Document your work flow (processes and procedures)
  • Keep documented evidence that you are following your documented processes and procedures
  • Have some process of continuous quality improvement
The question then is how do you prove (provide documented evidence) that a stable release does not have any significant software bugs?
For Windows applications there are software tools that replicate keyboard and mouse actions and the final output can be compared against a reference case (for example open a file, make some edits, save file under a new name, compare result).

With a CNC system the keyboard / mouse are a little more difficult to emulate (not impossible but can be done), but there is a material component to the testing that would be consumed with every test run (perhaps MASSO has a couple hundred kilos of engineering wax which can be melted down and recast for the next test run)."


Some tips I used were:
  • When checking in code for a merge make these requirements:
    • Set up a coding standard with comment requirments included
    • Implement a testing framework, such as google test, catch 2, pytest etc.
      • Code does not enter without a test.
      • You fix a bug a test is created so it does not reappear
    • Do a team meeting/code review to accept the changes ... public embarrassment does wonders, by that I mean showing your work to others, not singling people out for abuse.
  • If possible, create a digital mirror of the device. Yes, this sound daunting but I can pretty much guarantee that every military jet engine has a corresponding digital model. The fact that they can sim the part on the screen, means they are pretty close already.
    • Printing an image to postscript (ASCII) can let you do file diffs without having to look at a picture.
  • Actually, cut chips, burn parts etc.
Yup I use my machine to actually cut chips when I wrote the Masso Post Processor for FreeCAD. I will also say the FreeCAD code review was interesting and quite professional. When you work for the same company for 40 yrs you get isolated.
 

zombieengineer

ZombieEngineer
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.


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"]
 

perry

perry
If you start going the path of quality (such as ISO 9001, for software development there are other standards) there are three things that need to be done:

Fun ISO9001 story: I worked for a software/hardware company in the 90s that got 9001 certification. I was a QA engineer, testing interaction between the hardware and third party applications, as well as our own in-house application that ran on that same hardware. The certification process took months and as a result the quality of the software went down the toilet. The version 3 release of the application had a million bugs that cost customers dearly, drastically increased support calls (and thus our costs on support), and drove a lot of customers to the competitor's products, which were arguably worse, but at least stable.

We literally spent 2/3 of our time making spreadsheets to document what we did, instead of actually testing the software. It was an unmitigated disaster. I quit shortly thereafter.
 

MstrODstr

Member
Fun ISO9001 story: I worked for a software/hardware company in the 90s that got 9001 certification. I was a QA engineer, testing interaction between the hardware and third party applications, as well as our own in-house application that ran on that same hardware. The certification process took months and as a result the quality of the software went down the toilet. The version 3 release of the application had a million bugs that cost customers dearly, drastically increased support calls (and thus our costs on support), and drove a lot of customers to the competitor's products, which were arguably worse, but at least stable.

We literally spent 2/3 of our time making spreadsheets to document what we did, instead of actually testing the software. It was an unmitigated disaster. I quit shortly thereafter.
You're singing the song of every software engineer out there who has worked in the field for more than 20 years...
 

breezy

Moderator
Oh that answers a few questions. Why is it that almost all entrepreneurs that manage to build a successful business seem to struggle with running and growing the business?
You didn't read the newsletter emailed 31st Jan
Because it's really hard to do.
Also starting a business out of your family home, using the living area as the office for 5 staff (Sales), garage as test and goods packing area and a storage unit off site for all incoming goods. When renting or owning a office/warehouse in an Sydney industrial park is expensive, all these need to be considered when growing your business.
 

MstrODstr

Member
You didn't read the newsletter emailed 31st Jan

Also starting a business out of your family home, using the living area as the office for 5 staff (Sales), garage as test and goods packing area and a storage unit off site for all incoming goods. When renting or owning a office/warehouse in an Sydney industrial park is expensive, all these need to be considered when growing your business.
I have worked with and for owners who started a successful business; but, really struggled with growing and running the business (largely due to the success they had in starting the company).

It is GREAT to see the owners have recognized this and brought on someone to focus on just that.

Thanks for the info everyone.
 

breezy

Moderator
So we're looking at hopefully by the end of March. I'm wondering who's been testing any fixes against problems reported with 5.100b over the past year? Have there been betas dropped here on the forum that aren't on the Workshop site?
MASSO's production releases number up from v5.00 and beta up from v5.100b, hence next will be v5.08.
Even I was wrong just released v5.09.
Lots of new features but not everything from v5.100b.
 

zombieengineer

ZombieEngineer
What do we know about the "talking head" (no disrespect but I don't know what to call him) in the last two videos released by MASSO?
Have we seen that person on these forums?

 

breezy

Moderator
Not sure he could be Jason who replaced me in the Support team.
Also check out Peter's plasma video, same plasma video just edited differently.
 
Top