I am seeing different behavior between homing methods 23 and 29, which I would expect to be otherwise analogous (reversed directions of movement). Method 29 (rising home negative start) doesn’t seem to be doing anything for stage two.
I see obvious differences in the trace information, but I’m not doing anything that I would expect to cause a difference. All the homing parameters are identical, except for homing method.
RapidCodeHomeTrace.2.PositiveStart.txt
Works like expected. Moves until home switch goes high, then reverses direction until it goes low.
(28:47:10.797) Axis (0) Homing Canceled!
(28:47:10.820) Axis (0) Home Method Rising Home Positive Start (23). Home Stage (Stage Two) Home Switch Initial State (False)
(28:47:10.820) Axis (0) Home to Move to Switch(Home) with direction (Positive). Home Stage(Stage Two)
(28:47:10.834) Axis (0) Starting Velocity SCurve Move at Velocity (1.000000), Accel (1.000000), and Jerk (100.000000)
(28:47:18.101) Axis (0) Home to Move to Switch(Home) with direction (Negative). Home Stage(Stage Two)
(28:47:18.115) Axis (0) Starting Velocity SCurve Move at Velocity (-1.000000), Accel (1.000000), and Jerk (100.000000)
(28:47:19.433) Axis (0) HomePositionSet()
(28:47:19.445) Axis (0) Home Moving to Zero. MoveSCurve with Velocity (1.000000), Accel (1.000000), Decel (1.000000), and Jerk (100.000000)
RapidCodeHomeTrace.2.NegativeStart.txt
Moves until home switch goes high. Returns immediately without backing off the switch (i.e. the home switch is high when it returns).
(28:43:0.437) Axis (0) Homing Canceled!
(28:43:0.459) Axis (0) Home Method Rising Home Negative Start (29). Home Stage (Stage Two) Home Switch Initial State (False)
(28:43:0.459) Axis (0) Home to Move to Switch(Home) with direction (Negative). Home Stage(Stage Two)
(28:43:0.473) Axis (0) Starting Velocity SCurve Move at Velocity (-1.000000), Accel (1.000000), and Jerk (100.000000)
(28:43:5.60) Axis (0) HomePositionSet()
(28:43:5.72) Axis (0) Home Moving to Zero. MoveSCurve with Velocity (1.000000), Accel (1.000000), Decel (1.000000), and Jerk (100.000000)
Both of these functions are looking for a change home limit rather than a particular edge (Rising/Falling). 23 would have captured the “Falling edge” if it had hit the positive limit and then turned around.
Our Homing routines are similar to the DS402 without being a perfect match. We can’t change the behavior our implementation without breaking things for customers that might have been doing the method for a decade. I’ll get the documentation on how these functions work updated.
I don’t understand. I am attempting to home to the home switch, and neither the pos or neg limits should have been hit.
When I home starting in the negative direction, it hits the home switch, then stops and returns.
If I wanted a homing method that was symmetric to 23, what would I choose, or how would I configure it to behave accordingly?
If you are on the far side of the switch relative to the travel direction, you’d expect to hit the end of travel. You’d then turn around and find the switch again. Both functions 23 and 29 exhibit the same pattern of behavior that would only be revealed in some cases.
The safe to way to do 23 (as currently diagrammed) in any case is to run 23. Do a negative move that would get you off the home switch. Run 23 again. This will consistently get you to the Rising Edge of the Home Switch.
The safe way to do 29 (as currently diagrammed) to Run 29, negative move off the switch, then Run 23 (or 29 though 23 should be faster).
We’ll be updating the documentation for actual behavior soon.
When I read “starting in the positive direction,” I think of movement that is unconditionally always in the same physical direction, independent of current position or where any of the limit/home switches live. The (updated) diagrams suggest that my understanding is incorrect.
For example, #24, instance (a) starts moving to the right, but instances (b) and (c) start moving to the left. In what sense is this “starting in the positive direction?”
What I see is that the final move of each instance is always in the same direction.
I’m also unsure how the home signal would ever be on continuously for instances (b) and (c). We use proximity sensors that are on only so long as a corresponding part of the head is right next to it. We would never have the situation seemingly described in this diagram. In what kind of scenario would the home sensor be on continuously for any meaningful distance of travel? Is this merely expanded to show what would happen if the home sensor happened to be on when homing began?
Typically, when we home to a sensor, we move until the sensor goes high, then we move in the opposite direction more slowly until the sensor goes low. I would much prefer to end the homing routine off the home sensor (otherwise I’ll have to do it myself), since, in our scenarios, that’s also going to be the desired physical limit of travel.
Is there a homing method you implement that would accommodate that behavior? We’re almost never going to home while the home sensor is high, because we often use the (physical) limit switches for homing.
Also, we want to be able to use arbitrary I/O points (not necessarily dedicated drive inputs) as the home switch. I presume that prevents us from using 17 or 18 as the homing method, right, since those won’t use the HomeCustomConfigSet() parameters?
Would FALLING_HOME_POSITIVE_START work similar to 23 except that it would back off the home switch (instead of backing “onto” the switch)?
Thanks for the updated diagrams. If you wanted to diagram your implementations of all the homing methods (and I could learn to understand them correctly), that might help me answer my own questions.
The DS402 homing diagrams aren’t very representative in that the home signal is normally very small relative to the range of motion. Your 3 cases are…
Signal Active - The middle one. Movement would be small to find the edge of the signal and then possibly the index pulse to the right or left of it.
Signal Inactive - Case a. The direction you travel finds the Home Signal before the End of Travel.
Signal Inactive - Case c. The direct you travel finds the End of Travel before the Home Signal. You have to turn around to find the signal.
RISING_HOME_NEGATIVE_START makes sense as a routine if you know your Home Signal is closer to the Negative Limit than the positive limit. You are more likely to find the limit before End of Travel and save time performing the search. Negative Start indicates that it will go negative in Signal Inactive Case but you will often go the other direction in these methods. If the Home Signal is active, it should seeks the appropriate edge based on method. This would normally be negative motion for Rising methods and positive motion for Falling.
Some Systems have Home Signals that are continuous to the End of Travel. Some of the Homing Methods are designed for those cases. Here is an example:
It sounds like you want to use the methods that home to the Negative or Positive Limit (1 & 2) until you talk about arbitrary I/O points. Are those always going to be connected to something at an end of travel?
We’re going to provide a diagram for all the methods actual behavior soon. Would you like to pick this back up after reviewing them?
No problem. I was partially having a discussion with myself.
I realize not everybody is going to have physical setups like we’re doing it, and I didn’t mean to imply only silly people would do anything differently than we do it. I’m just unaware of how most of them are doing it.