This is the "holy grail" (fictional dreams) of stepper motors: reading motor position without encoder feedback.

Grzesiuk93

[snip]
that we move axis manually, by hand
[snip]

[snip]
so we can acquire a right position in emergency situation like this? How are you managing these problems?
[snip]

There is no configuration / software remedy for this situation. The open loop configuration offers no feedback that can be used.

My systems require a return to a known position. Having sensors at various position makes it possible for you to do so. Two options: (a) user tells the system which sensor to aim for (b) machine takes safe route to nearest sensor position.

The only other option is to make use of an encoder (as you have guessed already).

#dP

 This is the "holy grail" (fictional dreams) of stepper motors: reading motor position without encoder feedback.

Grzesiuk93

[snip]
that we move axis manually, by hand
[snip]

[snip]
so we can acquire a right position in emergency situation like this? How are you managing these problems?
[snip]

There is no configuration / software remedy for this situation. The open loop configuration offers no feedback that can be used.

My systems require a return to a known position. Having sensors at various position makes it possible for you to do so. Two options: (a) user tells the system which sensor to aim for (b) machine takes safe route to nearest sensor position.

The only other option is to make use of an encoder (as you have guessed already).

 I got it. In this case is it safe to use (in defined conditions - for example - when motor is not in sensor 1 or 2) MoveVelocity block  Then if we are in position, we set the bit (which consists of - for example - InVelocity bool output from MC block AND I1.0 (pos 1/2)) that will execute MC_Stop. Would that solution be okay in practice?

Grzesiuk93

I got it. In this case is it safe to use (in defined conditions - for example - when motor is not in sensor 1 or 2) MoveVelocity block  Then if we are in position, we set the bit (which consists of - for example - InVelocity bool output from MC block AND I1.0 (pos 1/2)) that will execute MC_Stop. Would that solution be okay in practice?

YES, if you are sure it is safe.

The other option is to use homing. Then this is handled for you.

Homing also has many modes. There is automatic, assisted and direct. If the sensor that you use as reference is always the same sensor, then use automatic (it moves by itself) or assisted. If the sensors change as for the situation, then use direct setting.

For the most accurate "direct set" homing, the best would be to use a hardware interrupt on the sensor used as reference.

#dP

 

Grzesiuk93

I got it. In this case is it safe to use (in defined conditions - for example - when motor is not in sensor 1 or 2) MoveVelocity block  Then if we are in position, we set the bit (which consists of - for example - InVelocity bool output from MC block AND I1.0 (pos 1/2)) that will execute MC_Stop. Would that solution be okay in practice?

YES, if you are sure it is safe.

The other option is to use homing. Then this is handled for you.

Homing also has many modes. There is automatic, assisted and direct. If the sensor that you use as reference is always the same sensor, then use automatic (it moves by itself) or assisted. If the sensors change as for the situation, then use direct setting.

For the most accurate "direct set" homing, the best would be to use a hardware interrupt on the sensor used as reference.

 Do you mean MC_Home block? There are some available Modes, but as far as I see in help there are no modes like automatic, assisted or direct. Or maybe i misunderstood you. My sensor is always the same for referencing.
What about Homing in Drive Configu. there is requierement to use Hardware Input for homing, which I dont have, so option with Homing will not pass in my case.

Grzesiuk93

Do you mean MC_Home block? There are some available Modes, but as far as I see in help there are no modes like automatic, assisted or direct. Or maybe i misunderstood you. My sensor is always the same for referencing.
What about Homing in Drive Configu. there is requierement to use Hardware Input for homing, which I dont have, so option with Homing will not pass in my case.

 Yeah, I get the namings Siemens use wrong. But yes I was thinking of the modes in the MC_HOME block. A reminder is attached as a PDF.

You have several options there to look at.

> My sensor is always the same for referencing.
> there is requierement to use Hardware Input for homing, which I dont have

These two statements contradict each other. Would you care to explain? Keep in mind that configuring an input to be linked with the motion control, does not mean it cannot be used in normal code.

Defining a profile for homing, does not mean you have to use homing. Active homing will work well for you. Passive homing will need you to code the movement, but the referencing ("zeroing") happens in the background when triggered.

#dP

 

Grzesiuk93

Do you mean MC_Home block? There are some available Modes, but as far as I see in help there are no modes like automatic, assisted or direct. Or maybe i misunderstood you. My sensor is always the same for referencing.
What about Homing in Drive Configu. there is requierement to use Hardware Input for homing, which I dont have, so option with Homing will not pass in my case.

 Yeah, I get the namings Siemens use wrong. But yes I was thinking of the modes in the MC_HOME block. A reminder is attached as a PDF.

You have several options there to look at.

> My sensor is always the same for referencing.
> there is requierement to use Hardware Input for homing, which I dont have

These two statements contradict each other. Would you care to explain? Keep in mind that configuring an input to be linked with the motion control, does not mean it cannot be used in normal code.

Defining a profile for homing, does not mean you have to use homing. Active homing will work well for you. Passive homing will need you to code the movement, but the referencing ("zeroing") happens in the background when triggered.

 I guess I just misunderstood that function. Could you please explain me what is a Digital input homing switch that we set up in Configuration for Active/Passive homing? At first I thought it is a button that will execute homing, but now I see I might be wrong. Digital Input homing switch says that we have achieved a desired position, is it a signal for MC_Home that function was executed and axis is on the position of DI homing switch (sensor)?

Grzesiuk93

I guess I just misunderstood that function. Could you please explain me what is a Digital input homing switch that we set up in Configuration for Active/Passive homing? At first I thought it is a button that will execute homing, but now I see I might be wrong. Digital Input homing switch says that we have achieved a desired position, is it a signal for MC_Home that function was executed and axis is on the position of DI homing switch (sensor)?

Please feel welcome to use the search facility in this forum. Find the full document of small version that I have attached earlier. There are more descriptions on "homing" as a task.

• MC_HOME requires a trigger, just like the movement commands do.
  
  
• The input refers to the reference sensor.
  
  
• The image in the motion configuration tells you how the movement will take place.
  
  
• Active mode make those movements as soon as MC_HOME is triggered; the path as the image shows in the motion configuration.
  
  
• Two motion tasks are active when doing passive homing. (a) The MC_HOME records the place where the reference is triggered. (b) The user program with motion tasks (relative move / velocity / jogging)  that pushes movement beyond the reference sensor. The expected path as the image shows in the motion configuration.
  
  

#dP

(more info)

 Thank your for everything now, its all clear to me now. [snip]