(CANCELLED) Difficulty replicating S7-200 motion accuracy on S7-1200

Hi-ya all,

We use the motion control on the S7-1200 extensively - but up to now in applications that did not need accuracy when motion is interrupted.

I am hoping to reach out to somebody that uses the motion control on the S7-1200. There is an application functionality that is possible with the S7-200, that is now giving trouble on the S7-1200.

What follows is some notes on what we tried and the result we got. Sorry, I can't share the program.

Maybe there is someone that is willing to contribute a design idea that may help. As the S7-200 is obsolete, the alternative to the S7-1200 is a non-Siemens PLC.

APPLICATION DESCRIPTION
* A stepper motor is driven by a frequency pulse (PTO).
* The motor is started when when the START button is pushed.
* The motor ramps up with a preset acceleration to running speed (linear = 300mm/s).
* An input triggers the stop - hardware interrupt is used.
* The motor ramps down to standstill.

SYMPTOM
A variation to the stop position is observed when using the S7-1200 with its motion control. The S7-1200 was changed with an S7-200 as a controlled check. The S7-200 delivers a total variation of 0.4mm (smaller than 1mm is okay). The S7-1200 however delivers a variation of 2.4mm (up to 4mm has been reported but not confirmed). The variation from the S7-1200 seems to increase from one feed to the next and then reduce to original "zero".

IMPLEMENTATION (How it was programmed in the S7-1200)
NOTE: S7-1200 FW4 with all inputs set to 0.1us filter period. Bare minimum program with no HMI and no network traffic. The motion profile used on the S7-200 was replicated on the S7-1200 for the test.

[Variation 1]
* Start the motion with MC_MoveRelative. Requested distance is more than maximum travel distance.
* When the stop input is made, a hardware interrupt is called.
* The hardware interrupt calls the MC_HALT function.
* All motion control blocks in the OB1 scan are "blocked" while motion is taking place. This is done to prevent a motion control calls being interrupted by the hardware interrupt.

[Variation 2]
* Start the motion with MC_MoveVelocity at 300mm/s.
* When the stop input is made, a hardware interrupt is called.
* The hardware interrupt calls the MC_MoveVelocity set to 0mm/s.
* All motion control blocks are "blocked" while motion is taking place. (see note above)

[Variation 3]
* The same as Variation 2, but no hardware interrupt used.
The best result was delivered by Variation 3 but not even close to the result given by the S7-1200.

[Variation 4]
* Replace stepper driver & motor with servo amplifier.
* Servo amplifier set to speed mode with internal speed setpoint.
* S7-1200 gives enable and "run".
* When the stop input is made, a hardware interrupt is called.
* The hardware interrupt gives the servo amplifier a "stop" signal - set Q0.2:P.
Result: Random variation of more than 3mm.

---
Any ideas from someone on what to try to get the S7-1200 to do the task?

Thanks for your interest.
w

huggy_d1

If you are putting your slow acting control code in a task that runs periodically, say every 10 ms, and put your motion control triggers in something called every 1 to 2 ms, you should be able to improve motion control without adversely affecting overall scan time.

The key is to basically histogram your process and optimize the logic to provide nearly immediate response to input and position changes.

If this has already been tried, please add that variation.

huggy_d1,

Always good to see your friendly face. Thank you for your interest.

I have considered that approach.. and dismissed it. Reason: all (most) code called from OB1 is jumped over as soon as the motion is being executed - with the exception of the code that brings the motion to a halt. Even without this measure the PLC scan is 1ms yet the variation to the stop is equivalent to 9ms.

As you have made this suggestion I will try it (thank you).

Greetings.
w

Hallo try this:

1. use home to set Position to -1000000.0
2. start move_absolute to a target >0.0
3. use home with flying positioning with position 50.0mm

This will cause the drive will make 50.0mm and stop after the signal.
If the "50.0" are to short the drive may reverse,

There will be a FAQ (ID 109477583)  for this. Middle of July in German and end of July in English.

miami

Hallo try this:

1. use home to set Position to -1000000.0
2. start move_absolute to a target >0.0
3. use home with flying positioning with position 50.0mm

This will cause the drive will make 50.0mm and stop after the signal.
If the "50.0" are to short the drive may reverse,

There will be a FAQ (ID 109477583)  for this. Middle of July in German and end of July in English.

 

@miami:

Thank you for your interest. In my case reversing is not an option. But I think I know where you are "moving" to with your suggestion. I'd sure would like to see that FAQ one month from now.

----
@huggy_d1:
We did not test the full extend of your proposal, as we went with an alternative that works. I will look into your idea at a later time.

---
UPDATE:

(opinion)
Personally, I am disappointed that we could not use the same design concept from the S7-200 for the S7-1200. The trouble is that there is not a repeatable stopping distance when the motion control is asked to come to an "unscheduled" halt. Calling motion control blocks in a hardware interrupt does not help the situation.. it makes it worse. It has to do with the fact that the S7-200's motion is hardware based and the S7-1200's motion control is software based.

This subject (for me) is closed as we have made changes to our system to overcome the shortcomings we encountered with our original design - it will do for now.

w

As an after thought for those who were thinking
of triggering motion control from an interrupt.

Quoted from the system manual..

S7-1200 Programmable controller System Manual,
01/2015, A5E02486680-AH, page 540

Note
The CPU calculates motion tasks in "slices" or segments of 10 ms. As one slice is being executed, the next slice is waiting in the queue to be executed. If you interrupt the motion task on an axis (by executing another new motion task for that axis), the new motion task may not be executed for a maximum of 20 ms (the remainder of the current slice plus the queued slice).

Hello All,

I gave it some more  thoughts and found simple enough solution. This solution is not about stopping as fast as possible but stopping precise as soon as possible

So ... Use your sensor input to reference axis on the fly. Its possible to do inside an interrupt. By doing so you will pick exact position of the system.

Then, once in regular cycle, use absolute move positioning to stop as soon as possible - meaning move to near coordinate.

This way you will always stop at exact and same position. It will take a bit more time but as much as i can say it will be good for most of the application.

Examples would be labeling and stopping the label at same position, positioning tube before sealing, positioning bottle before capping and similar. ( you can see that I'm in packaging business )

Other systems need to make fast stop to be exact but this will allow to stop in time and be exact about it.

Problem I did not find solution to is starting motion control motor at random signal. It causes similar problems as discussed before.

Regards