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

Yes I separated them when I suspected noise and also added an em filter in the power lines to the arduino board and the laptop power thinking that it might help.

1 Like

I do remember there was 1 cambam issue with GC and think to remember it was due to uncloased poly lines, but dement and drunk can’t link to it. The code would run perfect in CAMoticts but GC had a huge hickup. If you don’t want to post the full gcode here, you can pm it to me. Just to exclude the cambam aspect.

It looks like the Cambam setting for Z axis feed rate is 10 ipm, which should be reasonable. It might be interesting to set that to 45, same as the XY feedrate. I think I’ve seen something similar in a file with a very low setting for the Z axis feedrate. You could use an editor to search for instances of

G1 F10.0 Z

And change them to

G1 F45.0 Z
1 Like

It looks like the Cambam setting for Z axis feed rate is 10 ipm, which should be reasonable. It might be interesting to set that to 45, same as the XY feedrate. I think I’ve seen something similar in a file with a very low setting for the Z axis feedrate. You could use an editor to search for instances of

G1 F10.0 Z

And change them to

G1 F45.0 Z

Yes Thank you I thought also that varying the speed might affect it somehow. Also the canned boring cycles take too long, so it would speed them up. I kept them slower due to reading about mechanical failures on the standard spring clip that keeps the router moving with the turning lead screw.

1 Like

The Z axis is very slow, 10 is probably still too fast.

David Lang

I do remember there was 1 cambam issue with GC and think to remember it was due to uncloased poly lines, but dement and drunk can’t link to it. The code would run perfect in CAMoticts but GC had a huge hickup. If you don’t want to post the full gcode here, you can pm it to me. Just to exclude the cambam aspect.

Has errors 4 different times when I run it usually on layer 6 or 7 when the tabs have started

Here is the whole file:
mirror_box_element2_outline.nc (8.1 KB)

no matter what speed you put in the file, it’s not going to go faster than the
mechanical limits. It’s currently the motor RPMs that are the limit, not
anything else in the system

David Lang

Are you saying that the z motor turns but the Z: number on the screen doesn’t change? Or that the z motor turns and the number on the screen changes but the router doesn’t change depth?

I’m trying to get the error to happen here on my setup, using the big file as well as the shortened set of commands here but so far I see my sled stop for each z change then resume as expected after the z moves to the proper depth.
It’s easier to fix a problem when it can be triggered on command. What should I do to make the problem happen?

Are you saying that the z motor turns but the Z: number on the screen doesn’t change? Or that the z motor turns and the number on the screen changes but the router doesn’t change depth?

The z motor turns, the router moves the depth (up or down) but the z does not change. I also checked the log and the z value does not change there as well.

I do not know. My thought is that if you stop the sled when the z on log and GC z report doesn’t change, I can start to catalogue the failures.

Right now I have to watch the rig like a hawk for hours because when it occurs, it will immediately ruin the part (and hours of complex sub gcode segment runs. If it would stop, I could reset the rig and run again with probable success.

1 Like

If the firmware doesn’t see pulses from all or part of the encoder, one gets z motion without a number change in GC. As you found, GC logs the values it gets. This sounds like a hardware problem to me.

The parts of this connection are

  • the encoder on the motor
  • the cable
  • the Arduino Mega2560 (pins 18 and 19 on the yellow silkscreen)
  • the Maslow PowerControl board (the signal passes through connectors, but is not altered).

When I’ve had this problem, it was caused by an intermittent connection of the cable to the z motor; I used a cable tie to firmly attach the cable so that it wouldn’t wiggle loose. Others have had an intermittent encoder on the z motor. In one case, the encoder disc was coming loose, super glue was the repair for that.
An intermittent malfunction of an Arduino Mega2560 IO pin would be relatively rare, in my experience they fail altogether when they die.
On the PowerControl board, checking the solder connections for the z-axis connector and the pins that connect to the Arduino should be enough to pass or fail that item.

Respectfully

The problem is that the sled goes on when the GC does not see the change in the log or the Z report.

I do not touch the rig or cables. I restart the board and reboot the GC and it works again for some period of time. It is not mechanical or electrical in connection. It is something that happens with the z reporting. Why does it require a reboot and re power to start the z reporting?

Isn’t there a value in the software that checks that value of the z data and checks that it has moved the proper amount?

I know that this is true for x and y, because when I turn of the power to the motors(but the arduino is still powered by usb) the sled immediately stops when it does not keep up, but the z will move and not check and will keep going with manual or gcode file operation.

I appreciate all of the help that the forum is providing and will continue testing. The maslow works awesomely other than this one problem.

I will continue to report data from this so that a solution maybe found.

1 Like

blurfl

Thank you so much for your attention. I recall that you had indicated that the GC only reports the value that the Arduino is reporting in status. Is that the case?

I have a programming background, but do not begin to understand how the software works and what the distribution of functions across the python GC and the c/c++ Arduino are.

I have taken a look however at the reporting procedure calls in the Python and have seen the following:
from line 341` in main.py ------------
def runPeriodically(self, *args):
‘’’
this block should be handled within the appropriate widget
‘’’
while not self.data.message_queue.empty(): #if there is new data to be read
message = self.data.message_queue.get()

        if message[0] == "<":
            self.setPosOnScreen(message)

This section seems to be detecting if the message_queue is not empty(from the arduino)and if so places the current position on the screen. That seems to be async to the operation depending on when the arduino sends a status message.

It would seem though that when I run the device, and when the gcode is running with G0 Z moves in the file, that the machine waits for the G0 Z move to complete - then updates the position(has been updating continually during the move to completion) - and at completion moves on to the next gcode statement in the buffer.
from line 370 in frontPage.pu -------------
def sendLine(self):
try:
self.data.gcode_queue.put(self.data.gcode[self.data.gcodeIndex])
self.data.gcodeIndex = self.data.gcodeIndex + 1
except:
print “gcode run complete”
self.gcodecanvas.uploadFlag = 0
self.data.gcodeIndex = 0

This code is responsible for the transfer of the next gcode line into the queue to be sent to the machine. As I said, the machine seems to wait for each of the G0 Z moves. There may be an opportunity to check whether the Z value in the position message

self.setPosOnScreen(message)

equals the gcode command sent in the

self.data.gcode_queue.put(self.data.gcode[self.data.gcodeIndex])

command.

I believe these values are already parsed out of the messages, so the SW may be able to test the properties with respect to the outgoing and incoming z values to see if the sleds z value fell behind.

These actions may not be fully synchronized, but seem to have some wait and continue logic to it.

Further, this action would only be flagged if the Gcode command being sent to the arduino contained a z value change. This would allow for checking only in z moves.

This is just a thought on approach. I will raise this issue now in the Firmware section in the forum because it would appear to be a fault in the arduino code. I have seen comments in the arduino source code already that ask why the Z motion is handled differently in the code than the x and y is. I know it is related to the fact that x and y motions depend on the triangular calculations for correct motor motions, and the z motion is a straight step to operation. The position read and sensing for keeping up however should be the same.

Thanks again for all of your help and attention.

checking if Z falls behind needs to be done int he firmware, by the time the
data gets to GC it’s too late to react.

GC is not intended to be providing real-time control and reporting, it feeds
g-code to the firmware which is the real-time engine. The only real-time
function of GC is sending a stop command.

David Lang

The data about the z-axis position is reported along with the X and Y positions so that if you are seeing the X and Y position update then you will also be seeing valid z-axis data.

My current thinking is that the issue could have to do with the serial data sent from Ground Control to the Machine. Because the Z axis moves are always done at the end of the line like G1 X10.0 Y11.0 Z12.0 if any characters are cut off of the command it will usually be the z-axis commands.

Would it be possible for you to capture a screenshot of Ground Control right after the error has happened?

1 Like

Bar,

Yes I will do a screen capture and post it this weekend if it will help.

I point you to the listing above. All my designs generate single G0 Z moves with 0.1 inch moves each and do not combine with any x and y motions. Not sure that would be an issue because there are no instructions with Z at the end of a combined move.

Those instructions usually are contained in a design that is moving the router bit in 3 dimensions at once. Platform plywood routers usually separate the z moves and then do a single layer cut for the prescribed x y shape. Tabs are the exception, but Cambam still generates a separate z instruction for the depth change, and then generates an x y move for that level of tab.

1 Like

Also useful would be the log.txt file, especially if you can quit GC shortly after the error occurs (so the error is near the end of the log. In the log, GC records each line it sends:

Sent: G1 X123.45 Y543.21 Z-0.1 

A few lines later, it logs the same line as echoed from the firmware:

G1 X123.45 Y543.21 Z-0.1 

Ignoring the chatter that records the position as reported and that several Sent: lines can be buffered by the firmware, one can look for a line where the firmware response doesn’t match what was sent.

1 Like

Not sure if it helps, but I had a similar issue and ended up fixing my “similar” issue by cycling “enable zaxis” in ground control under Maslow Settings.

1 Like

Interesting I will try disabling and re-enabling the z axis under settings and see if that corrects the z reporting.

I tried just toggling the z enable in settings but the z reporting did not restore. It did restore with a pwr cycle of arduino and reboot of GC