I am unsure how to even ask this, let alone how to look for it and I would like to point out that because of this, I didn’t look to see if there were any threads about this already. And I would like to apologize beforehand if there is.
I was a part of the class that was at the beginning of June of this year and that was my first time programming anything PLC like, so I am very new to this. But something came to mind today that I wish I would have come to me while I was in the class so I could ask.
My physical setup - I have a project that we control 9 pump motors, 6 solenoids, and about 11 conveyor motors (just to start).
I have more than one chart controlling the same I/O points (turn things on and off). Would it be better to have the separate charts control variables and then one chart loop through and see when those variables have turned on and off to control the I/O points?
And would it be faster to turn the points on, if they are already on, or off if they are already off? Or would it be faster to instead look at a variable to see if it is 1 or 0 to turn the points on or off accordingly?
The two examples that I have to help me kind of get my second question across in the picture below. The left is turning the I/O point on continuously while the if statement is true. Where the right one is the one that checks if the variable is “1” and if the checkbit = 0 before it starts turning the I/O point on. And if either of those two are false, it doesn’t touch the I/O point.
The one bit of key info that would be helpful is to know if are talking to remote I/O or if its all on localhost…
But, regardless, there are some aspects of your post that we can advise on from a high level…
Your point about not finding any of this ‘performance’ info is well taken. I am in the process of combining, updating and pretty much totally re-writing the two current optimization and best practices docs, but its a big job.
Unless you are using serial I/O, having more than one chart talking to the same I/O rack/module is not an issue. Ethernet is very fast when it comes to I/O operations and so there is not a lot to worry about till you are getting into multi controllers talking to the same I/O.
One thing you don’t mention is what GUI you are using, PAC Display, groov View or something else?
Generally you want to connect your I/O graphic elements directly to the I/O vs via the controller.
You can read why here (last post, but skim the rest of the thread): Groov View tags to IO
As far as turning on a point that’s already turned on, its not a problem.
As you (hopefully) recall from the class, you should have delays in all your charts and every loop in every chart, so that delay is going to take care of your performance ‘gains’ in checking if its on before turning it on.
As a reminder about delays:
So lets know if your I/O is remote or local host and if there is more than one control strategy talking to the same rack and lastly what user interface you are using.
There might be some tweaks or things to keep in mind depending on how that’s setup.
And I would like to apologize, this was more of a “general question” for learning than anything else. We aren’t running into performance issues, I was working on the charts yesterday and I thought “Is what I am doing the most performant or efficient” while doing it and though I should ask that question.
All the I/O is on localhost and there is only one strategy on the controller for the setup. I am programming this in PAC Control and we have an HMI using Groov View.
From what you indicated, it seems like I don’t need to worry about multiple charts controlling the same I/O as long as they don’t conflict with each other. (One is trying to turn a point off while another is trying to turn it on.)
And from what I gather, the system doesn’t keep sending the signal to turn a point on if it is already on. So it does it’s own internal check and ignores what I told it to do is already done.
Can your logic be setup for faster performance? Yes it can.
Is it worth spending extra development time to squeeze out more performance? Usually not.
Avoid premature optimization.
What you are doing is fine - yes you are hitting the IO more than you need to, but it doesn’t matter. Yes, when you tell a point to turn on and it is already on, it sends the command anyways.
Like Ben said, with serial you would want to optimize more, same with remote IO over a slow or expensive link. In those cases you would do what you mentioned, block read and write the data into local variables. That takes more developer overhead (more labor), and can cause other subtle bugs, only do it when needed and save your employer/customer money.
I will keep those points in mind while working with these devices.
I have a very beginner mind set to programming and my original language was Python, so I am always thinking “What is going to give me better performance” since Python is a slow language.
