Home » Eclipse Projects » 4DIAC - Framework for Distributed Industrial Automation and Control » improvement of usability(experiences)
| improvement of usability [message #1772996] |
Wed, 20 September 2017 00:58  |
 Ernst Murnleitner
Messages: 19
Registered: December 2016 |
Junior Member |
|
|
The last months we used 4DIAC/FORTE and developped a small model biogas plant, where it was used. While the system works nice, there are some suggestions/topics for discussion which would increase the usability or which could speed up the development process. Have you similar experience or solutions aready?
a) Networks become quite big in the editor. It is difficult in order to connect function blocks if their distance is large. I hope, that subapplications would solve this. Subapplications cannot really be used this time (4diac bugzilla no. 509425). I also used adapters in order to keep the number of connections low.
b) The use of ECC diagrams is a very nice feature. It however happened that we built an endless loop within such a function block. Debugging inside the ecc of the fb is not possible. As a work around I introduced a variable "debug" which was set in each state to a different value.
c) design of the application: I thought a lot if it is better to use bool variables or events for certain things. As an example, if an actuator is switched on or off, this could be achieved by:
- seperate events for "on" and "off"
- one event for "on_off_state changed" and a boolean variable with "true" or "false".
At the end we used the latter one because we transferred the data via MQTT and this aproach fitted better, because the "state changed event" was translated into a message and the boolean variable was the payload.
There would also be a difference, if the events are sent more than once. E.g. if there are two events (on and off) without any bool value, in the simplest implementation, each event would directly start an action, count the number of switches twice etc.
Using one event and one bool variable for specification if on or off, one could relatively easy compare the bool with a safed state and only perform an action if the bool changed. I ended up with the event's meaning "the actuator has eventually switched" instead of "the actuator has switched". Eventually a "best practice" example or documentation would be nice for newcommers.
d) Connection of muliple applications or devices and restart of one of it. In conventional PLC programming input values are read all the time (cycling). Here we only transferred data if data changed. An event was sent in this case. However, if we restarted one of the devices or applications, the following happened:
The restarted application initialised values to their default. The application which provided events and data however did not send data because no event occured. The whole system was in an inconsistant state then.
Solutions would be:
- store data in non volatile memory (which is not always available)
- add logic for restart (which makes it complex)
- reinitialise everything (which however is not always possible)
e) reconnect of communication modules. We used an mqtt broker in order to make data exchange. If the mqtt broker was restarted, the forte module (paho) did not connect again. Because of the usage of events, this would be a problem anyway because events could be lost (see above). In industrial applications, such things have to be taken into account.
f) lost states due to restart of modules and cyclic publishing. See above. At the end I fired events not only on change of a state but also every one or few seconds. If you have a large number of actuators and each publishes its state each second or so, there will arrive a huge number of events. In my application which is communicating with forte via mqtt, I had to seperate sending and receiving of mqtt into separte threads, because it took up to severa minutes, that the input events could be processed if many output events were published. I have not investigated yet, if this would be necessary in forte, too. Eventually, forte already creates seperate threads? The QoS (Quality of service) when using mqtt could also be important. QoS means that the messages should be published without any handshake, like forte does with UDP broadcasts.
g) huge number of events on restart (in my case). If I restart my system, I publish states and settings wich are received by the forte application via mqtt. I publish all data not only changed because the forte network does not save it's states. However, this gave an overflow of the events, because each actuator sent several events and there has been a number of actuators and other objects. At the end, I introduced sleep between sending the next data.
|
|
|
| Re: improvement of usability [message #1773003 is a reply to message #1772996] |
Wed, 20 September 2017 07:38  |
|
Thanks for this report. I was lucky to get a sneak preview on your work. So seeing this report publicly is really helpful for the 4diac project. There are lot of interesting points to be considered for the future development of 4diac and some have been already. For example the current big work towards 1.9 is exactly to bring subapplications back. We also noticed the MQTT issues. Jose has spent a lot of work you can see in FORTE's development branch to address issues like network outages or broker restarts. Now FORTE reconnects automatically. But there still more work is needed.
If you have time we would also be happy to host a story on your use-case, with pictures, in the 4diac blog.
|
|
|
| Re: improvement of usability [message #1773004 is a reply to message #1772996] |
Wed, 20 September 2017 07:40 |
Jose Maria Jesus Cabral Lassalle
Messages: 199
Registered: February 2016 |
Senior Member |
|
|
Wow! this is nice collection of issues. I also experienced some of them, but din't put it so clear as here. I'll add some comments (question or answers) to each point:
a) I think this is the biggest problem regarding usability right now. Apart from subapplications, I also thought about some kind of "view" which would be exaclty as a subapplication (a funciton block with a network inside that you can go in and out), but the application in forte would remaing the same, just as one big network. That was my first thought, but I think that subapplications improve the performance of the application in forte.
b) I also think that debugging an ECC would be a cool feature. Also, since the ECC is basically a state diagram, some generic test for fucntionality or good practice (as a static analysis) can be applied on it in order to avoid problems.
c) I like the "best practice" or maybe design patterns for 61499. Since this comes mostly from experience, we could open something (online docs, forum topic, a bug) where to collect all this examples.
d) After initialization an input or output, could you connect the INITO to the REQ event of the Function Block to force the reading of the value and a new output event from each block? This will propagate events of the PLC that was restarted.
e) Which version of forte are you using? We faced similar problems with the MQTT broker going down, so in the DEVELOP branch of forte, the MQTT layer uses asyncrhonous communication, and when the connection with the broker is lost, forte will keep attempting to reconnect every couple of seconds (maybe this retry attemp time can be put as a CMAKE variable)
f and g) I didn't quite understand the situation in both points, but forte runs each resource inside a device runs in a separate thread. The QoS is constant in the MQTT layer, so maybe a variable in CMAKE or even in the parameters can be added to solve this issue.
|
|
|
| Re: improvement of usability [message #1773010 is a reply to message #1773004] |
Wed, 20 September 2017 08:21 |
|
Jose to comment on your comment a. In principle the current subapplicatoin implementation in forte is exactly what you suggest. The only open point before we can start testing it is to fix the generation of the right name for download. Monika gave me some hint how i could do it so now I only have to sit down and program it ;-)
Regarding your suggestion of collecting design patterns and experience. We have the possibility of wiki pages as part of the eclipse wiki [1]. Anybody with an eclipse account , anyhow needed for forum posts, can write there. Only the first few posts need to be reviewed by an wiki administrator to prevent spam. Would this be an option?
[1] https://wiki.eclipse.org/4DIAC
|
|
|
Goto Forum:
Current Time: Thu Apr 25 06:16:43 GMT 2024
Powered by FUDForum. Page generated in 0.03533 seconds |
] 
Search
Help
Register
Login
Home
