Joint Amplifier Fault on Non-Moving Axis
12 Aug 2024 17:25 #307568
by DrDflo
Joint Amplifier Fault on Non-Moving Axis was created by DrDflo
Background: I have a 3-axis benchtop milling machine (PM-833TV) that I converted to CNC. I upgraded to DMM servo motors about 3-years ago and everything has worked like a charm until the hard drive in my HP 8300 died last week. I misplaced my most recent backup HAL and INI files, so I had to modify an older version. They are attached below. I also upgraded from 2.8 to 2.9 after installing the new hard drive. I am using the ProbeBasic GUI.
The problem: Approximately every other manual tool change, when the Z-axis retracts the spindle to its max travel, I receive a "joint 1 amplifier fault." This is odd because the Z-axis is joint 2. Joint 1 is the Y-axis, which is not moving. Further, when the DYN4 servo drivers encounter an error their status LED switches to red and the drives have to be power cycled to clear the error. There is no indication of an error on the physical Y-axis drive when I receive the fault on the LinuxCNC GUI. Simply pressing the power button in the GUI allows me to resume control of the mill (but it cancels my current milling operation). Further, this "joint 1 amplifier fault" does not occur during long milling operations the rely heavily on the Y-axis only during manual tool changes.
Any idea what could be causing this? Please let me know if you require any additional information
The problem: Approximately every other manual tool change, when the Z-axis retracts the spindle to its max travel, I receive a "joint 1 amplifier fault." This is odd because the Z-axis is joint 2. Joint 1 is the Y-axis, which is not moving. Further, when the DYN4 servo drivers encounter an error their status LED switches to red and the drives have to be power cycled to clear the error. There is no indication of an error on the physical Y-axis drive when I receive the fault on the LinuxCNC GUI. Simply pressing the power button in the GUI allows me to resume control of the mill (but it cancels my current milling operation). Further, this "joint 1 amplifier fault" does not occur during long milling operations the rely heavily on the Y-axis only during manual tool changes.
Any idea what could be causing this? Please let me know if you require any additional information
Please Log in or Create an account to join the conversation.
- tommylight
-
- Away
- Moderator
-
Less
More
- Posts: 19188
- Thank you received: 6430
13 Aug 2024 00:53 #307602
by tommylight
Replied by tommylight on topic Joint Amplifier Fault on Non-Moving Axis
I would venture a guess at interference and check that first with a scope or a DVM that has a min/max memory feature.
The following user(s) said Thank You: snowgoer540
Please Log in or Create an account to join the conversation.
- snowgoer540
-
- Offline
- Moderator
-
Less
More
- Posts: 2388
- Thank you received: 779
18 Aug 2024 17:52 - 18 Aug 2024 17:53 #308097
by snowgoer540
Replied by snowgoer540 on topic Joint Amplifier Fault on Non-Moving Axis
In addition to what Tommy said about noise in the cabinet, etc. and checking it with an oscilloscope, one thought that came to mind while reading this was ensuring that:
The X servo fault is really connected to input-20
The Y servo fault is really connected to input-21
The Z servo fault is really connected to input-22
This won't solve your issue, but it could possibly explain the Y and Z servo confusion (or it would verify noise on the Y servo-fault line).
Some other ideas include:
1. Commenting out the servo-fault connections in the .hal file. This will likely resolve the issue, but it is a valid check to rule out a software vs hardware issue.
2. If all else fails, assuming it is noise and you are unsuccessful in resolving it for whatever reason, you could use the debounce component to add a debounce delay and ensure a steady state change on the input before tripping the software stops. Example: If Z retracts cause a 1mS blip on the oscilloscope on the Y servo-fault input, then adding a 5mS debounce should take care of that. This is of course a band-aid, but a solution nonetheless.
3. Loose connections, etc.
The X servo fault is really connected to input-20
The Y servo fault is really connected to input-21
The Z servo fault is really connected to input-22
This won't solve your issue, but it could possibly explain the Y and Z servo confusion (or it would verify noise on the Y servo-fault line).
Some other ideas include:
1. Commenting out the servo-fault connections in the .hal file. This will likely resolve the issue, but it is a valid check to rule out a software vs hardware issue.
2. If all else fails, assuming it is noise and you are unsuccessful in resolving it for whatever reason, you could use the debounce component to add a debounce delay and ensure a steady state change on the input before tripping the software stops. Example: If Z retracts cause a 1mS blip on the oscilloscope on the Y servo-fault input, then adding a 5mS debounce should take care of that. This is of course a band-aid, but a solution nonetheless.
3. Loose connections, etc.
Last edit: 18 Aug 2024 17:53 by snowgoer540.
The following user(s) said Thank You: tommylight
Please Log in or Create an account to join the conversation.
Time to create page: 0.071 seconds