I'm using SM1720D85C-DE in a current design.
We've been asked to add hardware limit switches to the existing design.
Can't seem to locate much information on how these work. I set up pins C&D as limits (UCP/UDM) - any way I can read this back to verify it is set properly? RBm and RBp return either 0 (limit not reached) or 1 (limit reached) which I assume is correct.
When a limit is reached (switch activated) does motor stop? Do I need to stop motor (monitor limit via polling)?
Saw a "Disable Limits" in playgound - do I need to enable limits?
Any help would be greatly appreciated.
If you don't issue UCI and UDI, the limit switches will be enabled in firmware. UCP and UDM will enable them if UCI and UDI were previously issued. Make sure that portC is used for positive travel (increasing encoder counts) and portD is used for minus travel. The axis will stop when a switch is encountered.
What firmware version is your motor?
Firmware version is 4.15T. I'm also issuing the LIMD command as I don't think this version has directional limits by default.
Behavior I'm seeing is motor will stop when limit switch is triggered but controlling software checks counts and can tell move didn't complete - it reissues G command and the motor continues on to original count value even though switch is triggered. Is this expected? I didn't think the motor would 'allowed' a move to continue with switch activated.
This is the case for either switch and motor going in either direction - FYI this is the behavior for all four combinations (counts+/portC switch, counts+/portD switch, counts-/portC switch, counts-/portD switch).
What should be behavior for "opposite" switch being thrown? (i.e. counts+/portD switch, counts-/portC switch)
Thanks for quick response.
JT
I'm trying to find a motor with the same firmware to find a work around. The 4.15 firmware was released about a decade ago, and offered flexibility needed at that time. One problem with 4.15 was that a "G" command would clear all faults and continue to try a move even if it ended in another fault (ZS existed in the instruction set, but would allow a G to do the same thing). Our Newer firmware requires the programmer to acknoledge the fault and deal with it.
The workaround for V4.15 is to always check your Status word before starting a move... and after it. You can tell if the move was successful or if it didn't complete.
As for the limit switches on V4.15 being ignored on another "G" command... I would use IF statements to detect that they were triggered... and write my code to prevent a "G" command in the wrong direction.