running instances multiple times

Hello.

I have gone quickly through the PDF you sent me. The page numbers you reference in your description does not help -- the PDF only contains FB2 (181 pages). Are you aware that there is a forum dedicated to German speakers?

One repeating theme is the repeated FB calls, each with its own instance. It is not a big problem but it is a waste of resources. The program can be restructured to only have one instance. That includes motion control calls and call to FB1 and FB3.

(see picture above)
The central idea is to have a TRUE state on the "EN" pin. {In FBD that means leaving it open which is different than on the LOGO} The "Execute" pin (purple) should have the trigger that starts the movement. That would combine what is in purple and what is in red.

You will have a trigger1 / trigger2 / trigger3 / .. that goes through an OR to combine as a single trigger. One catch: there must be a one scan break between triggers. The "Execute" pin must see a OFF -> ON and ON -> OFF transition between triggers.

It is not clear to me why all the MC_MoveAbsolute is set to 0.0. I assume another process incrementally move the payload to various positions (FB1?). The fact that FB1 looses the true state on the "EN" causes problems also. The enable need to stay on.

I may not be available here for a while -- how do you wish to proceed?

Example sequencing concept coded in SCL:
How do you stop an axis with position accuracy in the case of product identification with the SIMATIC S7-1200?

Thank you so much for checking the PDF. You are right, I have accidentally sent the wrong PDF. I have resend the right one just now. 

I got your point and will try to restructure my code. I always had the presumption that it must be possible to do it with one STEP and not building the same many times. I will try the way you have said now!

The MC_moveAbsolute is initiating the travel back to the origin once the end of the slider is coming closer. Because every FB is just traveling forward so I have to get it back at some point

Again thank you so much, it is highly appreciated and really helps me!

m2thedoggy

Thank you so much for checking the PDF. You are right, I have accidentally sent the wrong PDF. I have resend the right one just now. 

I got your point and will try to restructure my code. I always had the presumption that it must be possible to do it with one STEP and not building the same many times. I will try the way you have said now!

The MC_moveAbsolute is initiating the travel back to the origin once the end of the slider is coming closer. Because every FB is just traveling forward so I have to get it back at some point

Again thank you so much, it is highly appreciated and really helps me!

Working through the PDF would have no meaning if you are making changes to the project.

True... If you find an easy solution to the problem I would leave the code as it is. 

Thank you!!!

So... I found a part of the solution. As you have qwazee, the enabling and trigger connection created the problem. Now the Enabling is empty and everything is connected to the in_trigger_start. I have now changed this and get the axis moving. However many other problems are now there but I think this is solvable. 

However, as qwazee has written it can all be solved in one network . I tried some ways but failed to do so. I will come back with a description of the problem shortly. 

m2thedoggy

<snip> I have now changed this and get the axis moving. However many other problems are now there but I think this is solvable. </snip>

One of those issues might be where you compare one REAL number with another REAL number. Better to compare with a small range. In SCL the code could be:

#atStop := ABS_REAL( #V1 - #V2 ) < 0.01;