Joel,

I am embarrassed, but you helped me find it with the json. I did not realize I had limits set on the discard values. I new it was something simple. Problem solved. I must have copied this point.

Here is the json.

{
"dataPoints":[
{
"xid":"DP_0f1ff7a5-96bf-4daa-a8a6-fe14e1afaab4",
"name":"Delta Upstairs Attic",
"enabled":true,
"loggingType":"INTERVAL",
"intervalLoggingPeriodType":"MINUTES",
"intervalLoggingType":"AVERAGE",
"purgeType":"YEARS",
"pointLocator":{
"dataType":"NUMERIC",
"updateEvent":"NONE",
"contextUpdateEvent":"CONTEXT_UPDATE",
"context":[
{
"varName":"p59",
"dataPointXid":"DP_937c0338-c38c-45cb-9167-b5fec4e5ce81",
"updateContext":true
},
{
"varName":"p58",
"dataPointXid":"DP_a79ff828-72d6-480a-b2fc-6df058f76707",
"updateContext":false
}
],
"logLevel":"NONE",
"variableName":"delta_upstairs_attic",
"scriptPermissions":[
"superadmin"
],
"executionDelaySeconds":0,
"logCount":5,
"logSize":1.0,
"script":"var tempvar1 = p59.value;\nvar tempvar2 = p58.value;\nreturn tempvar1 - tempvar2;",
"settable":false,
"updateCronPattern":""
},
"eventDetectors":[
],
"plotType":"SPLINE",
"rollup":"NONE",
"unit":"",
"simplifyType":"NONE",
"chartColour":"",
"chartRenderer":{
"type":"IMAGE",
"timePeriodType":"DAYS",
"numberOfPeriods":1
},
"dataSourceXid":"DS_4ddc2b19-9bce-44f9-bf79-812775e6a2da",
"defaultCacheSize":1,
"deviceName":"Calcs",
"discardExtremeValues":true,
"discardHighLimit":200.0,
"discardLowLimit":40.0,
"intervalLoggingPeriod":1,
"intervalLoggingSampleWindowSize":0,
"overrideIntervalLoggingSamples":false,
"preventSetExtremeValues":false,
"purgeOverride":false,
"purgePeriod":1,
"readPermission":"superadmin, user",
"setExtremeHighLimit":1.7976931348623157E308,
"setExtremeLowLimit":-1.7976931348623157E308,
"setPermission":"superadmin, user",
"tags":{
},
"textRenderer":{
"type":"ANALOG",
"useUnitAsSuffix":false,
"suffix":"",
"format":"0.00"
},
"tolerance":0.0
}
]
}

I will start with a simple explanation and add any further detail if needed. I have a Meta Data Source with a point that calculates a very simple difference between two context data points. The script validates during the set up, but the point does not calculate when saved. It works fine if I only use one data point context and a hard number but not two context data points. It does not matter from what other data sources I use, it always fails with two context points. I can have both checked for context, or just one, but still no go. The naming is fine or it wouldn't validate. So I am at a loss with this very simple point.

Any ideas?

Any further info needed?

Thanks in advance.
PS - I also searched this forum for anything, and did not find much.

Version is 3.7.x with all updates completed a few days ago.

@terrypacker ok, let me see if I have resolved this correctly or if you have a better method. In meta points, I can create binary points to be set upon Event Detectors. I can then create more meta points to combine those binary meta points into logical statements that can then be assigned Event Detectors. This would effectively be the same as a Compound Event Detector. This will work, albeit kind of an ugly solution.

Is this the best way to handle it or is there a better way?

At first I was hoping there was a way to add Event Detectors as context to a meta point, but not that I could see.

Thanks as always for your help.

Yes it is a broad question about a useful capability, so I figured it was something you had already answered, but did not see anything in the documentation or the forum. Specifically, what I am trying to do is create logic statements on triggered event detectors to create multiple event detection actions. I will check out the meta data point scripts. Thanks for the direction.

In the Original Mango Automation, there was a concept of compound events. In this concept you could create logic statements with multiple events which result in a separate event that could be handled. I do not see this idea discussed in the documentation unless I missed something. Is there any recommendations with Mango M2M to solve this issue?

Rob987,

You have run into a common problem that I see all the time. The swapped word issue is defaulted differently by different Modbus master clients. So modpoll can look correct because it assumed (defaulted) the order correctly. As a general rule, if the numbers are not coming out correct swap the words to see if that helps. Other troubleshooting techniques would be to retrieve each individual word and assemble them manually and see if that helps resolve the issue. Furthering the issue, I have found that device documentation can greatly lack in describing the order of their numbers. Of course all of this depends on getting the correct register number resolved first.

I'm glad you got it resolved.

JF89,

I have a saying that applies, " It's difficult until you know how"

I understand there is alot to learn. I promise you it is worth it to put the effort. Mainly because the power of Linux far exceeds the power of Windows, but it does come at a cost. That cost is time digging, trying, and eventually succeeding.

The alternative if you just want to get up and running is to get a regular Windows computer. Windows IoT is a special beast. You may run into big troubles there. Of course you may not, so feel free to try, but just know Windows IoT could be a challenge as great as learning Linux. Of course I always recommend just trying to see if it works. I think you will find much more support for Linux than you will for Windows IoT and I mean that in a general sense, not just Mango.

Good Luck in your endeavours!

There are multiple embedded computers to choose other than Rpi. Nothing against Rpi, I use them quite a bit, but for Mango I would use a minimum of 2GB memory and then run the board headless with no Xorg GUI. I have chosen a board with 4GB of memory and it was a little over $50 US. However it did take 3-4 weeks to ship. It's the Pine Rock64 with 4GB. I am not using emmc yet, but that would be the next step for me. I only have about 10 points right now, but the custom displays are performing well.

I also tested on a Solid Run embedded computer with 2GB and headless with no Xorg GUI and it worked well also. In all cases, including Rpi, you will need to restrict the memory for the JVM. Check the forum here at Mango, you will find the way to do it.

I would add that Java performance on Linux is better than Windows. Oracle generally recommends Linux on most of their products. Specifically they recommend Oracle Linux, which 95% the same to Red Hat. All that to say that I would probably take the time to learn Linux if you want to use Mango. It's actually not that hard.

Good Luck in your endeavours.

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.

@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?

@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.

• 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.

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 `,~)

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

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.

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?

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.

Right, makes sense, I don't see OPC-UA much either. The OPC-DA technically uses DCOM, so unless you are accessing it over the network, then it probably is not using TCP/IP at all. In the case it is over the network, fun! fun! fun! setting up DCOM over the network. Ok, I'm now getting bad memories. Checking out now!!! My recommendations stand. As a matter of fact that last time I set up OPC-DA I used the Makitron free trial to help me set it up. It's actually great software.