1 second delay

Using a real-time PC-104 computer with a sample time of 1 millisecond and an optical encoder I measured the delay from the serial command to the actual response of the motors to be over 1 second!!

I tested the the delay in the serial command and in the response of the optical encoder and both are negligible--on the order of milliseconds.

Why does the motor controller take over 1 second to respond? Can it be sped up?

I've tried using the maximum and minimum acceleration, also with and without the watchdog and nothing helps. Changing the acceleration only changes time to reach the commanded velocity (as expected) but does not change the delay time between the serial command and the actual response of the motors.

I also tested to see if part of the delay was due to the play in my drive chain, however, when accelerating from a forward velocity to a greater forward velocity was only 10 milliseconds less than accelerating from a reverse velocity to a forward velocity. Thus the slack in my chain is only about 10 milliseconds of the 1 second delay.

How is this improved???

I would be happy to send plots of the results.

1s does not sound anywhere near right.

Try testing with roborun. Slide the speed to a given value and hit the stop button. Command should take effect practically instantly.

I'm not sure what "practically instantly" means, especially on RoboRun that has a resolution of 1 second on the data log. And since the response of the motors was still not within the 1 second resolution, how can you argue that a 1 second delay is not "anywhere near right?" Using a real-time device with a resolution of 0.001 seconds I am not able to get the controller to respond any faster than 1.080 seconds.

So how can this be improved? Or, how can my money be refunded?

Besides, I don't want to run the controller through RoboRun, I want to be able to command it through serial, and with a lot better response than 1 second.

Roborun graphs updates slowly because the various parameters are read at a lower priority and sequencially.

Practically instantly means that you hit the button and the controller stops right away. Actual timing is in the 10 to 50ms for the command to take action (not knowing exactly what windoes does or when).

Clearly our products would be totally useless for the application where we have been selling them if response time was 1s.

We accept returns within 30 days of purchase. Please contact us via the contact or support form on the web site.

Note that if you are operating in closed loop, the PID parameters will play a very important role in how fast your motor will reach the desired speed.

A low Int gain will make the controller ramp slowly to the desired speed.

This is not about timing the response for the motors to stop from a running position, but to change speeds. Stopping time may be faster due to several techniques like grounding to motors. I am simply interested in the controllers ability to control the motor with any step command, be it positive or negative.

Also, all this is in open-loop. I simply want to know how well the controller will respond. I close the loop on my own on the real-time controller.

Have you any documentation that can show that the 1 second delay is not "anywhere near right?" Have you tested this before? What is your response time? I am using the AX2850.

The reason I suggest to hit the stop button, is because this can be easily done with one click vs moving a slider in which case you don't always know for sure if it is your hand or the response that was slow.

Going to speed 0 is like going to any other speed in our case. Plus, because the AX2550/2850 does synchronous rectification, there is a "braking effect" when going from a high to a low speed. That braking effect is of similar strenght as accelerating from low to high speed.

One way to test the "go to speed" is with hyperterm or the Console tab in roborun and send speed commands manually. For example !a3F (go to 50%) followed by !a7F (go to 100%) then !a3F (back to 50%).

Response speed is - by design - 16ms max before a command is acknowledged and executed. In the case of "go to speed", the acceleration then kicks in, ramping from the current speed to the desired one more or less fast, but for sure much faster than 1s.

This has been tested and verified countless of times.

It may be that there is something wrong with this particular unit.

In order to isolate the problem, please do your test with roborun so that we are both looking at the same thing.

I did perform the test using roborun, and I could see the motors react, however I can't measure how quickly with the naked eye. The log file isn't helpful because it doesn't output the encoder counts, and even if it did it wouldn't give me a 16ms response time while using a 1s resolution.

Please explain to me how I should test this in roborun. I can zoom in the plot but there are no units of time. I can't tell by just watching it because (I hope) the response is a lot faster than what I can see with the naked eye. So what test should I try and how am I going to determine the response time?

As mentioned previously, the roborun capture is too slow to record this.

You would not be able to measure it without instruments (storage scope) and fancy triggering.

Depending on how heavy your motor is, you will feel it jolt if you step up/down the speed at max acceleration.

If so, there is something else causing the 1s delay that you have experienced before.

The theoretical values of 1 to 16ms reaction + acceleration should give you a pretty accurate number on how quickly the controller actually responds

This doesn't help me at all, especially since the real-time PC-104 I'm using is just as "fancy" as an oscilloscope with triggering.

I am frustrated in that I used my own hardware to show a 1s delay, then you ask me to use roborun, but then say it's to slow and that I should use other "fancy" hardware.

Can you show me any documentation (of the several tests you've performed) of the RoboteQ AX2850 responding within 16ms?

Or how else can I determine if this unit is faulty?

Please excuse my impatience, but I feel like I'm getting the runaround and would like to know it's performance. Surely it's documented!