@Mika Ok - pretty sure it’s a problem with the pulse inputs. They are too sensitive in the CubeX.
I have the CUBE connected to a motion controller, which is USB powered by the same laptop I’m running Granity from.
As a comparison I ran the IONI in my own custom motherboard, which has opto-isolation on the inputs.
Then the fault does not happen.
So. Maybe the cube should have some filtering on the pulse inputs?
Update. I’m afraid this is not getting better. One fault solved and then another rears its head…
Having disabled the FMO setting, now the drive will sit happily when not moving without faulting.
However - if the motion controller step direction signals are plugged in or unplugged, or if the motion controller is powered down or powered up while connected, then the error 140415 is triggered. I’ve never had this issue with any other motor drive. Either stepper or servo.
Even though I have optically isolated my motherboard pulse inputs it is still happening. It might seem trivial but I can see this is going to cause a lot of problems when used in the field.
So if there is a way to address this it would be appreciated. Let me know if you need any more detail.
Thanks Gerald
Hi Gerald
That error comes from step pulse train connected to direction input. Please double check your wiring.
Kind regards, Esa
@Esa Thank you for the reply. I did look it up, and it refers to the step pulses being too fast.
At the time it happens there are no step pulses being generated, and the wiring has nothing wrong with it.
IN addition to when the pulse signal is plugged in or out, it happens when the motion controller is powered down or turned on - and while the pulse cable is already connected. This could happen at any time but should not normally cause a fault in the drive. And as I explained - the pulse connection is optically isolated, so it should not be to do with any earth problem.
It can be a big problem for example if the camera gimbal is being operated remotely and it’s up on top of a crane or something - then it has to be brought down any time this happens for a reset.
I only have this issue with the IONI drive. I am assuming perhaps there is some disturbance in the pulse line when the motion controller resets after power up, - and which causes some false triggers.
What I need is to know how to desensitise the IONI, perhaps by electrical filtering? The inputs are rated as “high speed” up to 4 mhz, however the actual pulse rate is never more than 1mhz.
Otherwise please - is there was a way to simply disable this fault, as is possible with other faults?
Thanks Gerald
Hi Gerald
The fault is triggered when the signal to DIRECTION pin changes too fast, not the STEP pin. Please check that you have step & dir signal wired to corresponding pins.
We’ve have not had this kind of issue with IONI before.
Would it be possible to get wiring diagram or schematic of your system?
Kind regards, Esa
Hi. If I didn’t have the correct pins connected, I’d expect it would not work at all, or else would only go in one direction. So I think we can safely assume that is not the problem?
It is likely when the external motion controller is booting up or shutting down there is a sudden change of state of the direction signal. Maybe even bounces a little. But that is not something I can do much without effecting normal operation.
re wiring -The output from the motion controller is TTL 5v, but that is then connected via an opto isolator - circuit as attached. This is part of a custom motherboard.
If I connect the TTL output directly using the the cubeX1 then the result is the same.
So for that reason I mentioned the error detection in IONI might be the place to do something?
Hi Gerald
Have you checked with the Granity servo scope how the position setpoint behaves?
How does the motor behave when you drive it in torque mode?
https://granitedevices.com/wiki/Servo_motor_torque_mode_test
Also, please reply with servo scope graph of your tuning. If it oscillates, it’s possible to drive more than needed current into the motor.
Kind regards, Esa
Hi Esa. I’m not sure how this relates to the problem?
The motor runs fine in step direction mode - perfectly in fact. So nothing wrong with tuning or torque etc…
This is just a glitch when initialising or turning off the motion controller.
@Esa Not receiving a response - I am now wondering if your question about torque scope was related to the original problem with motor over-heating? And now maybe you are suggesting an oscillation might cause overheating? In fact I thought that discussion had finished, as you didn’t come up with any explanation earlier.
My current concern is the error caused when turning on and off the motion controller. In relation to that you haven’t responded. I’d still like to know if the error detection can be made less sensitive.
Or can I assume it is hard coded and you can’t do anything about it? Thanks G
Hi Gerald,
I would suggest you do what Esa asked. I am sure he has a reason for wanting this info.
You have been very fortunate to have Esa respond so quickly. He is normally a very busy guy and hard to get in touch with.
"Hi Gerald
Have you checked with the Granity servo scope how the position setpoint behaves?
How does the motor behave when you drive it in torque mode?
https://granitedevices.com/wiki/Servo_motor_torque_mode_test
Also, please reply with servo scope graph of your tuning. If it oscillates, it’s possible to drive more than needed current into the motor.
Kind regards, Esa"
I did two tests with the motor under load. (It is driving a harmonic drive gear reducer via timing belt.)
The first is at 3.25amp which is the motor rated current. The other is at double that. (I’m running a Meanwell SDR 24v supply adjusted to 28vdc, and the motor is rated at 24v. )
There were no motor faults during the test, including at 9.5 amp
In practice the motor performs well and follows its prescribed path as one would hope… (only a small amount of following error which is acceptable…)
Hi Gerald
I’m sorry for the late reply.
Those graphs look good. The latter graph means simply that the motor reaches the maximum speed and due to this the current it reduced.
If the position mode works also well, then the overheating doesn’t come from tuning.
I asked about these oscillations as if the system oscillates much in such manner that it’s not visible or audible, it’s likely to cause overheating.
For the error detection we will not remove those, as it would be too high safety and responsibility liability for us.
I asked for position setpoint graph from the servo scope to see if there are any high speed bursts coming that might cause this issue. If there’s a lot of noise that triggers the setpoint, there will also be current driven into the motor accordingly which might be the cause for the overheating.
Kind regards,
Esa
So you are saying that it is possible for the system to be in an oscillating state, yet without visible movement of the motor? Sounds like what may have happened, and why it was so mysterious.
Thermal time constant can’t help here?
Re the error detection - it’s still odd if it is triggered by the direction line, not the pulse line. Or could it be sensitive to changes in the earth? Also - I wonder what is it protecting against?
Thanks Gerald
Hi Gerald
Yes, it’s possible to push too much current into the motor with oscillation. This is somewhat long shot, as most oscillations are also audible if not visible also.
The thermal time constant should work in oscillating cases also.
It’s surprisingly usual mistake to wire the step wire to the direction input, and due to this it has it’s own fault flag. I remember only one case where earthing/earth currents caused any issues to the setpoint signal. In your application the currents are also not that high to be of concern.
Do you happen to have an oscilloscope at hand? I would really like to see the step and dir signals.
Kind regards, Esa
I think it’s not so surprising that step and direction often get mixed up…! But why it would cause the drive a problem - only you can know…
I don’t have a recording oscilloscope, only analogue - so I can’t really capture a single event like turning off the motion controller. Looking at the step pulses - they are quite clean - and the circuit for step and dir output is the same. The only thing I know is that when power is off the dir line is low, and when it boots up then it initiates to high.
I tried recording with Salae Logic but only shows the dir line going high or low once. No apparent bounce or repeat.
BTW the error is not consistent. Often it doesn’t happen, just randomly.
