changing speed within move

[gbynum]

I’ve a client for whom I’ve installed several RMC100’s who has asked for 2 more on a different application. This one happens to be driven by a rotary actuator which turns a maximum of 180 degrees. The components were preselected; I’ll have absolute SSI feedback with about 4000 counts over my range. It is replacing an existing system which used traditional bang-bang directional valves and a cam operated flow control to change speeds in one direction; all I will get are a forward and reverse command.

Hard numbers will be determined at commissioning, but what it looks like is that the axis will drift out of position SOME between uses (every 10 minutes to 2 hours, commonly). I’ll ASSUME home to be at 1000 counts and that the move will be to 5000 for this discussion. I’ll again ASSUME the position to which it drifted is 1200 counts.

My first command will be retract to 1000. At present, I don’t know if this will be a maintained after external feedback confirms that was completed. As long as I don’t undo the move, drift while the machine cycle begins will not matter, so loss of the signal won’t hurt. The next command will be extend to 5000. During this move, I must make 1 or more speed changes at approximate (+/-100 counts is MORE than sufficient) positions. The first speed value is insignificant, indeed it will be programmed in excess of what is available (the actuator wears, and they’d like maximum available speed which will be higher with a more recently rebuilt unit than with a more worn unit. At the transition point, the desired speed will definitely be within control range; I only anticipate 1 lower speed, but my numbers following will show 2 to cover my hindside. The total move requires about 20 seconds giving me an average count rate of 200 counts per second. So, a move table will be something like this.

Step 1, “home”, move to 1000

Step 2, “away”, move to 5000
1000 to 3000, 600 counts/sec (expect to get only 400-550 week in week out)

Within step 2, 3000 to 4000, 150 counts/sec (expect easily to get this; issue I see is following error WILL be high {and vary} at transition and I don’t want to let integral accumulation significantly change the transition point)

Within step 2, 4000 to 5000, 120 counts/sec with PERHAPS a deceleration ramp to a stop … that is not required as external feedback (a proximity switch, if it matters, to the system logic controller) will drop my “away” (and “RUN”) signal before it would stop anyway, ASSUME at 4900.

Step 3, repeat Step 1. After this is completed, I lose motive power (the hydraulic unit is shut down)

While they emphasize smoothness, I think that the worst I can do will be 100 times better than what they want; the only issue is to not speed up at position 3000 or 4000.

The previous systems done there used 1 input which went to CPU In0, the Run/Stop. CPU Out0 sourced DIO 0 in an input to event mode for the single “move” by 2 axes. I’ll have, as I’m planning it, just 2 moves and one axis. They presently have 115VAC signals, so there will be relays added; I presently am considering using 2 poles on the “home” and “away” relays, one to energize CPU0 and 1 to select a unique input. I believe the input to event must be delayed until acknowledgment; I’ll source the move unique relay contacts from this then into (perhaps) DIO input 1 and DIO input 2 to select a step within the event.

Am I either overestimating capability, or going around my elbow to get from finger to thumb? Changing speeds on the fly is the “fly” in the ointment. I don’t NEED positions except to change speed … including at the end of travel. Thoughts are solicited.

NOTE: I realize the RMC70 would probably be the better choice for this application … customer wants to stay with what they know.

[Peter_Nachtwey]

@gbynum

Hard numbers will be determined at commissioning, but what it looks like is that the axis will drift out of position SOME between uses (every 10 minutes to 2 hours, commonly).

It shouldn’t drift at all unless power is off or in open loop mode. Blocking valves that shut when power is off will keep the actuator from moving.

Step 1, “home”, move to 1000

Step 2, “away”, move to 5000
1000 to 3000, 600 counts/sec (expect to get only 400-550 week in week out)

Within step 2, 3000 to 4000, 150 counts/sec (expect easily to get this; issue I see is following error WILL be high {and vary} at transition and I don’t want to let integral accumulation significantly change the transition point)

The integrator shouldn’t wind up if you use feed forwards.

Within step 2, 4000 to 5000, 120 counts/sec with PERHAPS a deceleration ramp to a stop … that is not required as external feedback (a proximity switch, if it matters, to the system logic controller) will drop my “away” (and “RUN”) signal before it would stop anyway, ASSUME at 4900.

This isn’t clear but you can change speeds on the fly using an input.

Step 3, repeat Step 1. After this is completed, I lose motive power (the hydraulic unit is shut down)

While they emphasize smoothness, I think that the worst I can do will be 100 times better than what they want; the only issue is to not speed up at position 3000 or 4000.
[/quote]

The previous systems done there used 1 input which went to CPU In0, the Run/Stop. CPU Out0 sourced DIO 0 in an input to event mode for the single “move” by 2 axes. I’ll have, as I’m planning it, just 2 moves and one axis. They presently have 115VAC signals, so there will be relays added; I presently am considering using 2 poles on the “home” and “away” relays, one to energize CPU0 and 1 to select a unique input. I believe the input to event must be delayed until acknowledgment; I’ll source the move unique relay contacts from this then into (perhaps) DIO input 1 and DIO input 2 to select a step within the event.

There isn’t a PLC in this.
You don’t need to acknowledge transitions unless your application requires it.
This is confusing because I don’t know your application. It would be better if you just said what you want CPU IN 0, CPU IN 1 to trigger.
Do you know you edit *.st1 files and cut and paste them into a forum post? st1 files are just text files.
It is possible to change speed speeds on-the-fly and to trigger the speed change with a digital input. However, the speed you want to change to must be pre programmed into the step table as it doesn’t sound like you have a PLC or HMI from which you can change parameters or speeds.

Am I either overestimating capability, or going around my elbow to get from finger to thumb? Changing speeds on the fly is the “fly” in the ointment. I don’t NEED positions except to change speed … including at the end of travel. Thoughts are solicited.

Like I said, this shouldn’t be a problem if you can pre-program the speed.
It is also possible to use an input to ramp down the velocity a little bit with each successive pulse.

NOTE: I realize the RMC70 would probably be the better choice for this application … customer wants to stay with what they know.
[/quote]

[gbynum]

@Peter Nachtwey

@gbynum

the axis will drift out of position SOME between uses (every 10 minutes to 2 hours, commonly).

It shouldn’t drift at all unless power is off or in open loop mode. Blocking valves that shut when power is off will keep the actuator from moving.

It is an internally leaking actuator … not valve or control issue

@Peter Nachtwey

This isn’t clear but you can change speeds on the fly using an input.

ok …

@Peter Nachtwey

This is confusing because I don’t know your application. It would be better if you just said what you want CPU IN 0, CPU IN 1 to trigger.
It is possible to change speed speeds on-the-fly and to trigger the speed change with a digital input. However, the speed you want to change to must be pre programmed into the step table as it doesn’t sound like you have a PLC or HMI from which you can change parameters or speeds.
Like I said, this shouldn’t be a problem if you can pre-program the speed.

I will receive ONLY TWO inputs from the system which I am calling “home” and “away”. There is nothing else available. The possibility of overlap need not be considered.

“home” must give a command of one polarity. While some type of velocity control would be nice, it isn’t necessary. This command will be dropped by the machine control logic and the command should go to approximately zero.

“away” commands the work direction. What is desired is the maximum, pump limited, velocity which will vary with the age of the actuator and how much wear (internal leakage) has occurred until the feedback reaches a preprogrammed position_ then smoothly go into a programmed closed loop speed. There is a possibility that additional speed changes will be desired at further positions. This command will be dropped by the machine control logic and the command should go to approximately zero.

I thought that I had a way to turn on an output at a position within a move but don’t see it; via that, I could use the output into an input to accomplish the speed change you mention. I need to review the help to learn how to include an image.

[Jacob_Paso]

As I understand it, you would like to do the following:

1. When the Away input turns on, begin moving at full velocity.
2. When the axis reaches position a, enter closed loop control at a certain speed.
3. When the axis reaches position b, enter closed loop control at a certain speed.
4. Stop at 5000 counts.

, where there may be more or fewer velocity-change positions than a and b, and where positions a and b and c, etc. are less than 5000 counts.

Is this correct?

If this is correct, it is a very easy application. In the Input to Event Editor, simply set up CPU input 0 to start an Event Step sequence that does the Away move as follows:

Step 1: Open Loop command with 10 volts. Link Type is Absolute Limit Switch at the position you wish to change to a velocity.
Step 2: Go command to 5000 counts with the specified velocity. If you have more setpoints at which to change position, then the Link Type should be Absolute Limit Switch again at the next position you wish to change the velocity.
Step 3: Similar to step 2 as many times as you need to change the velocity.

For the away move, in the Input to Event Editor, set up CPU input 1 to start an event with a single step that issues a Go ccommand to your home position.

[gbynum]

@Jacob Paso

As I understand it, you would like to do the following:

1. When the Away input turns on, begin moving at full velocity.
2. When the axis reaches position a, enter closed loop control at a certain speed.
3. When the axis reaches position b, enter closed loop control at a certain speed.
4. Stop at 5000 counts.

, where there may be more or fewer velocity-change positions than a and b, and where positions a and b and c, etc. are less than 5000 counts.

Is this correct?

Close enough … stop will occur when the Away input is dropped.

@Jacob Paso

If this is correct, it is a very easy application. In the Input to Event Editor, simply set up CPU input 0 to start an Event Step sequence that does the Away move as follows:

Step 1: Open Loop command with 10 volts. Link Type is Absolute Limit Switch at the position you wish to change to a velocity.
Step 2: Go command to 5000 counts with the specified velocity. If you have more setpoints at which to change position(GBYNUM assumes you meant velocity here), then the Link Type should be Absolute Limit Switch again at the next position you wish to change the velocity.
Step 3: Similar to step 2 as many times as you need to change the velocity.

For the away (GBYNUM assumes you meant home here) move, in the Input to Event Editor, set up CPU input 1 to start an event with a single step that issues a Go command to your home position.

That is as simple as I expected. What I missed (and caused me to not see the link type was (DUMB ME) not changing from System Wide to Current Axis.

I ASSUME? that I could avoid the open loop move and request a velocity higher than attainable with the Absolute Limit Switch used to transfer out of it if I’d like to keep the safety features per “Open Loop operation disables all safety features on the RMC!” If I don’t have integral, there can be no windup which is a problem I foresee with it.

THANKS! (Do I even need a communication module? The previous system did to delay command from CPU input 0 until ready.)

[Peter_Nachtwey]

I ASSUME? that I could avoid the open loop move and request a velocity higher than attainable with the Absolute Limit Switch used to transfer out of it if I’d like to keep the safety features per “Open Loop operation disables all safety features on the RMC!” If I don’t have integral, there can be no windup which is a problem I foresee with it.

We have a special “quick move” command that runs open loop during the first part of the move but is always checking to see when it must ramp down in closed loop to get to a position. Try it, I think you will like it.

THANKS! (Do I even need a communication module? The previous system did to delay command from CPU input 0 until ready.)

[/quote]
No, if all you need is two inputs and two outputs.

[gbynum]

I really appreciate your help … the customer has given us the order with a DIO in it … if we can save a few bucks, it will be REALLY nice. What they have now is a standard “all ports blocked” directional valve, equivalent to a Rexroth 4WE6E or Vickers DG4V3S2C. In one direction there is a cam operated pressure compensated flow control, the other substantially no control, pump flow limited. The problem is that the actuator wears internally and the speed varies with “angle”; they constantly file or shim the cam to get by. Closing that loop is the goal, but +/-20% is likely good enough. We’re using a Rexroth 4WREE6E16 for the application. Note that there is NO position control involved, only position “sensitive” velocity changes, and those only in one direction.

@Peter Nachtwey

We have a special “quick move” command that runs open loop during the first part of the move but is always checking to see when it must ramp down in closed loop to get to a position. Try it, I think you will like it.

I don’t see it in the list, RMCWin 2.30.0; where can I find any documentation.

THANKS! (Do I even need a communication module? The previous system did to delay command from CPU input 0 until ready.)

@Peter Nachtwey

No, if all you need is two inputs and two outputs.

Now I’m confused severally … The RMC “simulate” APPEARS to require one. I need only 2 inputs, zero outputs. Are you suggesting that as simple as this would work, obviously after tuning? The exit from steps 3 and 11 will be loss of the input. When an input drops, I simply want to open loop stop, so use the falling edge to go to another step; the editor assigned that to inputs 16 and 17. I didn’t program step 21 below, but it will be trivial.

;INPUT # AXIS0
[INPUT] 0 1
[INPUT] 1 11
[INPUT] 16 21
[INPUT] 17 21

; STEP# MODE ACCEL DECEL SPEED POSTION COMMAND AXES TYPE VALUE INDEX COMMENT
[STEP] 1 0000C 200 200 0 10000 o 001 l 3000 2
[STEP] 2 0000C 200 200 250 5000 g 001 l 4000 3
[STEP] 3 0000C 200 200 150 5000 g 001 0 0 0
[STEP] 11 0000C 500 500 0 -10000 o 001 0 0 0

[Peter_Nachtwey]

@gbynum

I really appreciate your help … the customer has given us the order with a DIO in it … if we can save a few bucks, it will be REALLY nice.

It looks like inputs 16 and 17 were used for something at one time but they would cause step 21 to execute. You didn’t provide any step information for step 21 so maybe it isn’t used but you should check. It could be that inputs 16 and 17 are the falling edge entries in the input to event table for inputs 0 and 1. There should be a step 21 that issues an open loop command with a 0 volt output to stop. This would mean Input 0 executes step 1 on a rising edge and step 21 on a falling edit. Input 1 executes step 11 in a rising edge and step 21 on a falling edge. I am pretty sure this is how it worked before.

What they have now is a standard “all ports blocked” directional valve, equivalent to a Rexroth 4WE6E or Vickers DG4V3S2C. In one direction there is a cam operated pressure compensated flow control, the other substantially no control, pump flow limited. The problem is that the actuator wears internally and the speed varies with “angle”; they constantly file or shim the cam to get by. Closing that loop is the goal, but +/-20% is likely good enough. We’re using a Rexroth 4WREE6E16 for the application. Note that there is NO position control involved, only position “sensitive” velocity changes, and those only in one direction.

I understand now.

@Peter Nachtwey

We have a special “quick move” command that runs open loop during the first part of the move but is always checking to see when it must ramp down in closed loop to get to a position. Try it, I think you will like it.

I don’t see it in the list, RMCWin 2.30.0; where can I find any documentation.

THANKS! (Do I even need a communication module? The previous system did to delay command from CPU input 0 until ready.)

@Peter Nachtwey

No, if all you need is two inputs and two outputs.

Now I’m confused severally … The RMC “simulate” APPEARS to require one. I need only 2 inputs, zero outputs.
[/quote]
Then you don’t need a communication module. If you only need the 2 inputs.

Are you suggesting that as simple as this would work, obviously after tuning?

This should be simple but you need to program step 21 to issue a open loop 0 volts on the falling edge…

The exit from steps 3 and 11 will be loss of the input.

We cannot control the input, but you can use an output to signal when done.

When an input drops, I simply want to open loop stop, so use the falling edge to go to another step;

Note, If you look in the right side of the tool bar in the input to event editor you will see a buttons to select either the rising or falling edge parts of the input to event table.

the editor assigned that to inputs 16 and 17. I didn’t program step 21 below, but it will be trivial.

Good. BTW, there is a V and v command that allows you to just change the velocity. All that is required is the speed in the command value and the command V in the command field. This command assumes the axis is already moving and the V command just changes the velocity. The position, accel, decel and mode from the previous G command are assumed.