Hello team,
I have a Hiwin ED1F servo drive that is connected to a Hiwin linear motor (LMSA23).
My problem is that I power-cycle the drive, start the network and try to enable the axis in RapidSetup. I will hear the motor clicking/enabling, it does a small movement to do the commutation, the motor then shows as disabled in RapidSetup due to “Amplifier fault” “No error”.
If I set the Amp Fault Trigger action to None in RapidSetup I can Enable the drive. I can then re-activate the Amp Fault trigger and it will now not trigger if I do following Amp Enable.
I have used the MotionScope to record the Controlword and Statusword during when I click “Enable” in RapidSetup during these two cases.
For when I get the error I have investigated the Statusword and I never see Bit 3 being set to indicate “Fault”.
Can you help me understand what RapidSetup is reacting to?
Here’s a link to a .ZIP file containing my two MotionScope trace:
We have a built in 1000 cycle (1 second @ 1kHz) abort when a drive fails to fully enable. That is what is happening. No error was signaled by the drive but it also was never reaching Operation Enabled. This is a safety feature we added so people who called AmpEnableSet without the timeout. We recommend everyone uses the timeout to avoid a state where you think you are enabled but never reach it. A disconnect between the intent of the Motion Controller and the state of the drive.
Finding out why the drive will not enable is the next step. Normally this is just the drive missing an STO or the like. Most drives signal that state as an error. Other drives do not.
Thanks, now I understand what is happening. I enable the drive and linear motor, the first time after power cycling the drive needs to do its commutation/wake and shake routine. That routine for sure takes longer time then 1 second. I will try the overloaded AmpEnableSet with timeout tomorrow.
If you have an expected longer than a 1000 cycle amp enable process (like the wake and shake), I suspect we’ll need to use Output Overrides to avoid the safety abort. We’re going to want to use Output Overrides during the wake and shake. Take a look and let me know if you have any questions.
We’ll discuss adding something that is less heavy handed for a future release.
We have now migrated from 8.3.1 to 10.4.0 to be able to use the (for us) new overloaded AmpEnableSet() with a timeout. We specify 5000 for the timeout. However I still see the drive being disabled 1 second after the initial servo on command.
Is this expected?
Yes, that is still expected. As Jacob mentioned, you’ll need to use the PDO Output Override on the drive’s control word, so you can set the control word from your software. It seems like you only need to do this upon the first enable of the drive. Once the wake-and-shake is done, you can stop overriding the control word, so it works as normal with the RMP firmware.
To be clear, at present, these are different features.
In 7.0.11, the firmware was modified to Amp Fault if the drive did not reach OPERATION_ENABLED state after 1000 cycles. (In 10.3.9 this was modified to be exactly 1s, regardless of sample rate.). This causes the Axis get an Amp Fault action (most people set to ABORT).
In 10.3.4 the AmpEnableSet(timeout) was added. It throws an exception if the AMP_ACTIVE signal does not turn on within the timeout. (We integrated some drives that take ~300+ milliseconds to enable and you don’t want to start commanding motion until it is actually enabled.)
In 10.3.6 we improved the AmpEnableSet(timeout) so that the firmware feature where command position is set equal to actual position (while disabled) stays active until the AMP_ACTIVE signal turns on. This eliminates any small jumps you might see when enabling an Axis. It is very helpful on drives that take a long time to enable.
I think your use case makes a good argument for us to modify the firmware feature of causing the Amp Fault to use the timeout value specified by AmpEnableSet(timeout), if the timeout is larger than the firmware default of 1 second. How does that sound?
After further review, we don’t want to use the value passed in to AmpEnableSet(true, timeout) because that would alter the standard/expected behavior for all RapidCode users.
Instead we’ll give you access to the timeout value by reading/writing RMP memory if you want to change it.
AmpEnableSet() documentation has been updated to note the behavior and how to access the Amp Fault timeout value. Here’s some example test code:
