Trinamic Discussion Groups

[shorton]

TMCM-110-42

Is there a way I can change speeds "on the fly" without stopping the motor, but still end up at a target position accurately and not have insatnd (max) acceleration?

It appears that with the MVP command I have to issue a MST before it will read a change in speed axis parameter.

If I use velocity mode, I don't seem to have control over how many steps I want at a particular speed.

So example I have to travel a distance of 30000. I would like to move at speed 100 for 0-2000, speed 500 for 2001-28000, and speed 100 for the last 28001-30000. Without stopping the motor, and with smooth accelleration ramps.

Can it be done in TMCL?

THanks, Scott

[Andrew]

You can mix MVP and ROL/ROR commands as much as you like. You change the speed or target position via axis parameters.
After doing so, you can still give more MVP, or ROL/ROR, or set the target position via an axis parameter.

You can switch from position mode to speed mode on the fly too. You are perfectly able to change speed, and still have an accurate destination. Even if you miss destination, the module will go back to it.
You can also change the speed in position mode on the fly.

... Just try everything...

Position count (parameter #1) remains valid in any mode. So you are not lost.

In position mode speed is set by parameter #4 "maximum positioning speed".
It can be set on the fly. Speed ramp will apply, as set by #5 "maximum acceleration".

In speed mode speed is set by parameter #2 "target (next) speed". The ramp still applies, as set by #5 "maximum acceleration". Speed limit also applies as set by #4 "maximum positioning speed".
If you set target speed greater than the limit in parameter #4, only the limit will be reached. Target speed will remain only a target. So, when you increase the limit on-the-fly, the speed would go up automatically. But not past the target speed.

All these parameters can be changed on the fly.

See also:
http://www.trinamic.com/ttdg/viewtopic.php?t=53
It has more discussion about mixing commands in direct mode and standalone mode.
_________________
Distributor of Trinamic
Our TMCM-DLL is here (not free): http://www.trinamic.com/ttdg/viewtopic.php?t=30 | Power supplies: http://www.trinamic.com/ttdg/viewtopic.php?t=394
On request: System integration services, custom programming, mechanics,etc

[shorton]

I tried MVP ABS, 0, 100
then changed max pos speed, then
MVP ABS, 2000

But there is no speed change.

I cannot physically overshoot my destination.

Can you give me an example of how to move as in my example"

[Andrew]

Speed must change on the fly, otherwise something is wrong.
Sometimes speed does not increase because acceleration is zero (you did not allow acceleration).

Speed also won't change while acceleration or deceleration already takes place. You would need to change the target speed for that in speed mode.

The case where you need not just alter the speeds, but to alter them at certain points is a more complicated.
MVP stops after any move.
But you wish not to stop.
As I wrote on the other theme to you, TMCM are very poor at setting the bottom speed. Perhaps this still could be done with builtin functionality, but I need to think more. I will report later.

Without using built in functionality, this could be done obviously by standalone programming in TMCL.

For example you may do polling. Once you arrive at destination, you change the speed.
But the precision of the moment of "speed change" depends on precision of polling.
Below I submit a sample program. It is based on a function WAIT. Internally in TMCM it still does polling, though at high resolution. I don't know what is the resolution of WAIT. Perhaps Trinamic should comment.

An interesting discussion on speed is here:
http://www.trinamic.com/ttdg/viewtopic.php?t=263

A discusssion more closely related to this topic is here:
http://www.trinamic.com/ttdg/viewtopic.php?t=106
It discusses the advantages of TMC chips (also of the modules based on the chips).
It describes the options for contiguous ramps without stop.
It is a bit technical, but it reveals the internals of TMC modules - the working of chips TMC428 and TMC246/249.
It displays an example of a ramp the sample program below might be used to produce. At each waypoint there would be a pause. The duration of a pause is a product of duration of a command (about 0.38ms) and the number of sommands that change speed on-the-fly.

Here is the sample program to change speed on the fly on arrival to target points without stopping.
It users target points as variables in bank #2. So that you can change them without changing the standalone program.
Keeping target points variable imposes a penalty of time to retrieve them from the bank. Extra commands - extra time.
You might save some time by sending the variables in direct mode, but then there's a delay of communication over the RS232, or other port.
Another way would be to store values for waypoints directly in TMCL program in EEPROM. But then every time you change them you would need to write to EEPROM, which would wear it out. Read here on the durability of EEPROM:
http://www.trinamic.com/ttdg/viewtopic.php?t=117
It also describes some details of using a Coorrdinates Array.
One more explanation there, is that command MVP in TMCM610 does not yet approximate for all axes to arrive at a waypoint simultaneously. It will be fixed in the future. In other modules MVP does arrive approximately simultaneously.

But the sample code below is for 1 axis anyway.

Speed of communication (for direct mode) and duration of a command is also discussed here:
http://www.trinamic.com/ttdg/viewtopic.php?t=53
It also contains some intricacies of mixing commands in direct mode and standalone mode... Should you mix this program with standalone operation.

GGP 12 2 0 //Get variable for Speed
AAP 4 0 0 //Put it in "v_max"
GAP 4 0 0 //See what controller has actually assumed for "v_max"
AAP 130 0 0 //Put it in also in "v_min", so deceleration won't occur
MVP 2 0 0 //Move to coordinate 0 (must be stored previously)
WAIT 1 0 0 //Wait for arrival

/*Motor has stopped temporarily and abruptly
Now we have to change the next target position and speed
Then we have to restart motion
If we are quick, nobody notices the pause*/

SAP 138 0 2 //Set ramp to Velocity Mode
GAP 1 0 0 //Get position
AGP 53 2 0 //Back it up at user bank #2 in variable #53
GGP 0 2 0 //Get the next target position from user bank #2
AAP 1 0 0 //Overwrite the current position (parameter #1)
CCO 0 0 0 /*Store it in coordinates array. We can put a variable to coordinates array only through axis parameter #1. Otherwise we could use UF1 to ask computer to upload a coordinade via SCO.
See UF1 (Active Communication) here:
http://www.trinamic.com/ttdg/viewtopic.php?t=480*/
GGP 53 2 0 //Get the backed current position
AAP 1 0 0 //Restore it
GAP 4 0 0 //Take the current v_max
AAP 3 0 0 //Put the v_max to actual speed. Motion restarts without a target, because we are still in velocity mode

/*The pause betwen stop and start: 0.38ms*10commands=3.8ms.
Motion now has restarted without any acceleration.
No deceleration either, because we are still in velocity mode
To avoid resetting "p" (see the BUG below) you can change the speed in position mode, without using "SAP 138 0 2" above. But then deceleration would ensue immediately*/

MVP 2 0 0 //Begin moving to a target a few lines above stored in CCO 0. Automatically switches to "position mode"

/*BUG: When switching from another mode to position mode, MVP recalculates variable "p" (pmul, and pdiv). This overwrites your custom values. Make sure you restore them before deceleration occurs.
If changing does not occur (e.g. not previously changed to speed mode), then these parameters remain unaltered.
Changing "p" during deceleration (on-the-fly) affects deceleration immediately. Perhaps TMC428 recalculates "p" at every step of deceleration, not just at the beginning of deceleration.*/

SAP 130 0 1 //This is the finish. Be quick to set v_min back to default 1. This command should be placed before MVP (and before AAP 3). But then the pause between motions is even greater
GGP 13 2 0 //Get next variabe for Speed
AAP 4 0 0 //Put it in v_max
STOP 0 0 0

[shorton]

Andrew:

I'm getting back to this and trying to follow some of your posts. You have a habit of referring to other threads (themes)> Then int eh other thread you refer back to several other threads including the one that you came from. This leads those of use trying to follow in circles <smile>. I understand you touch on the similar situations in the other threads, but they are not always 100% on topic to the particular question. At the least it's hard to follow when jumping in circles. I'm trying to tie some of them down.

Can you assist me in getting a handle on your post above, in this thread alone woudl be great .

Some of your last statements in the previous reply in this thread are confusing becasue they say they have to come before the other commands, but they do not. I'm sure I'm misunderstanding some point, but there it is.

Please, let's take my original example literally and work to do exactly that.
First, let assume this will be a static, standalone program, running in standalone
mode.

Edit: snipped original part of this post after this point. For clarity, see next post for replacement text and issues:

[shorton]

Andrew:

I'm continuing to try to disect your suggestion.

As I recall the original problem was that a pair of MVPs reguire a MST or the second will not work.

i.e.

[Andrew]

Well done Shorton!
Your last code is almost correct.
I am glad my lessons start bearing fruits.

As for the circular references. This is part of the learning process. I try to keep answers both general and specific. This requires lots of links. Obviously many problems may have the same solution. Or several solutions combined. I cannot afford repeating each solution separately.

[shorton]

Andrew: OK, thanks. Yes I didn't understand the point about restoring the previous speed due to the stop caused by positioning mode. Thanks for straightening me out on that, I understand now.

So now I have a 3 part move working. There were some waits missing above, here is a complete, functional, 3 part move, then a 3 part move back the other way:

[shorton]

Well, in implementing this I've found good and bad.

Good: I can set a minimum start speed. I've set it to some low value e.g:
10 of max 260 and I get a decent, quieter start with no/reduced growl, and no apparent accel curve.

Bad: If I try to use it for a full motion as in the example above, I get a very solid "bump" when it changes speeds. The transition from 0 back to the previous speed isn't happenign fast enought to prevent the bump. The "bump" can be felt and heard. That bump wont' be acceptable in my app. It isn't noticible at teh very low speed on ramp up, but it's clearly evident at a faster speed, even at low current .

[shorton]

This is the code that produces a hard bump in them middle of teh motion:

[Olav Kahlbaum (TRINAMIC)]

I see that you are setting the minimum speed (SAP 130) to the same value as the maximum speed (SAP 4). This causes something like a hard stop when the motor has reached the target position.
In your first move, your speed is low (speed1=10), but in your second move you are using a higher speed (speed2=260, so 26 times higher than speed1). I think that this causes the bump. Please try setting the minimum speed to a lower value in your second move.

[Andrew]

There's no sense in setting a speed mode just before the position mode MVP. You need to move that command anywhere closer to the preceeding WAIT. It would eliminate the initial dip of speed, after setting the current speed abruptly.

This of course does not cure the particular bump you have.

I suspect the bump occurs not just after the second move. But after each move. Beause all moves are too short, all of them never reach v_max=260 and v_min=260, or even speed 10. Just you do not notice the bump after the first move.
You correctly set the first v_max and v_min to a lower value of 10. But even this speed might not be achieved on a short move of 50 steps. So it still might cause a bump. Just you do not notice, because the speed is slow.

Just as I noted to you in our previous discussions, including in other threads. The distance you are trying to move does not allow you to accelerate to the v_max. So you are wrong to assume that the finishing speed was v_max or v_min. There's no point in restoring that speed.
You need to learn what actual speed to restore.

If all distances are fixed, I suggest you simply detect the speed at which the finish occurs, and try to restore that fixed speed.

Instead of trying to determine the finishing speed by reading it in an experiment, you may simply try and set different speeds on the bumped move, and see when the bump disappears.

Also you could calculate, what speed the controller has time to accelerate to, by using the formula for theoretical S.
(See the description of TMC428 about variable p, or the other thread:
http://www.trinamic.com/ttdg/viewtopic.php?t=263)
But as I noted there, the formula is not correct. Still you could try to use it for approximation.

If you have variable distances, then you cannot easily detect the actual finishing speed on the fly. Then I would recommend to implement my suggestion for speed mode. Speed would change around each waypoint with a certain precision, but at least with an invariable repeatability.

Note that in my suggestion for speed mode you can insert any code into the detection loop. For example insert the earlier mentioned UF1 function to report the arrival to the computer. TMCL-IDE will not be able to deal with that report. But a custom software, like my DLL, would.

[shorton]

[shorton]

Andrew:

[Andrew]