Should HMI and program be decoupled like Model-View-Controller, or everything hard-coded? What is best for a flexible and maintainable system etc? Any suggestions?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2017-08-11
Originally created by: scott_cunningham
I try to keep the "brains" in the program. That means, avoid putting button logic, filtering, etc. in the HMI - doing this can cause troubles if you don't remember what all was done in the HMI and change your PLC code. (I learned this the difficult way).
I typically let HMI buttons set a variable True (like ReqStart) and then have the PLC logic set the variable to False - this is a sort of acknowledgement that the logic actually got the request. Before I had tried impulse or timed settings on the HMI, but it would always lead to troubles - depending on the communication rate between the HMI and logic.
Also, to support multiple languages, I define a status enumeration and send the code from the logic to HMI instead of a string - the HMI can then have lookup tables converting the code to language strings. If it doesn't know the code - I simply have the HMI use, "Unknown status: " + code.
I am sure others will have good ideas.
Good luck!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am newbi in mvmv model, but I think that hmi in codesys allows it, you can compile your realtime (model model-view) without the visual part.
For example, whe you associates a label text with an realtime variable is as a binding in C#, and you can pass an realtime fb via varinout to a visualization which could be like in wpf does with context property.
The diference with wpf is that in wpf the binding variables are passed as text (which is converted in code after) and in codesys-hmi the binding variables are passed as code. It means that you cant compile your view part without your model-view part. But your has the advantage that it throws an error in compilation time.
I think that you have the tools to do that. Another question is how you separate your model modelview from your model, if it has to be separated in a control.
And, as Scott says, dont use control code in hmi part.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Should HMI and program be decoupled like Model-View-Controller, or everything hard-coded? What is best for a flexible and maintainable system etc? Any suggestions?
Thanks
Originally created by: scott_cunningham
I try to keep the "brains" in the program. That means, avoid putting button logic, filtering, etc. in the HMI - doing this can cause troubles if you don't remember what all was done in the HMI and change your PLC code. (I learned this the difficult way).
I typically let HMI buttons set a variable True (like ReqStart) and then have the PLC logic set the variable to False - this is a sort of acknowledgement that the logic actually got the request. Before I had tried impulse or timed settings on the HMI, but it would always lead to troubles - depending on the communication rate between the HMI and logic.
Also, to support multiple languages, I define a status enumeration and send the code from the logic to HMI instead of a string - the HMI can then have lookup tables converting the code to language strings. If it doesn't know the code - I simply have the HMI use, "Unknown status: " + code.
I am sure others will have good ideas.
Good luck!
Hi.
I am newbi in mvmv model, but I think that hmi in codesys allows it, you can compile your realtime (model model-view) without the visual part.
For example, whe you associates a label text with an realtime variable is as a binding in C#, and you can pass an realtime fb via varinout to a visualization which could be like in wpf does with context property.
The diference with wpf is that in wpf the binding variables are passed as text (which is converted in code after) and in codesys-hmi the binding variables are passed as code. It means that you cant compile your view part without your model-view part. But your has the advantage that it throws an error in compilation time.
I think that you have the tools to do that. Another question is how you separate your model modelview from your model, if it has to be separated in a control.
And, as Scott says, dont use control code in hmi part.
Thank you both for some really good points, I will for sure look into these tips.