Home and motor direction issues

Hey folks. I built a PrintNC CNC. This is a typical xyz machine with two synchronous y-axis motors. I just finished wiring and am trying to work some bugs out. Unfortunately, it is completely possessed and has a mind of its own.

I've been trying to get it to home. It seems like things randomly work and then don't work the next time. Motors will sometimes be able to move both directions, and other times they'll only go in one direction.

My latest attempt was the closest to success I've come. The Z axis homed as expected. Then, X and Y begin their homing sequence. Both y motors hit home successfully and stopped. The x axis moved towards home. Once it registered and stopped, the left y axis motor decided it wanted to continue back towards home and crash into the machine without stopping.

I've been scrubbing through the HAL and INI file, but I don't see anything wrong. I appreciate any help or point in the right direction. One thing I did notice, my x axis homes on the right but the picture shows home on the left. I don't know if that matters.

 
 

Thanks. I gave it a shot but didn't have any luck. I've fixed a few things that were wrong, including correcting Z and X offsets and origin locations, but I am still having major issues. My machine locations will suddenly change for no reason.

Here are two of the crazy things I've noticed happening.

1. I home the machine. X, Y, and Z go through the routine and everything behaves normally. Then, I'll run some commands and notice that one of the axes magically changes its coordinate on the LinuxCNC GUI(Axis) to be outside of bounds. Because it is now outside of bounds, it will no longer move. I have to restart the program to regain the zeros and re-home. As an example, my z-axis limits are 0 (down) and 4 (up). 4 is also the home location and the origin offset. My x-axis has a similar configuration. I'll home it and run a few commands for testing. Then I notice that Z no longer responds and shows it is at location 8 on the screen. Way out of bounds, even though it hasn't moved. Similar issues happen on X and Y. 
2. I'll home the machine and Z homes normally and stops. Then X and Y home normally and the motors stop, but the coordinates in LinuxCNC GUI keep moving like the motors are turning...but they aren't. The program keeps looking for home even though the machine found it. 

No idea what's happening. Any ideas where I can start? This seems more like a software issue, but maybe I've wired in some kind of crazy bug.

I'm going to do a play-by play, because I'm having a difficult time describing my issues. So I'm going to type what I am actually doing and observing. These issues are happening often enough that I believe I can capture it better this way.

1. Shut off LinuxCNC (AXIS) and power to CNC. Left both off for a couple minutes. I am using the same PC for this conversation.
2. Launch LinuxCNC.
3. Power on CNC and wait about 30 seconds.
4. Untoggle emergency stop and toggle machine power. All coordinates at 0.0
5. Hit home all.
6. Home successful. Z @ 4", Y1 & Y2 @ 0, and X @ 38.5. Origin is typical front/left/down of machine, but home is front/right/up. So far so good. 
7. Type the following MDI Command: G0 X15 Y22 Z1.25 F250
8. No movement at all. X, Y, and Z all showed movement on the preview screen but didn't actually move. The preview now shows they are at those coordinates. The machine is still in the home position.
9. Negative manual control on X axis had no effect. No movement.
10. Positive manual control on Y axis had no effect, but negative crashed it into the bearing. It was still at home, but thought it was at Y22.

This is actually one of the best examples I could have had. Other times one or two axis will work, and the third will give up the ghost. I'll probably try this same approach in a few minutes just to see if it behaves differently.

I realized the F250 G-Code command may be Marlin specific and screwing things up. Here goes round two. The machine is still sitting at home, so I'm going to manually move it an inch or so away on each axis while powered off. The machine and LinuxCNC are off.

1. Launch LinuxCNC.
2. Power on CNC and wait about 30 seconds.
3. Untoggle emergency stop and toggle machine power. All coordinates read at 0.0
4. Hit home all.
5. Home successful. Z @ 4", Y1 & Y2 @ 0, and X @ 38.5. Origin is typical front/left/down of machine, but home is front/right/up. So far so good.
6. A little different than last time. Manually run X axis in the negative direction.
7. Success. Took it to 36.3630.
8. Manually run Z in negative direction.
9. Success. Went to 1.9318
10. Manually run Y in positive direction.
11. Success. Took it to 18.4420.
12. Type the following MDI Command: G1 X5 Y7.5 Z 2.88
13. Error. Cannot do G1 with Zero Feed Rate. I guess I need that F?
14. Type the following MDI Command: G1 X5 Y7.5 Z 2.88 F300
15. Success. WTF?
16. Type the following MDI Command: G1 X26 Z3.8 F500
17. Success, although I think I've maxed out the feedrate. Not sure what that is.
18. Type the following MDI Command: G1 X9 Y22 F500
19. Success.
20. Type the following MDI Command: G1 Y1 F500
21. Success. I just realized I switched from the G0 command the first try to now using G1. Going back to G0.
22. Type the following MDI Command: G0 Y18.5 F500
23. Success.
24. Type the following MDI Command: G0 X3.77 Y4.668 Z2.99 F423
25. Success. I give up.
    
    GREMLINS!!!

EDIT: AHA. After those steps, I manually ran Y to its max at 27.5 with success, followed by X's min at 0. Then I tried to manually drive Z down a few inches...but it wouldn't move towards zero even though the preview says it is moving down. It will move positive. So now I've again lost control and need to reset both LinuxCNC and the CNC. Took a little longer this time. 

What could possibly be causing this?

Not to beat a dead horse, but to try and provide one last example. Sorry for all the posts, I just want to be clear what's happening.

I was curious about how the Z-touchoff behaved. So I moved Z to about the halfway point and "touched off." I then manually drove it Up (positive) to see if it would still stop at the existing limit, or go past it. Fortunately, it stopped at the home offset location (like it's supposed to).

Then I tried to manually go negative again back to the touch-off point. It moved on the preview but not in reality. Because I'm brain dead, I tried again in the positive. Since it thought it had moved negative but was still at home, it moved up and destroyed my endstop mount (again, luckily I have good superglue).

I've had enough of this thing for tonight. Any advice is appreciated.

phillc54 wrote:

A good starting point is to ensure that all the axes move in the correct direction after homing.
Right arrow moves the tool right (X+), up arrow moves the tool rearwards (Y+), and page up moves the tool up (Z+).

You mentioned previously that X homes to the right but your ini file suggests otherwise, HOME, HOME_OFFSET, and MIN_LIMIT are all in the region of 0.0 which is tool to the left.

 

This was true from the original post. It is one of the configurations I fixed prior to my first post yesterday. I think it is all correct now. I attached the updated INI and HAL files. The origin is front/left/down. Y positive is towards the back, X positive is towards the right (and its home location with offsets) and Z positive is up (and its home location with offsets). My Y-Axis is inverted still, and reinverted with a negative on its scale. When I tried to just remove the inverted command the Y-Axis went a little nuts. I may try to fix that again if anyone thinks it could be triggering these issues. 

   

andypugh wrote:

If things suddenly shoot out into outer space after running G-code then I would suspect that either the tool table has spurious offsets in it, or the work coordinate systems have.

Try MDI M6T1G43, M6T2G34 etc, and G54, G55, G56 etc. See if any unexpected changes in the DRO occur. (none of these should result in physical motion, generally)
 

Sorry for my noob'ness, but I'm not clear on what you mean by tool table or what offsets could be affecting the work coordinate system.

Trying and reporting back what I see from each command.

• M6T1G43: This opened a tool change prompt that said "Insert tool 1 and click continue when ready."
• M6T2G34: This prompted an error. It says "Unknown gcode used."
• G54: Looks like it changed something on the preview
• G55: Same as above
• G56: I don't see this doing anything.
  
  This doesn't really shoot off into outer-space, as you say. It thinks it is moving a motor in one direction, but the motor doesn't spin. So it changes its coordinate system and forgets where it is. But it usually will let me move it in the other direction, which causes it to crash into all sorts of things.
  
  Like right now. It homed just fine before I conducted those gcode tests. But once I tried doing manual control (F3, not MDI), it fails. Z moved down when I told it to go negative. Y Moved positive. Then I tried to go negative (left) on X and the motor didn't move. BUT, it thought it moved. The coordinates and position were changing on the preview. Now, I bet I could hit positive and it would crash into the frame on the right. I don't want to try it, but I'm sure it would happen (as I've found out the hard way). Sometimes it's X that fails, sometimes Y, and sometimes Z. Other times they all work fine, as during my second play-by-play post above.