Debounce within subroutine?
- Nitram
- Topic Author
- Offline
- Elite Member
Less
More
- Posts: 210
- Thank you received: 15
17 Jan 2020 10:32 #155056
by Nitram
Debounce within subroutine? was created by Nitram
Hello.
I have an ATC setup on a mill (FADAL) which calls a main macro for the M6, then from within that macro a series of sub macros are called to achieve the tool change in sequence.
Two of the sub macos are to advance the ATC carousel clockwise, and the other to advance the ATC carousel counterclockwise.
Within these subs, as the ATC rotates, each pocket position activates a hall sensor and an M66 P4 L3 Q1.5 sends a digital input to the controller that the next pocket position has arrived. An M61 Q... then updates the tool number. This process continues via a counter until the commanded tool number has arrived.
On a very rare occasion, if a tool number is requested, the ATC stops one tool short of the target. In other words if I issue an M6 T15, on a rare occasion I will get tool 14 or tool 16, depending on the direction the ATC rotates to get there, but it is always short, never over.
What I think is happening, is that as the ATC starts to rotate, with all the tooling and weight in situ hanging from the carousel, the ATC wiggles a bit as it gets going and the hall sensor tiggers a double leading edge i.e. once leaving the current position (due to the ATC wiggling and re-triggering it on the way out, and then once again as the hall sensor gets a rising edge due to the normal course of events as the carousel arrives at the next pocket position. This means that the tool count is raised by two for only a single tool pocket advancement, thus the controller "thinks" it has arrived at the correct tool, but is in reality one pocket short due to the double trigger...
So, does an M66 have the ability to be de-bounced?
If not, could I put a G4 Pxxx between turning on the ATC carousel motor, and the M66, so that the carousel starts turning, but it is not "looking for" the rising edge of the hall sensor until the G4 P... has expired thus allowing time for the previous hall sensor to depart without triggering on the rare occasion and creating a "double count", i.e. only leaving the "door open" for the new leading edge for the incoming pocket position to be seen?
Long post, with probably a simple answer, but I thought it important to set the context.
Thanks,
Marty.
I have an ATC setup on a mill (FADAL) which calls a main macro for the M6, then from within that macro a series of sub macros are called to achieve the tool change in sequence.
Two of the sub macos are to advance the ATC carousel clockwise, and the other to advance the ATC carousel counterclockwise.
Within these subs, as the ATC rotates, each pocket position activates a hall sensor and an M66 P4 L3 Q1.5 sends a digital input to the controller that the next pocket position has arrived. An M61 Q... then updates the tool number. This process continues via a counter until the commanded tool number has arrived.
On a very rare occasion, if a tool number is requested, the ATC stops one tool short of the target. In other words if I issue an M6 T15, on a rare occasion I will get tool 14 or tool 16, depending on the direction the ATC rotates to get there, but it is always short, never over.
What I think is happening, is that as the ATC starts to rotate, with all the tooling and weight in situ hanging from the carousel, the ATC wiggles a bit as it gets going and the hall sensor tiggers a double leading edge i.e. once leaving the current position (due to the ATC wiggling and re-triggering it on the way out, and then once again as the hall sensor gets a rising edge due to the normal course of events as the carousel arrives at the next pocket position. This means that the tool count is raised by two for only a single tool pocket advancement, thus the controller "thinks" it has arrived at the correct tool, but is in reality one pocket short due to the double trigger...
So, does an M66 have the ability to be de-bounced?
If not, could I put a G4 Pxxx between turning on the ATC carousel motor, and the M66, so that the carousel starts turning, but it is not "looking for" the rising edge of the hall sensor until the G4 P... has expired thus allowing time for the previous hall sensor to depart without triggering on the rare occasion and creating a "double count", i.e. only leaving the "door open" for the new leading edge for the incoming pocket position to be seen?
Long post, with probably a simple answer, but I thought it important to set the context.
Thanks,
Marty.
Please Log in or Create an account to join the conversation.
- Todd Zuercher
- Offline
- Platinum Member
Less
More
- Posts: 5009
- Thank you received: 1443
17 Jan 2020 17:33 #155067
by Todd Zuercher
Replied by Todd Zuercher on topic Debounce within subroutine?
Couldn't you just put a debounce on the input from your hall sensor?
The following user(s) said Thank You: Nitram
Please Log in or Create an account to join the conversation.
- Nitram
- Topic Author
- Offline
- Elite Member
Less
More
- Posts: 210
- Thank you received: 15
18 Jan 2020 01:53 #155090
by Nitram
Replied by Nitram on topic Debounce within subroutine?
Thanks Todd, quite right!
I knew there was a simple answer that was eluding me, I just needed to look closer to the root of the issue and didn't see the wood for the trees...
Debounce now added to HAL (setp to 20 servo-thread cycle debounce) and seems to work without any more problems, although given it is a relatively rare occurrence, I'll will feel more comfortable with no more occurrences over the long term.
Thanks again for your help!
Regards,
Marty.
I knew there was a simple answer that was eluding me, I just needed to look closer to the root of the issue and didn't see the wood for the trees...
Debounce now added to HAL (setp to 20 servo-thread cycle debounce) and seems to work without any more problems, although given it is a relatively rare occurrence, I'll will feel more comfortable with no more occurrences over the long term.
Thanks again for your help!
Regards,
Marty.
Please Log in or Create an account to join the conversation.
Time to create page: 0.052 seconds