Davide Nardella

If you don't have an empty PLC, ask the PLC programmer to skip OB1 for some minutes and connect your PC directly to the PLC PN Port.

Currently, it is set to 2000. Increasing it obviously improves the situation this is not good news, if at 2000ms you have more problems than 3000ms it means that, statistically, some transaction takes 2500ms, and this is unacceptable. In our high productivity lines we use Snap7 (of course ;-) ) and the maximum time we record is 500ms for a complete transaction (PLC->SQL->Feedback to PLC) in a wired network, more than that we cannot tolerate. 10/15 ms is the maximum time you should expect. Possible...

Hi Laura, These problems are also common in WinCC, it seems that they depend on the communication queues inside the PLC that have become very complex over time. You can act on the communication priority, but it depends on the use you make of your automation, it may not be the most efficient way. (In my opinion, the communication load should never affect the CPU cycle time) Or, as WinCC does, you can mask the problem: in case of TCP error, disconnect the client, then at the next turn of your communication...

Hi Laura, These problems are also common in WinCC, it seems that they depend on the communication queues inside the PLC that have become very complex over time. You can act on the communication priority, but it depends on the use you make of your automation, it may not be the most efficient way. (In my opinion, the communication load should never affect the CPU cycle time) Or, as WinCC does, you can mask the problem: in case of TCP error, disconnect the client, then at the next turn of your communication...

Hi Laura, These problems are also common in WinCC, it seems that they depend on the communication queues inside the PLC that have become very complex over time. You can act on the communication priority, but it depends on the use you make of your automation, it may not be the most efficient way. (In my opinion, the communication load should never affect the CPU cycle time) Or, as WinCC does, you can mask the problem: in case of TCP error, disconnect the client, then at the next turn of your communication...

Very interesting. Never tested in production with Windows 11. Can you send me, please the source code of your changes ? thanks (in "about me" in the site you can find the mail) or tou can contact me in Linkedin (Davide Nardella)

public static void DBRead() { TestBegin("ReadArea()"); int Result = Client.ReadArea(S7.S7AreaDB, DBSample, 0, DataToMove, Buffer); if (Result==0) { System.out.println("DB "+DBSample+" succesfully read using size reported by DBGet()"); } TestEnd(Result); } this function does not show anything, only reports ok or not ok. Please, if you are a programmer, look into the code ;) then, as I wrote, size reported by DBGET is wrong because uses an unsupported function. try this public static void DBRead()...

not all functions are available on TIA Portal CPUs (1200/1500), it's normal that you have that errors using the demo. Don't use DBGET because it first queries the DB size (using an unsupported function). Use ReadArea and WriteArea instead. Then, did you re-compiled (and re-downloaded) DB100 after unoptimized it? Into the editor are the variable address visible?