Z axis stops reporting position on main ground control screen v1.20 - Happens again! -- Firmware Solution?

Software Maslow Firmware
1

I have experienced the same failures again with the Z axis not reporting on ground control when the z axis moves.

I ran an experiment - I turned off the aux pwr supply on the arduino board that powers the motors.

I then tried to jog the sled in x or y - Gorund control immediately stops the action with a warning that the sled is not keeping up and something is wrong.

I then tried to jog the Z axis up or down by a tenth 0.1 in motion. Ground control did not error in any way. It would seem that the position feedback of the Z is different that x and y ??

My original post was that I was losing Z reporting of position change of z in ground control. I thought it was due to my not having compiled the arduino correctly with the latest version of Arduino IDE.

But further testing has revealed that I would lose z track at specific places in certain gcode files.

To counteract this error, I am breaking the gcode into smaller files that are created by cambam for each section of the design. It is interesting that one file has 60 canned cycles of boring holes (8 z moves down to cut at 0.1 in depths and 1 long z move to extract the bit to safety height) and I get no errors in the z reporting even though there are more than 500 z moves - strange.

When I run the outline file (the cuts around the outside of the part) it always errors on the tab z motions after a certain amount of time. It would appear at first look that long segments of x-y motion with z motions up and down for tabs is when it errors most - more strange.

Not sure what is going on - but a fix would be that ground control does a quick check to see that the z axis actually moved the specified amount would be a good fix. When the x and y motions take off when the z is at the wrong depth bad things happen and it ruins the part. If the sled would stop if the z axis fails to change on ground control after the arduino has moved in z, it would prevent the damage to the part. It would require a power down of the arduino board and a reboot of ground control (that’s what it takes to clear the z reporting error) but that is only an inconvenience. The part would be saved and complex parts could be built.

Thanks again for your attention and help in finding a cure for this error that I am experiencing

I am repeating this from the Ground Control forum topic for completeness. Wanted to start a dialogue of possibilities in fixing the Z reporting failures in Arduino code.

2

I am looking at the firmware code and seeing the movement take place in the motion.cpp module at line 74. It starts with:

// why does this return anything
int coordinatedMove(const float& xEnd, const float& yEnd, const float& zEnd, float MMPerMin){

/*The move() function moves the tool in a straight line to the position (xEnd, yEnd) at 
the speed moveSpeed. Movements are correlated so that regardless of the distances moved in each 
direction, the tool moves to the target in a straight line. This function is used by the G00 
and G01 commands. The units at this point should all be in mm or mm per minute*/

This is where it looks at G0 or G1 gcode statements. It then calculates which axis is making a change at line #87:

//find the total distances to move
float  distanceToMoveInMM         = sqrt(  sq(xEnd - xStartingLocation)  +  sq(yEnd - yStartingLocation)  + sq(zEnd - zStartingLocation));
float  xDistanceToMoveInMM        = xEnd - xStartingLocation;
float  yDistanceToMoveInMM        = yEnd - yStartingLocation;
float  zDistanceToMoveInMM        = zEnd - zStartingLocation;

If this is a z only move, then xDistanceToMoveInMM and yDistanceToMoveInMM will be zero.

During the move it will operate on the steps at line # 124 in the while loop

        //write to each axis
        // This section ~180us
        leftAxis.write(aChainLength);
        rightAxis.write(bChainLength);
        if(sysSettings.zAxisAttached){
          zAxis.write(zPosition);
        }

If x and y movement is zero, only the zAxis.write(zPosition) command will cause any change.

The previous position is capture by line # 83 at the beginning:

float  zStartingLocation = zAxis.read();  // I don't know why we treat the zaxis differently

when the while completes the position status is updated line # 170:

sys.xPosition = xEnd;
sys.yPosition = yEnd;

But Z is not updated in position???

Could we not right here in the code compare z finish position with z start position with something like this added in before the return:

float  zFinishLocation = zAxis.read();  // This store position after move in a temp variable.
if(zFinishLocation != zStartingLocation){ // If the z has not moved this will be unequal !!!
  Put stop command here;  // Not sure how this is done, but then throw error back to GC that sled 
                                            //lost track
}

Because the arduino code compiles before it downloads the code to the board, I can try variations of this on my own.

If there is any merit to this approach, or a proper call to stop the machine, I would appreciate any help and insight into solving this problem.

Thank you in advance for any help.

3

Sorry I missed one point. Probably want to check that the amount moved is equal to the start position plus the increment like this test —

if (zFinishLocation == zStartingLocation + zDistanceToMoveInMM) //Better test so it moves the correct
//amount – not that it just changed!!

Thanks again

4

Sorry for all the errors, it has been a long day at work:

if (zFinishLocation != zStartingLocation + zDistanceToMoveInMM) // Still a not equal test

5

Can you provide a section of gcode that repeatable demonstrates the error, or a section of log.txt that records the error?

1 Like
6

Yes. I be cutting some more parts this weekend. I will run the whole outline file, and when it stops I will post the screen shot, the log, and the gcode file for completeness.

Thanks again

2 Likes
7

Here is the data from the failurefrom the failure. It did not take long. failed on the third pass moving to z= -0.3 depth. I have sent 4 files:

Gcode file that was run
Log txt of the error
screen pic of the GC
screen pic of the command line stop I sent in when failed

Hope this helpsmirror_box_element1_outline.nc (6.1 KB)

Z_error_screen
Z_error_screen.jpg1366×768 108 KB
z_error_command_scrn z_error_log.txt (425.8 KB)

1 Like
8

Very frustrating day! I took the error measurements from the failure and tried to split the gcode into 8 passes(each one 0.1 Z in depth. I got to the 6th pass(the first cut with tabs) and it failed. I reset and ran again. Failed, but in exactly the same point. 2 more tries with full pwr reset and same failure. Here is the gcode sequence:

( Made using CamBam - http://www.cambam.co.uk )
( mirror_box_element1_outline 10/5/2018 4:45:31 PM )
( T0 : 0.25 )
G20 G90 G64 G40
G0 Z0.125
( T0 : 0.25 )
T0 M6
( Profile3 )
G17
M3 S1000
G0 X11.6573 Y7.2073
G1 F10.0 Z-0.6
G1 F45.0 X-11.7177
G3 X-11.8427 Y7.0823 I0.0 J-0.125
G1 Y3.2073
G1 X-11.8061 Y3.1707
G1 X-11.8427 Y3.2073
G1 X-12.3427
G1 X-12.3793 Y3.1707
G1 X-12.3427 Y3.2073
G1 Y7.0823
G3 X-12.4922 Y7.2049 I-0.125 J0.0
G1 X-14.6749 Y6.7699
G0 Z-0.5
G1 X-15.1162 Y6.682
G1 F10.0 Z-0.6
G1 F45.0 X-30.0547 Y3.7049
G3 X-30.1552 Y3.5823 I0.0244 J-0.1226
G1 Y0.0823
G3 X-30.0302 Y-0.0427 I0.125 J0.0
G1 X-14.975
G0 Z-0.5
G1 X-14.525
G1 F10.0 Z-0.6
G1 F45.0 X16.525
G0 Z-0.5
G1 X16.975
G1 F10.0 Z-0.6
G1 F45.0 X29.9698
G3 X30.0948 Y0.0823 I0.0 J0.125
G1 Y3.5823
G3 X29.9942 Y3.7049 I-0.125 J0.0
G1 X15.3424 Y6.6248
G0 Z-0.5
G1 X14.9011 Y6.7128
G1 F10.0 Z-0.6
G1 F45.0 X12.4317 Y7.2049
G3 X12.2823 Y7.0823 I-0.0244 J-0.1226
G1 Y3.2073
G1 X12.3189 Y3.1707
G1 X12.2823 Y3.2073
G1 X11.7823
G1 X11.7457 Y3.1707
G1 X11.7823 Y3.2073
G1 Y7.0823
G3 X11.6573 Y7.2073 I-0.125 J0.0
G0 Z0.125
M5
M30

It failed at the third tab every time at this place in the code:

G1 F45.0 X16.525
G0 Z-0.5 // It lost the z report on GC. bit moved but useless if GC does not track!!!
G1 X16.975
G1 F10.0 Z-0.6
G1 F45.0 X29.9698
G3 X30.0948 Y0.0823 I0.0 J0.125

Unfortunately, with all the power resets to run each modified gcode file over and over, the machine lost its center position on the stand. This renders the part useless because I have lost the home position load on the machine. I will start again tomorrow, but am very frustrated. I hope this information is of any help. I have spent 3 weeks now trying to cut these parts. I have a 2’ by 4’ router that I use for all my other parts. If I cannot get these parts cut on the maslow, I will have to send them to an outside source, eclipsing the cost savings of the maslow.

Too bad, because it is a great device. Hope there is a solution.

Thanks again

9

Thanks for sticking with this, and providing a clear way to replicate what you see. As you pointed out above, the Z axis doesn’t have the motion error checking that the X and Y axes have. Your suggestion for a fix is a good start, except that there are other places that move the z axis which wouldn’t be covered.
Maybe a better place is to check the z axis in the same place that the other two axes are checked. It would put up the same error dialog that the other axes use, but it would need a different value. The X and Y axes use sysSettings.positionErrorLimit, which defaults to 2mm. I would suggest using that value divided by 10 instead of introducing another variable.
I’ve created a branch with that fix here that you could try to see if it helps.

The other part of this is that it very much looks to me like you’ve got a problem with something wrong with your Z axis - the encoder or the cable. The only way I could reproduce the behavior you described was to unplug my z motor during a gcode. (DON’T DO THIS! I damaged the driver chip on a board doing this, :disappointed:) Without the patch above, no alarm was posted and the next line was run, just as you described. With the patch, the alarm dialog is triggered and the gcode program stops, with the current Z axis position showing in GC.

2 Likes
10

Thank you so much!! This allows me to do other things in the lab knowing that if the z stops, the sled will stop. I think I will try to order a new board(motor driver) and cable. Easy fix if it is that.

You have given me a way forward. I am removing the tabs(which is what always errors) and I will just do inside cuts and outisde cuts down to 0.6 . I then can use my multi tool to cut the remaining material(very quick actually)

Thanks again for your attention and help!!

1 Like
11

Happy to help! Before you click the ‘Buy’ button, take a look at the encoder wheel. It’s pretty easy to pop the cap off the a motor to look at it. If it is at all loose that could cause the intermittent problem. That, or cable-tying the cable to the motor housing would be the more common fixes.

12

Yes I will.

Also you mention the way you tested your fix for the z reporting and dialogue box on the sled keeping up. The test I used was to simply unplug the pwr adapter for the motor driver board. Arduino is still powered through the USB so system thinks all is normal. If you try (without your fix) to move the z, the system just thinks it is executing the z move with no error. But if you try to move the sled in x or y, it throws the error immediately. Now with the fix, when you move the z with an un-powered driver board, it will throw the same error.

Thanks again for the help. This should allow me to finish the complex parts I have been trying to cut.

I will report my results.

2 Likes
13

blurfl

I found your fix in report.cpp.

Yes, I understand that this is a better place because it checks all actions, not just gcode.

You changed this:

        if ((abs(leftAxis.error()) >= sysSettings.positionErrorLimit) || (abs(rightAxis.error()) >= sysSettings.positionErrorLimit)) {
            reportAlarmMessage(ALARM_POSITION_LIMIT_ERROR);

To this:

        if ((abs(leftAxis.error()) >= sysSettings.positionErrorLimit)   ||
            (abs(rightAxis.error()) >= sysSettings.positionErrorLimit)  ||
            (abs(zAxis.error()) >= (sysSettings.positionErrorLimit)/10.0)) {
            reportAlarmMessage(ALARM_POSITION_LIMIT_ERROR);

It now includes the z error limit which was not there and suggests a value 1/10 of the value for checking x and y. I will try it out!

Thanks again for considering the change!!

1 Like
14

Thanks for testing, there’s some discussion about the value to use for the Z alarm. Let us know if/how it works, and your suggestion for the value if it needs to be changed.

15

Well, I have done a significant amount of testing with the new code. It does not look like an electrical failure of the z encoder. It happens repeatedly in specific gcode sequences at the exact same point every time. Also, strangely, the new code does not throw an error when the z axis stops moving. I have uploaded the log file. It stops following the gcode a little past the middle of the text file.

Could my cambam be putting out code that is incompatible? It seems to fail when there are codes that are G2 or G3 with the i and j elements in it. I ran in contrast many runs of only G1 and G0 calls with a gcode file that cuts 60 or more holes. Lot’s of z motion but no failures!! Then immediately with the other G2 and G3 codes with i and j, almost immediate failure.

I am will to go to another gcode generator from dxf files for the solution. Could it be the cam bam files??

Thank you for your continued help

log_z_failure_no_stop.txt (281.7 KB)

16

There are two different z-axis issues going on here,m and you’re ‘enjoying’ them both!

Issue #466 - Z axis doesn’t have the motion error checking
This has not been merged as there are many different z-axis mechanisms which might need different values for a z-axis alarm trigger. The alarm would be a signal that the z axis needs some mechanical maintenance - either adjustment or lubrication. To date only you and I have tested this branch, and my testing with different z motors isn’t conclusive enough to take the patch into a pull request.

Issue #476 - Motion:arc() bug - G2 gcode cuts counterclockwise instead of clockwise
This issue would cause the z-axis alarm you mention:

It seems to fail when there are codes that are G2 or G3 with the i and j elements in it.

It was introduced with a patch that added z-axis travel to the G2 and G3 gcodes, due to insufficient testing. It It has been corrected in PR#477 which was merged recently, but won’t be released for a while yet. If you use the development version of the firmware G2 and G3 should handle the z axis correctly. Note that the z-axis alarm isn’t included in that development version, but as you indicated above you understand which one line of Report.cpp needs to be changed to get the z alarm if you want it.

Thanks for your patience :grin:

1 Like
17

Thanks for the quick reply. By the way, as a comparison to mine, what set of tools do you use for your 3d cad development and conversion to gcode. I use sketchup and cam bam.

Thanks again, I will try your suggestions.

18

I like Sketchup for complex shapes, and export to SVG then use Easel to generate the gcode. Easel for simpler shapes as well. No projects as complex as yours, though :grin:.

19

What file type do you export to the easel program?. I am looking at guides for easel and am new to this tool chain flow. Does the easel program have to be connected to the internet to perform the gcode function?

Thanks for a little guidance. I want to test whether simple shapes and z motions with this new tool chain do not error on my machine.

Thanks again

20

I submit SVG files.

It does - it’s web based, works in the browser.

It’s a good tool for that, though it doesn’t do ramping or helical drilling or the fancy stuff. For cutting simple shapes and leaving tabs it does fine.