Structuring DB - your opinions wanted

[knutfh]

I'm refactoring a task handling system that creates transport tasks to shuttle wagons in a material handling system. My environment is S7.

Wanting to settle the data model first, I thought I'd ask you guys for your opinion on one specific issue.

This is regarding how to structure the data for individual locations grouping lanes and destinations specifically - how to number them.
I also want to make the new solution more adaptable to other aisle configurations

Background information
The system consists of

• Buffer lanes (green)
• Grouping lanes (red)
• Destinations (ocre)
• Shuttle wagons (blue) - operating in aisles

The task system checks each buffer lane to see if there's a load unit (LU) there, and if it has a new destination.
If a destination exists, it should find a location in the grouping lanes closest to the destination, trying to group the LU together with other LU's with the same destination.

That's the gist of how this system works.

How is the data structured today?
Like alternative 1.

There are 80 buffer lanes, and all addresses for grouping lanes and destinations are based on where they are relative to the buffer lane.

In all cases the iteration is made on the largest range:

FOR lane 1 TO 80 DO...

Pros
Makes it very easy to find the right grouping lane.
Start with the grouping lane nearest the destination and work from there.
Cons
Illegal grouping and destination addresses must be dealt with. E.g. grouping lane 1-4 and 19-27 and so on. These do not exist.
Looping over lanes that does not exist costs cycle time.

Alternative solution
Like alternative 2 in the attachment. Number each location category starting with 1.

Pros
Iterate only over existing lanes - less work.
Easier to scale code to different aisle configurations. I can just pass an INT with the number of lanes in each category when making a new instance of the task system.
Cons
Does require a parameter for each position that relates the grouping and destinations to the buffer lane to do optimal grouping I'm not sure how CPU intensive a lookup operation would be.

In all, the cycle time of the CPU is very high as it is today, and one of my goals is to reduce the number of operations to improve cycle time.
The existing system has been extended and changed several times during commissioning, and there's big room for cutting down and streamlining the whole process.

Which of these two approaches would you gravitate towards, and why? Should I consider other options?

 

[Manglemender]

I can't really comment on your approach it it is beyond my experience but i was wondering about your cycle time issue. Two things spring to mind:

1: Are you using S7 Graph for sequencing? This is very processor intensive.
2: Are you passing UDTs to block for processing? When you pass a UDT into a block, the pointers are recreated for every access to the UDT within the block; while this is a neat solution it is also very processor intensive.

Nick

 

[knutfh]

1: Are you using S7 Graph for sequencing? This is very processor intensive.

No, S7 Graph is not used in this project at all.

2: Are you passing UDTs to block for processing? When you pass a UDT into a block, the pointers are recreated for every access to the UDT within the block; while this is a neat solution it is also very processor intensive.

Yes, UDTs are being passed quite a lot. I did not program this system in the first place, but the programming style varies from area to area depending on which of the project programmers made that part of the program. But for this part of the program UDTs are used a lot.

The cycle time varies between 78-200 ms with the average at about 100 ms.
This is with an 416F-3 PN/DP CPU.

Is there a quick way to figure out where the cycle time is accumulating other than manually calculating the execution time for each instruction of the program?

 

[Manglemender]

The only thing I can think of for the cycle time is to stop it executing sections of code and see the effect on cycle time or you couls allow the processor to only execute a section of code to what that takes.

Nick

 

[adfox]

Are You using lots of loops ?
Try making those loops incement with cycle scan.

 

[mk42]

If cycle times are getting long, it may make sense to break the code into a few different cyclic interrupts, for different priority code, or to only process a few iterations of the loop each cycle. It really depends on your process, and how fast different sections of code need to execute.

If there are lots of UDT's being passed around as inouts, it can often make sense to buffer them into local memory as a temp value, or potentially as a STAT, so that you don't need to worry about all the direct pointer accesses. YOu can copy it in at the beginning, and then copt it back out at the end. Obviously, this only works if nothing else could be changing the original data source while the code is executing.

In the 300's and 400's, I've seen programmers use the TIMETICK (SFC64) instruction to calculate the time it takes to run a section of code. Call TIMETICK before and after the code, and take the difference of the values. The result is the number of milliseconds it took to execute, although you do need to check that it didn't roll over from 2147483647 back to 0.

 

[knutfh]

In the 300's and 400's, I've seen programmers use the TIMETICK (SFC64) instruction to calculate the time it takes to run a section of code. Call TIMETICK before and after the code, and take the difference of the values. The result is the number of milliseconds it took to execute, although you do need to check that it didn't roll over from 2147483647 back to 0.

Thanks for the suggestion. I'll try SFC64 and see what I get.

I appreciate all feedback regarding cycle time. The cycle time will most certainly improve a bit when refactoring this part of the program anyway, but otherwise there is nothing that time critical going on. The parts that are time sensitive are already handled in cyclic interrupts.

It was not my intention to create another thread about optimizing and analyzing cycle times.

Does someone have any feedback regarding the data structure?

 

[L D[AR2P#0.0]]

When you say you want to make it more adaptable to other aisle configurations, do you mean more/less than 80 buffer lanes, or is it just the number/locations of grouping/destination lanes that would change?

Have you considered a CPU change - a 417 will give you approx 0.75 of your existing scan time.

 

[knutfh]

When you say you want to make it more adaptable to other aisle configurations, do you mean more/less than 80 buffer lanes, or is it just the number/locations of grouping/destination lanes that would change?

The number of all location types would change. We have many shuttle wagons in our plant and they are all mechanically similar, but the aisles are all different. Only some aisles have grouping lanes. The one in my example is the most complex. All others are smaller than this by a good margin.

Have you considered a CPU change - a 417 will give you approx 0.75 of your existing scan time.

We have an 416F today. As far as I can tell, Siemens does not offer the 417 as a fail-safe CPU?

There is also a desire to only have one spare CPU in stock - we have eight 416F's in the system.

But then, cycle time is not causing any trouble, but it would be nice to have more headroom.

Why refactoring?

• Existing code is not documented.
• Very sparse comments in line, mostly not in English.
• Confusing program structure unless you know it really well.
• Requirement changes during design and commissioning has left us with a patchwork program.
• We have undesired behaviour due to bugs that causes major downtime.
• Business requirements has changed for some of the aisles.
• Task for all aisles are handled differently today. New requirements make it possible to use the same logic everywhere.
• We have a need for better HMI and intervention possibilites.
• The already fragile and complex system will only become more fragile and complex by trying to adapt it to fit our new requirements.

All the best,
Knut

 

[TurpoUrpo]

Is the safety part how big? I believe that cycles close to 200ms are due to safety program execution. In TIA one can divide safety program execution on multiple parts so that impact on execution is smaller in any given cycle, but i dont remember is it the same for Classic Step7 too.

 

[mk42]

Is the safety part how big? I believe that cycles close to 200ms are due to safety program execution. In TIA one can divide safety program execution on multiple parts so that impact on execution is smaller in any given cycle, but i dont remember is it the same for Classic Step7 too.

You can have 2 safety runtime groups in Simatic Manager as well. This allows you to run some safety code at a high interrupt and safety code that requires a slower reaction time at a slower interrupt. This is mostly used in the process world to separate system/plant safety valves that run off slow analog modules from faster personal safety devices like light curtains or Estops.

 

[MichaelG]

Back to your original post

A couple of questions
(using the first numbering method)
1) The shuttles can move independently?
2) The shuttles cannot pass another shuttle on the track? It means that lane 1 buffer that needs to end up in lane 80 buffer must be double handled (eg passed along the shuttles)
3) Product can appear in any buffer lane and have to go to any destination?
4) Transfer Times for any shuttle are identical? (not the move time along the track just the load/unload time)


It looks like a delivery sorting warehouse - trucks dropping off parcels that have been picked up and re-sorting for loading onto a truck for delivery.
It also has preload storage if the destination (truck) is not ready.