dFx

Depending on what you are trying to achieve, this could be addressed differently. 1) general heating cooling application with a Moving setpoint that require the best precision (less than 0.5°C) generally uses one PID, that you will split the output from 0 to 50 and 50 to 100%. But in case of actuators being very differently effective on the PV, you may have troubles at setup. This is also very energy consuming. 2) Energy efficient version would be using at least a deadband, that may prevent some hystérésis or inertia on your actuators. so splitting pid CV from 0 to 45 and 55 to 100 could be a good idea. But this does still faces the problem with setup on different effectiveness of actuators. You can then scale differently your spliting ranges to address a bit the tuning différences (for exemple 0-10 and 20-100) 3) Do one PID for heating and one for cooling. Never use this solution if you can't affrod a deadband on your PV, that could lead to demands on cooling and heating. So if you can affrod 1°C of deadband, Simply put the deadband higher limit as SP for cooling and the lower limit to SP for heating. This is not the fastest solution but you can fine tune each PID separatly. Loop time directly affects every PID constants as they are working with the error measured. higher scan time will lead to higher errors mesured from scan to scan. last but not least, never try to setup a PID directly adding integral and derivative values. I almost never use derivation on heating/cooling pid. Start with setting your P correctly, then once your system is stable and with some not so high error, you can introduce Integral term.

Had once a similar problem. Installing PVC pipes around the measurement column did the job (almost up to the sensor head). Make sure you let a suffisient under spacing for the water to flow.

If this retain address is generated by your user program compiler, you should look around this compiler (logs ?) to get your addresses.

"Hardware interrupts" is called "Event" in codesys. Anyway, you can achieve a correct control of something slightly faster than your main cycle time, using some periodic task (not freewheel). Be carrefull about the length of the computing in it by adding a proper watchdog. Also remember that in codesys, Ouputs refresh is done by a task, so plug your fast periodic task to your output refreshing task parameter. Last but not least, controling something way faster than your PLC cycle time should be done with some interface (some modules may convert an analogic signal properly to drive a thyristors)

First thing to check if you go STOP mode is your cpu diagnostics : On your PLC, get online, then right clic on PLC -> diagnostics See Chapter 4.3 : https://support.industry.siemens.com/cs/attachments/68011497/68011497_S7-1500_Diagnose_DOKU_v10_en.pdf

A bit off-topic but main comes handy. Breakpoints is as powerfull as dangerous tool. That's why I prefer writing some spy code into my loops. exemple : FOR a := 0 TO 9 BY 1 DO // Code IF a == 1 THEN MySpy := MyValue; END_IF; // More code END_FOR; The main advantages are :  - It DOES NOT STOP scanning  - Spyed value is consistent  

Also make sure that your serial cable COM port is properly connected to your VM and not your host !

just set the field property as output and then modify the value using keymap actions

to setup date manually, go to TP control panel then date time and set it. to synchronize TP date, go to connections -> area pointer -> global area pointer -> date/time (check help for datalenght and data arrangement)

Had to work on such a slow loop in the past. We started with PID and failled to go with it. Then we realized that knowing the flow was a major issue, and Added some formula to offset PID's setpoint correctly. We went through a tough comissionning, but ended well adding some weight factor on the formula setpoint with the real setpoint. To start, as you know your flow, and your Customer likely know at constant flow how much acid is needed, start building some basic formula for acid ( acidDose = Flow * RawWaterPhError) Note I use raw Water Ph, cause your middle probe is only usefull to limit the ph drop. Once you get it stable (it should be easy), then slowly add some weigth to your PID, adding almost only integrative action (Proportional should be small in my mind),  PID role is just to correct the error using slow integrative action, while your formula should presets almost correctly the acid dosing.  so your loop should look like : formula * weigth + Setpoint * (1 - weight) -> PID setpoint -> PID -> PID output -> Dosing pump setpoint   Last but not least, make sure that the alkali probe is correctly setup (not too close from alkali injection point, and is sending some pretty stable signal). And also have a look at how is builded the pump setup (big issues can comes from bad installation).   @Jairus  : generaly, you need an agitator system and even some more time to the acid to properly diffuse in the water. Shortening the distance can be a big issue for the final probing.

Toatally solved my issue on FTME 10. thanks a lot. (searched for a while, cause I've no techConnect)