I do not have the Z-Axis motor and I just upgraded to the latest Firmware/GroundControl. Before I would get popups after each router round prompting me to adjust the Z axis. The newer version, V.083, does not provide those prompts, just plows ahead. Is there a setting I missed to enable these pop-ups?
Thanks
That sounds like an issue for sure! Let me look into it!
This isnāt the first time a weekly update has broken this functionality. May I
suggest that you build a second machine, say a tiny 2x3 machine with a pen
instead of a router (possibly even with triangular kinematics) and have an
accuracy/functionality test that you run on it each week (say a horizontal
zig-zag pattern, then lift the pen and move to another corner, lower the pen,
and do a vertical zig-zag). Such a machine is always useful for doing drafting
layouts or paper signs, even without a powered Z
FYI, I did find the switch on the settings panel for the Z axis. On or Off the same result for me.
I was able to replicate the problem pretty easily, and I think Iāve got it tracked down and fixed.
If you are comfortable with continuing to use 0.82 until 0.84 comes out one Wednesday that will work, or if you want to give the very latest a try, you can download it using the green Clone or download button in the upper right hand corner of https://github.com/MaslowCNC/Firmware
If you do download the firmware from there, I would love to be sure that it fixes the issue.
Thanks for the heads up about the problem!
I think @dlang is right that we do have an issue with new releases breaking old features, but Iām not 100% sure more manual testing is the solution. I feel like I have so little time, and there are soooo many things to test that it would take a whole day each week just to be sure the release has no bugs. I tried playing with an automated testing system like CircleCI, but because hardware is a factor itās tough. Iām hoping soon we can stop adding so many new features and move to a release every two weeks or even every month. That way I can dedicate multiple days to testing each new version.
Iāve said it before, but I really think we need a āRecommendedā and a āLatestā branch. I donāt want to run cutting edge, I just want a version where all the current features work. Different people will be attracted to download each of the files, the latest branch will still have plenty of people wanting to test out the latest and greatest.
Definitely a Current Stable version option would be very useful for those that just want it to run as smoothly as possible with minimal tinkering. Which will end up being the majority at some point.
Iāve downloaded the version that @bar linked to and run a simple file through it. It correctly prompts for z axis change if the setting is off and works correctly in automatic mode as well. It also correctly responds to a macro of āB03 I0ā or B03 I1ā and will change the behaviour in rewsponse to those codes in the body of a cut file as well - a poor manās tools change 
.
It is not based on the branch which operates the z axis during a move. If a line contains a z value as well as an x or y value, it prompts for the z change or runs the z motor before advancing the sled.
The shape was a simple 3" square, plotted at 15ipm with a .4mm pen as the bit. It plotted to within .2mm in both the x and y directions and the lines were smooth, the corners square.
More people should test this, it looks like a good candidate for āCurrent Stableā to me 
FWIW, here is the code I ran to exercise the z axis. It will prompt for a z change at the penultimate step whether the machine has a z motor or not.
G90
G20
G0 Z-0.1 F10
G1 X3.0 Y0.0 F15
G1 Z-0.15
G1 X3.0 Y3.0 Z-0.05
G1 Z-0.1
G1 X0 Y3.0
G1 Z-0.2
G1 X0 Y0
B03 I 0
G0 Z0
B03 I 1
G0 Z0.1
Can you write this cut file to run in a 450mm square? I can run it with a .4mm pen and report the results.
I think @dlang is right that we do have an issue with new releases breaking old features, but Iām not 100% sure more manual testing is the solution.
with hardware involved, manual testing is unavoidable. The key is to plan out a
test plan that tests as many different things in one run as possible so that you
do as few manual runs as you can get away with.
Having multiple machines, some of which are much more limited than the full
machine, but are enough to perform specific tests can help.
I feel like I have so little time, and there are soooo many things to test
that it would take a whole day each week just to be sure the release has no
bugs.
What many software projects do is to have a āmerge windowā for changes that
occupies part of the release cycle, after that window, only bugfixes/reversions
are accepted, any further improvemetns must wait for the next cycle.
In our case, I would suggest that the merge window open on Wednesday[1] when you
cut a release, and close Saturday morninng. This would mean that as of Saturday
morning, the version in Git is expected to be the version that will be released
the following Wednesday. People can then test this version over the weekend and
report problems. Meanwhile, people can experiment and develop on different
branches to produce PRs, but the PRs will not be merged until after the next
release is cut (unless they are fixes to problems discovered in testing)
This lets everyone else perform tests so you donāt have to do them all 
I tried playing with an automated testing system like CircleCI, but because
hardware is a factor itās tough.
Yep, most of the real problems we are having are hardware related and automated
testing in simulations would not catch them.
Iām hoping soon we can stop adding so many new features and move to a release
every two weeks or even every month. That way I can dedicate multiple days to
testing each new version.
I donāt I hope the development speed stays high
David Lang
[1] with this sort of testing, it make make sense to move the release day up to
Monday or Tuesday to give a little more time for adding things. But since we are
almost all hobbiests, having a release candidate available for testing over the
weekend is valuable
Thank you Bar for the quick response. I agree that having a test suite to verify operation is a grand idea. Before bringing someone else in on the software development or blessing contributed updates you should have a test suite. Actually, the whole test suite would be a great job for an intern.
Like the rest of us, you are constrained by time and money. I would suggest a more practical approach.
I would rather see updates that are the result of your investment in building your passion, the homeless shelter. This will further all of our goals as your motivation to fix issues will be unstoppable. I would rather have someone with their heart in the project leading the effort.
