Compacting and obfuscation of variable exchange for eHMI

PLCnext Engineer
1

Dear All,

While we develop eHMI control dialogs and screens for big projects, with hundreds of units for control and monitoring, there was found out next limitations.
If we have to exchange big amount of data for visualization, we get quiet heavy json variable file (from _pxc_api). Time of data transfer and parsing significantly increase,
and if we have a deal with operator PC station of low computing power, in some cases, eHMI became unavailable at all, just loading.gif spins over and over.
To find out way to solve this trouble we analyzed json variable files, and find out that variable names transferred as it were declared in PLC Data List, column Variable {PLC} (long and well human readable), but we expect to see variable name declared in HMI Tag column (Compact, and tiny). To get tiny names in json file we have to refactor column Variable {PLC}, and decrease readable opportunity in plc logic.
Also we increase timeouts in nginx *.conf files. So, we have two main questions:
1. Why variables don’t use HMI Tag Alias in _pcx_api json data file?
2. Is there any way to activate compacting, zipping and obfuscation of variables, build in in PLCNext, to get more lightweight json data file for eHMI? PLCNext Engineer 2021.0.1 Best regards.
Oleksandr

2

Dear Oleksandr, good and interesting point! I’ll check this with the development and product management and come back to you asap. Take care, Frank

3

Hello Frank, As we know now, it is not a big deal to activate gzip on nginx server side of plcnext, and get compacting of json data ten times, as well. But match more curious and actual question is the way to decrease time of FastCGI response, covered behind web server side of external linux cover and directly attached to plcnext core logic of control proces. Now we have a deal with json generation delay more than 500 ms, and we are afraid, that soon we will loose ability to provide reliable and lifebeat web pages. Its very important for us to receive recomendations for decrease of time delay in this case. Best regards Oleksandr

image.png
image.png
image.png
image.png
settings.png
image.png
device_list.png
image.png
image.png
image.png
image.png

4

Good Morning Oleksandr, good point, but I’ve no experience with FastCGI ?. I’ll ask one of our Web Engineers if they can step into your post, maybe they can share their experiences with you. Frank

5

Good Morning Oleksandr, I’ve spoke with our Web Engineers and to be honest, we don’t quite understand the how your application is created. FastCGI is indeed used for the WBM of PLCnext, but this should not be the bottleneck as it is not frequently called. For the rest I’ve understood, that you are using the PLCnext HMI to generate your (obviously big screens with a lot of variables).

The HMI does use the REST Interface to update the variables, but as a user this should all be quite transparent and don’t care for you. Or did you created and deployed your own application running under nginx? It would be great to get more background or maybe it would make sense to get in direct contact with your local support (could I contact you directly by mail?). Frank

6

Dear Frank,

Sorry for my late response, now I’m in a business trip, there is a release line for one of our projects.
As I can see, increasing of values fastcgi_send_timeout and fastcgi_read_timeout from 300 (default) to 900 or more, in nginx included configuration file
/etc/plcnext/device/Services/Ehmi/nginx_ehmi_location*.conf increase stability of data exchange between web hmi and controller.
Perhaps it works in some indirect way.
Regardless, we looking for ways to decrease time of plc response.
Please, let me know, how can we exchange emails in more private way, so I can send you as many background as it will be enough to receive a comprehensive answer for our deal. Best regards
Oleksandr

7

Dear Oleksandr, you can reach my directly via fwalde@phoenixcontact.com. At least I’d like to give a feedback from our dev regarding your initiate question, compressing the json via aliases instead of clear names.

Ultimately we have to talk to the PLC using its data namespace, and for typesafe information exchange between the client and the server. Adding an extra layer of indirection from tag/alias to full PLC data path would make things slower, not faster: the web server would have to resolve these aliases over and over again as an additional step of processing requests.

There are ideas to optimize the json to make it more compact and the communication speed in the result faster, but I can not give you any timeline for the implementation. All other application related details we may discuss than direct per mail. Take care, Frank

1.png
1.png
1.png