Even running at the default 9600 baud rate, the communication between PLC and HMI is so efficient that any changes would be immediately synced to the other, without you noticing any latency. If you do feel the screen is not very responsive as it should be, more than likely, there’s something wrong in your script that has dragged down the whole transmission speed. Actually, there are a few tips when it comes to script programming, that might help fixing your problem:
- Every script has the limit of 512 lines in length. Too long scrip would slow down its run as well as too big loops in script.
- Registers such as HDW/HDX, HSW/HSX, HAW/HAX are memory on the HMI. They have the benefit of fast access when used in script, compared to access speeds of registers on PLC (M registers, D registers etc). Use HMI local memory in script for computation, instead of PLC registers to speed up the transmission then the whole responsiveness.
- If you have to modify PLC registers in script. Try to reduce the chance of writing to it as much as you can. The following trick would work miracles in most cases.
Instead of:
@W_D0 = 100
Do it this way:
If @W_D0 <> 100 then
@W_D0 = 100
End - Try to run the script as less as possible. Your script will run exactly as you instruct it to do, which might slow it down when you are not aware of. Timers are especially susceptible to this. Firstly, reduce the frequency to a value as small you can accept. As the picture below shows, since the unit here is 10ms, when you set it to 10, the script would run every 100ms without fail, which is still a fast enough reaction when you need to detect something using the script. Most of times, make it repeat every second (set it to 100) would be enough. Secondly, ask yourself if you really need to run the script every time it’s triggered. More often than not, you only need to run it when some sort of condition is met, such as a button is pressed, an input comes on, master control is on etc etc. Then you should put the condition to the script. Or set a condition particular for this script as picture shows.
- In case you prefer to do computation on HMI other than on PLC. You can create an two-way address mapping on HMI. Then in script you can use HMI local addresses for computation, the changes would be immediately synced back to PLC and vice versa. The following picture shows how to do a HDW0-HDW100 to D0-D100 mapping. After this, you can modify HDW0-HDW100 as much as you want in script, D0-D100 on PLC would be changed accordingly.
- If none of the above fixed your problem, a good strategy to zero in on the culprit is to back up and delete all your scripts, then add them back one by one. Run a test after each one is added back until you find the one that slows it down. Use the same strategy to work out which sentence in the script causes the problem.
To sum it up, when you are faced with a laggy response. The steps you should take to fix it should be:
a. Go through your script, try to reduce the access (especially writing) to PLC memory as less as possible, as infrequent as possible (ref to tip 4).
b. For all the writings to PLC memory, unless you are certain every time it’s writing a different value then it’s necessary to execute it, try to evaluate first if it’s a different value. If not, go pass it, which would save you one redundant conversation with PLC (ref to tip 3).
c. Use memory mapping wherever you can. This would solve a lot of strange problems, including those you have been long scratching your head for. To give you a few examples:
- When pressing a word switch, combination switch or whatever, you would like to change the value of a WORD/DWORD address on PLC. You may notice. if you use the PLC address directly to the switch, there’ll be a half second latency before it’s finally done. This is especially obvious when you also, on the same hit, try to close a popup window or switch to another page.
- In the script, when you try to create a trigger on rising or falling pulse of a bit address, it would be impossible to make it work with a bit address from PLC directly.
- When you use “indirect window” to pop up a sub-screen, and choose to use a bit address to control its appearance and disappearance. If the bit address is from PLC, very likely the sub-screen would flick a few times before it finally settles.
