homing command run for second time makes motors run in wrong direction

[brettdaman]

Hi,

I have a raspberry pi that is connected to a tinyG for a cnc like machine. On the pi runs a node program that sends gcode directly to the tinyG every time it needs to move. In the startup of my program, it asks the tinyG to home. This works perfect the first time after a power cycle of the tinyG or after pressing the reset button. If I rerun the program and it tries to home for a second time, the direction of motors is reversed. I already spend a couple of days on this issue, trying to mess with a lot of parameters but with no luck. Can anyone describe what is causing this behavior and how to fix it?

To replicate it you might need my initial config parameters that I send before homing and the homing command. that is all that i send to the tinyG

g.set( {1:{po:1,ma:0,sa:1.8,tr:36,mi:8,pm:2}, 2: {po:0,ma:1,sa:1.8,tr:36,mi:8,pm:2}, 3: {pm:0}, 4: {pm:0}, x: {am:1,sv:1000,lv:500,lb: 5,sn:3,sx:2,tn:0,tm:600,vm:5000}, y: {am:1,sv:1000,lv:500,lb: 5,sn:3, sx:2,tn:0,tm:600,vm:5000}, z: {am:1,sv:200,lv:20,lb: 5,sn:0, sx:0,tn:-30,tm:0,vm:500}, a: {sn:0,sx:0}, gun:1,st: 0, sl: 1}) .then(function() { //g.get({'sr':''}); console.log('Homeing'); g.write({'gc':'G28.2X0Y0'}); }) .catch(function(err) { console.log(err); });

[troisiemetype]

Hi,

I remember having problems of that kind at the very beginning with my miiling CNC. It may seems silly, but I just had a bad contact, or too weak wires, for one motor. So it moved, but one of he four wires was sometimes not driving current, and the motor did whatever he wanted: any direction, but right number of steps. Could it be something like that in your case?

Note aside: unless they could change following use you make of your CNC, you don't have to send the settings on each startup. And you have some axis that don't have motor to drive them, but this could be intended.

Hope you'll find where it comes from.

[brettdaman]

Dear,

thanks for the help. I dont believe it is a wiring problem since the problem can be perfectly replicated.

A new development: It seems that if my device stopped over the middle of the axis the homing is in the correct direction. So it seems that the device thinks that the homing point is at the negative side and decides to change the motor orientation. But I have no idea how to configure the device so it stops doing that.

[silveyratx]

I am having a very similar issue. Any solution to this yet?

[brettdaman]

bump, did not find a fix yet!

[silveyratx]

Here is what I found out:

• I noticed that some connectors for the motors might have been shorting on the inputs of the tinyG just because they were very close to each other
• the cables that I bought with the minyCNC in Amazon were different from one another and would have different connector orientation

[brettdaman]

And your problem is gone?

In my case its very unlikely to be a wiring problem. The problem is very repeatable and consistent. All works fine if i push the reset button before I home the second time. And all is fine if I place the cnc in x+ y+ quadrant. In the other cases the motors turn the other way. The motors got plenty of power and react well to the current regulating potentiometers.

[silveyratx]

So far so good. Have you checked the polarity of your motors? You can send $xpo (x being the motor number 1-4).

[brettdaman]

Just to be sure I flash the basic setup comments for all my motors and all my axes each time when my application code starts. And just after that I do the homing

[cmcgrath5035]

Are you aware of the parameter update issue discussed in (closed) Issue 123? I have seen large variations in the time it takes tinyG to complete an individual parameter update and would expect even larger variations when using a json command to update multiple parameters. Does your software wait for the tinyG parameter writes to respond with success before proceeding?

[brettdaman]

My software waits a few seconds, I see the status chance long before I move on in code. So that cant be the problem. And the parameters are read perfect. The device behaves as expected every time I update the settings. So at the moment I need to power cycle/reset the tinyG before each homing and then it works perfect. So I place a relay that I control from my raspberry pi to power cycle in code, but that is not ideal.

[cmcgrath5035]

If a reset is whtt is required, sending a "CTL-X" should do the jib in software. Better (?) than a relay, but does not really explain the behavior

[brettdaman]

I worked around it by resetting the boards "CTL-X" before homeing. But it is still an issue that should be solved.

[jrcandy]

Hi @brettdaman , did you find any other solution to this issue? Sounds similar to mine would be useful to see if you can replicate mine. Basically as with yours, on a second homing command, once it finds the limit switch, it keeps moving in that direction instead of backing off in the opposite direction. Were you able to detect that the switch has been found? I could see it only in the verbose output by the deceleration

[brettdaman]

@jrcandy This is an issue from 3.5 years ago, I don't have the hardware anymore to test. Behavior was unexpected when executing a second homing so it could be related. Have you tried to configure your position manually before the failing step to force the tinyG to go the other way? Did you try to reset the board before your procedure? I can't really help you much further, it's a long time ago that I used tinyG.