You will have to isolate the inverter from Mango to know for sure. The first thing I would do is leave the configuration as it is and run a constant ping script and log the results. See if the response times on the ping grows during the failure times in Mango. If you are getting ping failures or long responses during the same time as Mango, it is likely the inverter software lagging or network latency issues. The next more drastic isolation would be to use another Modbus client and also the ping test at the same time and see if you get errors as well. Again logging the errors. I've used the original Mango, ScadaBR and now testing the new M2M2 mango for nearly 10 years and most of the time it is not Mango, but the device or network that is the issue.

I realize this is a bit old, but I want to point out that the relationship of momentary buttons and SCADA HMIs have a long and disturbing history. Not that they shouldn't be available, because they absolutely should, but understanding their use and characteristics is VERY important. In an electrically physical sense they make the most sense. You push and things happen, You let go and things stop happening. With variation of course, but as an example that is typical.

In SCADA HMIs, exactly what happens is highly dependent on the creators; both the Software vendors and HMI creators. My personal experience is to use them lightly and have a solid plan. Do not flip bits across a network with a momentary button. Instead start scripts that react to inputs, can verify control commands, retries, emergency stop events and time out features or any other rich programming options. If I am flipping bits, I like to use internal points, because I know there will not be a communication issue. Then the script can read that point, again with no worries of network failures. The logic does not have to be in the PLC, but the logic has to be robust if it is not in the PLC. IMHO it all depends on the use case to determine how it should be handled.

Be careful with momentary buttons on an HMI, know exactly how the software treats them and plan and test. At worst this is a safety issue, but it could also be a $$$ issue. As in lost $$$.

Having said that, I was very pleased to see this functionality in Mango. Thanks @Jared-Wiltshire for creating this feature.

Ok, thx for the input. So last step that actually was quite easy and I did not have to do anything except install the "libjssc-java" deb package that was already in the repository and then copy /usr/share/java/jssc-2.8.0.jar to the /opt/mango/lib dir. Which will replace the default mango jar file and this solved the issue. I did not have to repack or anything else. The replacement jar references a library in the /usr/lib/jni directory that is compiled for the ARM64 architecture.

SOLVED

Thanks for the help as always, and now you also know how to fix this going forward.

Interesting view @phildunlap. One of these days I will have to Wireshark Mango polls and play with those settings to see how Mango tries to optimize. But even if that is checked or not, if the inverter has a good network connection and the software is responsive, it should be able to respond quickly. It is very few points. I'm glad you pointed that out though, something for me to check out one day and it is certainly worth a try on this case.

@rob987 - Is this a wired or wireless connection?

Also, I have found that small resource embedded devices can get clogged up with actions that can slow the response. Can you correlate any inverter actions with the failures?

Awesome, thanks for the code reference. I am just now realizing that log is the Modbus request and responses. I was looking at that log wondering what it was, then it hit me it's Modbus req/rep. How do you get Mango to log that I/O? That could be useful.

So in this case, why did it send out the exact same request in less than a ms? and other times I see it in 1 ms. But why the exact same request in such a short time?

2019/03/22-21:06:43,356 O 000c00000006010300e20002
2019/03/22-21:06:44,356 O 000c00000006010300e20002

Nope, behold was needed, I was just using the log above, it is 1 sec gaps, so that is just a retry and makes sense. I missed the increment. So the question is still why is it needing to retry? Something is holding it up. Network or processor?

Thx for the beholds too `,~)

• The nnn is ms

• The only way I know how to have separate point scan times is to create multiple data sources with different scan times. I will let Mango staff have the last word on that. This could be a problem if the inverter does not allow more than one TCP/IP session.

• That "Contiguous Batch Only" definitely changed the request to ask for larger blocks of data. This may be more friendly to the processor. Meaning less requests to handle.

Recommendations to try:

• Try to set the Transport Type to TCP with keep-alive if it is not already. I think that should be the default. I have run into issues where performance is affected if that is not set. The constant TCP session set up and tear down is wasted load time.

• If the inverter allows more than one TCP/IP session then create a second data source that polls at the 15 min poll rate. If there is another way to do this, maybe the Mango folks will chime in. All settings should be the same for each data source except the points and poll rate.

• It's highly unusual, but it is possible that the PLC and the inverter have differing TCP stack software. This can lead to devices not talking. I have seen this before in embedded devices that are old. If this is true you could break down the TCP sections from mango and compare them to the PLC TCP packets. It's not likely, but possible. You could also check every bit sent from Mango and compare to every bit sent from the PLC and see how they differ. It can be grueling and may not be worth the time, but if you really want to know this is an option.

@phildunlap

Correct, my assumption was he unchecked the "Contiguous Batch Only" and it resulted in two requests for 13 and 37 registers per request as opposed to 2 registers per request based on the Modbus logging, which I dearly love that I/O feature. I'm totally lost on the alternative point polling periods you proposed. And that is ok, because I do not need that feature in Mango and will be sure to contact you if I ever do.

From a general SCADA perspective. Multiple polling rates for different points is handled differently across different systems. Some take over completely and optimize as they see fit and some do that VERY well. Others and my favorite is to create scan groups where you specify the points you want per group and what scan rate you would like for that group. Then the same TCP/IP session can be used by Modbus master to scan the groups as specified. Not sure if Mango would ever consider the scan group idea, but I would certainly like that feature.

@phildunlap

Ah! I do get what you are saying about scripting the update. So you could create a timer and use that to run a script to refresh. So your data source could be set to the longest you wanted for a refresh and you could create a script to refresh at shorter intervals. That actually is a nice work around and, oddly it mimics the scan group feature I discussed. It does lead to a question.

Will the scripted refresh be a single point only, or could you pass it a group of points?
Would that bypass the Modbus attempt to optimize requests?

However, the refresh work around may be the only way to do it for a device that only allows a single TCP/IP session, so that is a good technique to remember and keep in my tool box. Plus, single point MODBUS requests are not the most efficient, but in reality the load increase is very small in most cases. I like it, thx.