Siemens S7 - how to handle multiple tasks with slow PLC and don't lose data

[bigplik]

Hi, I heard about some strategy that we can use even slow version of PLC to make a lot of data calculations,
which could be too much for particular PLC, but for eg. if you use "data buffer in TIA Portal" we don't lose any data
on the loop.

However I couldn't find enough explanation article about that data buffer.

I appreciate your information in this case.

[5618]

I'm not particularly proficient with Siemens. This is a general PLC statement. What comes to my mind by your description is working with arrays of data. The ideal solution might be a FOR loop that cycles through the entire array performing one or more operations on each data point. Depending on controller capability, array size, and complexity of the operations, this could take too long and trigger a watchdog fault or hold up other time critical operations.

For that scenario, hopefully the values aren't critical enough that the index could be incremented by just one each program scan (or maybe several loops each scan), operating on just part of the array at a time. The feasibility of that depends on the application and the program structure.

If you're not talking about arrays of data, just complex operations on one or a few data points, I would be surprised if your controller actually has a problem with that. Even a few milliseconds is not typically too long to cause issues. If the process is that time critical, it's the wrong controller for the application.

Another scenario that comes to mind is using an external source to run calculations. We use a specialized program running on a PC that controls a process with many more inputs than any PLC PID. The process isn't entirely dependent on the external source for production, but it does allow for greater and more efficient throughput.

Edited January 23 by 5618

[Parky]

Not S7 but the older S5-155 there was a system that the original programmer generated a massive DB on startup (if it did not exist) what it did was act as a buffer for a printer on a critical process so if the printer ran out of paper or jammed the data was stored in the DB as a buffer, later the printer was replaced with a logging connection to the higher level system, what the programmer did was on PLC startup it checked the availlable memory, generated a DB as big to fill the memory, it did mean that no edits on-line could be made as there was no memory left. I only found out about it while I was on site on a different project & they lost the prograsm due to a failed main rack (batteries were held in this) they tried to re-load but it said not enough space, I was called over to see what I could do & found out the reason the engineers there uploaded the progam to the backup file at some point & the massive DB was uploaded with it. tuns out had to delete the DB download the rest then do a cold start & then a warm start to generate the DB. the program was well written however, they used absolute jumps to jump over segments (can only jump within segments upto 255 with relative addresses, so very difficult to do any mods as you would need to write down the original addresses & change the jump address accordingly perhaps that is what is meant use a DB as a buffer to send data to a higher level so as not to loose critical data, I doubt any reasonably large processor would not have enough time to do most of the processing. As pointed out many complex calcs or movement of data could possibly be done over a few scans. to reduce the load.