Are there homing methods that resemble 119/121 except for active low inputs? I see some that are similar, but not quite the same (e.g. 125, 127). They are still assuming that the home switch is active high and when it’s active they only move at the stage two velocity, which is typically much slower. For homing a machine to an active low input, this would mean either homing very slowly (some machines have hundreds of inches to move in order to home) or making the stage two move faster and sacrificing accuracy.
Are there other alternatives? The only thing I can think of is to create a user buffer to hold the inverted state of the input and a user buffer that triggers every sample that copies the inverted value of the input to the user buffer.
Niko has already been working to change the improved homing options to work off your limits configured state (Active High or Active Low). I expect it in the next release. The original methods will remain the same for customers that expect that behavior.
We recommend the use of Drive based homing as that the is most accurate homing you can get. There is no network latency and many drives use some for position capture, touch probe, latched position, etc.
The fastest way to handle homing in the master is to build a custom homing function with your machine’s design in mind.
I suspect you are trying to design a catch all process that works with any number of current or future drives and machine configurations. That will never be as fast, but will be more flexible. Our Homing functions are fine for that as they were designed without any machine/drive knowledge. I recommend a two stage process. A fast home to get you near the switch (with a small offset) followed by a second home in which you ensure you hit Homing velocity before hitting a switch.
In Summary:
Drive Homing: Most Accurate
Custom Homing: Fastest
Generic Homing: Simplest
In this case, I just want to be able to use a “standard” homing method with an inverted input. In our world, NC switches are fairly common, and I don’t need any new “behavior” other than how the input is interpreted. A number of other API functions take a mask/value pair of arguments for handling active high vs. active low. In this case, that would seem more flexible than what is currently accepted: bit index.
I can’t easily use drive-based homing with an arbitrary I/O. The drives know nothing about external I/O points. I understand about precision and network latency, but the only way I’d be able to do it is with the drive’s dedicated home input.
We’re planning to implement our own master-based homing routine(s), but for now, I need to make use of what’s already in place as much as possible.