Motor homes in wrong direction!

[scott14468]

Hi All, I am running TinyG V0.97, build 440.20 on a recently purchased Synthetos V8 control board and have run into a very repeatable what appears to be a firmware issue problem homing motors. The problem happens on all four stages (x, y, z and a) on each of the four axis 1,2,3 and 4.

I have configured a normally-open home (not limit) switch for each axis, and have confirmed that the polarity is correct. The xLimit signal is low when the axis is in its home position.

The problem is: attempts to home any of the motors when they are sitting at a negative position causes the motor to move more negative.

Here are my configuration parameters:

$x [xam] x axis mode 1 [standard] [xvm] x velocity maximum 1000 mm/min [xfr] x feedrate maximum 1000 mm/min [xtn] x travel minimum 0.000 mm [xtm] x travel maximum 200.000 mm [xjm] x jerk maximum 200 mm/min^3 1 million [xjh] x jerk homing 1000 mm/min^3 1 million [xjd] x junction deviation 0.0500 mm (larger is faster) [xsn] x switch min 1 [0=off,1=homing,2=limit,3=limit+homing] [xsx] x switch max 0 [0=off,1=homing,2=limit,3=limit+homing] [xsv] x search velocity 1000 mm/min [xlv] x latch velocity 254 mm/min [xlb] x latch backoff 5.000 mm [xzb] x zero backoff 5.000 mm tinyg [mm] ok> $1 [1ma] m1 map to axis 0 [0=X,1=Y,2=Z...] [1sa] m1 step angle 1.800 deg [1tr] m1 travel per revolution 2.0000 mm [1mi] m1 microsteps 1 [1,2,4,8] [1po] m1 polarity 0 [0=normal,1=reverse] [1pm] m1 power management 2 [0=disabled,1=always on,2=in cycle,3=when moving] tinyg [mm] ok> $st=0

Any thoughts are appreciated.

Thanks, Scott

[lagnat]

I know this reply doesn't answer your question but I wanted to share some thoughts that you might find useful. From what I've seen over the years, this project is effectively dead. You may get an answer but I suspect that you will not. You could go look at g2core to see what the Synthetos folks are up to these days. You might also want to look at FluidNC.

[ril3y]

Have you read through this? https://github.com/synthetos/TinyG/wiki/Homing-and-Limits-Description-and-Operation

Also, does the motor move in the right direction when giving a positive move? g0x10 etc? Also, can you do a g28.3x0 (1 axes) and does that home properly? We really do recommend NC switches too btw. TinyG codebase has been "done" for a few years now and yes we are moving forward with G2.

However, we will accept pull requests if you find an issue. You can try fluidnc (which is grbl) but you will not have the same motion control as g2 and tinyg. Either way let me know.

Riley

On Thu, Feb 23, 2023 at 2:08 PM scott14468 @.***> wrote:

Hi All, I am running TinyG V0.97, build 440.20 on a recently purchased Synthetos V8 control board and have run into a very repeatable what appears to be a firmware issue problem homing motors. The problem happens on all four stages (x, y, z and a) on each of the four axis 1,2,3 and 4.

I have configured a normally-open home (not limit) switch for each axis, and have confirmed that the polarity is correct. The xLimit signal is low when the axis is in its home position.

The problem is: attempts to home any of the motors when they are sitting at a negative position causes the motor to move more negative.

Here are my configuration parameters:

$x [xam] x axis mode 1 [standard] [xvm] x velocity maximum 1000 mm/min [xfr] x feedrate maximum 1000 mm/min [xtn] x travel minimum 0.000 mm [xtm] x travel maximum 200.000 mm [xjm] x jerk maximum 200 mm/min^3 1 million [xjh] x jerk homing 1000 mm/min^3 1 million [xjd] x junction deviation 0.0500 mm (larger is faster) [xsn] x switch min 1 [0=off,1=homing,2=limit,3=limit+homing] [xsx] x switch max 0 [0=off,1=homing,2=limit,3=limit+homing] [xsv] x search velocity 1000 mm/min [xlv] x latch velocity 254 mm/min [xlb] x latch backoff 5.000 mm [xzb] x zero backoff 5.000 mm tinyg [mm] ok> $1 [1ma] m1 map to axis 0 [0=X,1=Y,2=Z...] [1sa] m1 step angle 1.800 deg [1tr] m1 travel per revolution 2.0000 mm [1mi] m1 microsteps 1 [1,2,4,8] [1po] m1 polarity 0 [0=normal,1=reverse] [1pm] m1 power management 2 [0=disabled,1=always on,2=in cycle,3=when moving] tinyg [mm] ok> $st=0

Any thoughts are appreciated.

Thanks, Scott

— Reply to this email directly, view it on GitHub https://github.com/synthetos/TinyG/issues/278, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABYSMZ2JU4K5LE6LOFCEWLWY6YUFANCNFSM6AAAAAAVGAQ2VI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[scott14468]

Hi Riley,

Thanks for your reply.

Yes, movement using g0, which is the only movement command we use, is correct for both negative and positive values. And yes, if the motor is in a positive or zero location, it does home correctly. Our home switches are NC (limit signal is 0 when the stage is at home). I have tried both settings for ST-- didn't make a difference.

Also, thanks lagnat for the heads-up, much appreciated.

Scott

[ril3y]

Did you try the g28.2 command I asked?

On Fri, Feb 24, 2023 at 7:14 AM scott14468 @.***> wrote:

Hi Riley,

Thanks for your reply.

Yes, movement using g0, which is the only movement command we use, is correct for both negative and positive values. And yes, if the motor is in a positive or zero location, it does home correctly. Our home switches are NC (limit signal is 0 when the stage is at home). I have tried both settings for ST-- didn't make a difference.

Also, thanks lagnat for the heads-up, much appreciated.

Scott

— Reply to this email directly, view it on GitHub https://github.com/synthetos/TinyG/issues/278#issuecomment-1443604223, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABYSM625KTRVWZITXFK5BDWZCQ3TANCNFSM6AAAAAAVGAQ2VI . You are receiving this because you commented.Message ID: @.***>

[scott14468]

Hi Riley,

I assume you mean g28.3? I'm sure this will fix the issue. This is what I'm going to try implementing next.

Thanks, Scott

[scott14468]

Hi Riley,

Having just tried that, it doesn't work. The controller moves the motor in the negative direction to get to home. Since it is already past zero (in the negative direction), it fails.

Best, Scott

[ril3y]

Can you post your whole config? Issue a $$ and share that.

[scott14468]

Hi Riley,

Here's the configuration

tinyg.txt

Thanks, Scott

[giseburt]

The problem is: attempts to home any of the motors when they are sitting at a negative position causes the motor to move more negative.

can you explain that more? Specifically: what are the scenarios where it works correctly (or are there any), and which direction does it move?

It sounds like you want it to home to maximum instead of minimum. In that case:

[xsn] x switch min 1 [0=off,1=homing,2=limit,3=limit+homing]
[xsx] x switch max 0 [0=off,1=homing,2=limit,3=limit+homing]

I believe you want xsn to be 0 and xsx to be 1 in order to home to a positive direction.

However, if you instead want to to home to negative, but it doesn’t go positive if it starts with the switch “hit,” please try this and report back what happens:

1. Move the axis out toward the center of travel (for safety)
2. Start homing with the switch not pressed (it should start to move toward the switch), and then manually press it once it’s moved a little.
   • You should see it start to back off immediately after the switch is pressed. Release the switch and it should stop after 5mm (as set by xsb)
3. With the switch pressed start homing again. It should start by going away from the switch.
   • Release the switch. It should then start moving toward the switch again.
   • Press the switch again and it should stop and move away slowly.
   • Release it again and it’ll move 5mm away.

If all of that is reversed, check the input pin voltage with a multimeter.

[scott14468]

Hi Rob,

Thanks for the reply.

We have a single NO switch connected to the axis min position that is configured as a home switch (since we can move in both positive and negative directions from its position).

When the axis is at a zero or positive position, homing moves the axis in a negative direction toward the switch and the home operation succeeds. But when the axis is positioned negative, the home operation also moves the motor more negative away from the home switch. It doesn’t stop until it hits a physical/mechanical limit potentially damaging the system. It just seems in the case of a single switch, the controller should move the motor toward zero, not always negative. Our stages happen to be rotary stages. A couple of them can rotate the full 360 degrees, but one of them has wires so it must be limited to less than a full revolution. This is the stage giving us the problem.

Our initial solution was to rearrange the stage so its coordinate range is always positive. This would work as a solution however our mechanical design doesn’t allow this.

We have since revised the system to include two limit switches, the min switch configured as home and limit, the max switch configured as limit only. This is working OK.

Appreciate your help,

Scott

From: Rob Giseburt @.> Sent: Friday, February 24, 2023 6:12 PM To: synthetos/TinyG @.> Cc: scott14468 @.>; Author @.> Subject: Re: [synthetos/TinyG] Motor homes in wrong direction! (Issue #278)

The problem is: attempts to home any of the motors when they are sitting at a negative position causes the motor to move more negative.

can you explain that more? Specifically: what are the scenarios where it works correctly (or are there any), and which direction does it move?

It sounds like you want it to home to maximum instead of minimum. In that case:

[xsn] x switch min 1 [0=off,1=homing,2=limit,3=limit+homing]

[xsx] x switch max 0 [0=off,1=homing,2=limit,3=limit+homing]

I believe you want xsn to be 0 and xsx to be 1 in order to home to a positive direction.

However, if you instead want to to home to negative, but it doesn’t go positive if it starts with the switch “hit,” please try this and report back what happens:

1. Move the axis out toward the center of travel (for safety)
2. Start homing with the switch not pressed (it should start to move toward the switch), and then manually press it once it’s moved a little.

• You should see it start to back off immediately after the switch is pressed. Release the switch and it should stop after 5mm (as set by xsb)

3. With the switch pressed start homing again. It should start by going away from the switch.

• Release the switch. It should then start moving toward the switch again.
• Press the switch again and it should stop and move away slowly.
• Release it again and it’ll move 5mm away.

If all of that is reversed, check the input pin voltage with a multimeter.

— Reply to this email directly, view it on GitHub https://github.com/synthetos/TinyG/issues/278#issuecomment-1444649069 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQS3PV4ZECDXKTIWCXQUYTWZE55LANCNFSM6AAAAAAVGAQ2VI . You are receiving this because you authored the thread. https://github.com/notifications/beacon/ABQS3PQNAXJ6ZJ65P34LVU3WZE55LA5CNFSM6AAAAAAVGAQ2VKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSWDOMG2.gif Message ID: @. @.> >

[ril3y]

Curious what machine you are using this with. Just wondering. Could you share some details?

On Sat, Feb 25, 2023 at 11:13 AM scott14468 @.***> wrote:

Hi Rob,

Thanks for the reply.

We have a single NO switch connected to the axis min position that is configured as a home switch (since we can move in both positive and negative directions from its position).

When the axis is at a zero or positive position, homing moves the axis in a negative direction toward the switch and the home operation succeeds. But when the axis is positioned negative, the home operation also moves the motor more negative away from the home switch. It doesn’t stop until it hits a physical/mechanical limit potentially damaging the system. It just seems in the case of a single switch, the controller should move the motor toward zero, not always negative. Our stages happen to be rotary stages. A couple of them can rotate the full 360 degrees, but one of them has wires so it must be limited to less than a full revolution. This is the stage giving us the problem.

Our initial solution was to rearrange the stage so its coordinate range is always positive. This would work as a solution however our mechanical design doesn’t allow this.

We have since revised the system to include two limit switches, the min switch configured as home and limit, the max switch configured as limit only. This is working OK.

Appreciate your help,

Scott

From: Rob Giseburt @.> Sent: Friday, February 24, 2023 6:12 PM To: synthetos/TinyG @.> Cc: scott14468 @.>; Author @.> Subject: Re: [synthetos/TinyG] Motor homes in wrong direction! (Issue #278)

The problem is: attempts to home any of the motors when they are sitting at a negative position causes the motor to move more negative.

can you explain that more? Specifically: what are the scenarios where it works correctly (or are there any), and which direction does it move?

It sounds like you want it to home to maximum instead of minimum. In that case:

[xsn] x switch min 1 [0=off,1=homing,2=limit,3=limit+homing]

[xsx] x switch max 0 [0=off,1=homing,2=limit,3=limit+homing]

I believe you want xsn to be 0 and xsx to be 1 in order to home to a positive direction.

However, if you instead want to to home to negative, but it doesn’t go positive if it starts with the switch “hit,” please try this and report back what happens:

1. Move the axis out toward the center of travel (for safety)
2. Start homing with the switch not pressed (it should start to move toward the switch), and then manually press it once it’s moved a little.

• You should see it start to back off immediately after the switch is pressed. Release the switch and it should stop after 5mm (as set by xsb)

3. With the switch pressed start homing again. It should start by going away from the switch.

• Release the switch. It should then start moving toward the switch again.
• Press the switch again and it should stop and move away slowly.
• Release it again and it’ll move 5mm away.

If all of that is reversed, check the input pin voltage with a multimeter.

— Reply to this email directly, view it on GitHub < https://github.com/synthetos/TinyG/issues/278#issuecomment-1444649069> , or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABQS3PV4ZECDXKTIWCXQUYTWZE55LANCNFSM6AAAAAAVGAQ2VI> . You are receiving this because you authored the thread. < https://github.com/notifications/beacon/ABQS3PQNAXJ6ZJ65P34LVU3WZE55LA5CNFSM6AAAAAAVGAQ2VKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSWDOMG2.gif> Message ID: @. @.> >

— Reply to this email directly, view it on GitHub https://github.com/synthetos/TinyG/issues/278#issuecomment-1445150729, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABYSM63EYPCYOKUCTN3BXLWZIVT7ANCNFSM6AAAAAAVGAQ2VI . You are receiving this because you commented.Message ID: @.***>

[giseburt]

Ok, I think I have it sorted out now. The base assumption of the software (and myself, until you explained the rotary bit) is that the switch is at the end of travel in one direction.

To be more specific: When it starts homing, the first thing the software does is admit it has no idea “where it is” and so it’s going to go looking for the switch. Since it doesn’t know where it is, it will always just start going in whichever direction you told it the switch is. In this case, you said that the switch is at the minimum end of the travel, so start going negative and eventually you’ll hit the end where the switch is, and then you’ll be able to say where you are for sure.

When the axis is at a zero or positive position, homing moves the axis in a negative direction toward the switch and the home operation succeeds. But when the axis is positioned negative, the home operation also moves the motor more negative away from the home switch.

There’s your issue. The switch needs to be indicating the absolute end of the travel in one direction, not the middle. I’m not sure how we would have it know which way to go for this case.

The only alternative I know of would be to set the switch to be the probe switch instead, and rather that homing you would tell it to probe and provide which direction to go in by hand. Then when it’s done probing set your offsets to zero out your coordinate system.

In any case, this shouldn’t be true:

It doesn’t stop until it hits a physical/mechanical limit potentially damaging the system.

I do not fully understand the mechanics of your system, but you should strive to make the limit switches safely able to be hit without damaging the system or the switches.

More importantly, it shouldn’t be possible to go past the switch and it release again. If you wish to have the switch indicate the midpoint of the rotary axis, you need to have from the zero-point all the way negative hold the switch down. In that case, when it starts homing it can tell that the switch is hit and knows it’s in the negative, and then you would need the set the latch back off to half the full rotation, so that it will back off the switch into the positive from even the most-negative position.

Hopefully that’s helpful.

[giseburt]

Oh I meant to add that for rotary axes you might look into magnetic or hall-effect switches and magnets so you can detect without physical contact.

[scott14468]

Thanks for all your help. We are using the controller to run a 4-axis color measurement system.

Best, Scott

[ril3y]

I assume this resolved your issue? Sounds like a cool project!

On Mon, Feb 27, 2023 at 7:12 AM scott14468 @.***> wrote:

Closed #278 https://github.com/synthetos/TinyG/issues/278 as completed.

— Reply to this email directly, view it on GitHub https://github.com/synthetos/TinyG/issues/278#event-8615043459, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABYSM4VVHXYBOIUFBUFJC3WZSKZZANCNFSM6AAAAAAVGAQ2VI . You are receiving this because you commented.Message ID: @.***>

[scott14468]

Hi Riley,

Yes, we ended up adding two limit switches to each axis.

Thanks for your help, Scott