Single FB running for 100 motors

Hi there!

I was wondering if it is possible to run a single FB for 100 motors at the same time without having to creat 100 instances of it? 

Not sure if I made myself cleared, for any doubts, ask questions.

Best Regards,

Rodrigo Domingues

If I got you right you wanted to use a single instance of an FB to run it multiple times and control multiple motors.

It's possible but at each call for next motor you must provide the instance with data specific for controlling that motor. Then you need multiple instances of the data and place to store them. I do not see any advantages over having multiple instances but there's one disadvantage - more coding.

What is your rationale to use such a solution ?

jacek d

If I got you right you wanted to use a single instance of an FB to run it multiple times and control multiple motors.

It's possible but at each call for next motor you must provide the instance with data specific for controlling that motor. Then you need multiple instances of the data and place to store them. I do not see any advantages over having multiple instances but there's one disadvantage - more coding.

What is your rationale to use such a solution ?

 The idea was more to run a single FB but controlling multiple motors at the same time. 

I have this program where the goal is to control/monitor several characteristics of 100 motors. 

I've created an UDT with those characteristics and after that I've created a DB where in it I created an array of 100 addresses(motors) with data type of my UDT. Then I created a FB where there's the code of what I want to do with those characteristics that belongs to those motors (Doesn't matter much)

Now comes my problem:
               
 Am I forced to create those 100 instances and map for each of them for their correspondant instances if I want them to run simultaneously? Or is there a way where I can create one FB and program can run on all 100 motors at the same time? 

Best regards,

Rodrigo Domingues

The question is if the FB requires retain data apart the UDT. If not, use an FC. Otherwise I'd use multiple instances.

BTW, specifying the PLC and the software you use might be important to give correct answers.

jacek d

BTW, specifying the PLC and the software you use might be important to give correct answers.

 The question is if the FB requires retain data apart the UDT. If not, use an FC. Otherwise I'd use multiple instances.

It needs. There for if the case is for 100 motors than I would have to use 100 instances, right?

BTW, specifying the PLC and the software you use might be important to give correct answers.

Yeah, I know but wouldn't be in this specific situation

RodDom18

The question is if the FB requires retain data apart the UDT. If not, use an FC. Otherwise I'd use multiple instances.

It needs. There for if the case is for 100 motors than I would have to use 100 instances, right?

 Yes.

RodDom18

BTW, specifying the PLC and the software you use might be important to give correct answers.

Yeah, I know but wouldn't be in this specific situation

If you know better.

Hi RodDom,

since I have done this before I would list my observations and suggested strategy here for your consideration as applicable in your situation or not.

I assume that the reason for this approach is the need to configure multiple devices with least effort as these come in large numbers (> 100).

I try to keep everything simple but would accept complexity if the benefits outweigh the additional effort to provide the functionality. In this scenario I would classify my motors as simple or complex. The simple motors would become devices in an array of devices in one DB. The complex motors would each have a FB with instance DB.

Each simple motor would have an index (the array index) that points to the structure containing all the motor data in the element of the array.  All motor parameters (control bits, status bits parameters and field switches) will be virtualized in the structure of the array.  Each device assignment would connect field inputs (running feedback, trip) with the virtualized bits in the structure. The outputs will be assigned in the same way.  The code will be written in such a way the assignments are only necessary for functionality that exists. Clear and compact selection of variable names (symbols) will create self-documenting code. No system timers or counter or even timer FBs will be used because these will require assignment for each instance. Timers will be simple pulse edge totalizers.

The code will sequentially load the structure of each device into local variables for logic execution.  The code must be optimized because every inefficiency will be multiplied by the number of devices.

Depending on your skill level I would start very small say 8 devices and simple fuctionality and once that works look at more detail of the requirement and develop.

Good luck!