Meta data source influencing Modbus Data source

[ThomasEinasto]

Hi everyone,

We are using devices which hold in it's holding register binary values. Meaning one register has 16 values according to which kind of a signal they are getting.

Currently I have come to a conclusion that the meta data source is influencing on how Mango reads the bits from the register within a modbus module.

The problem could be a performance issue on MangoES but when I think about it I only have 100 meta data points on my system of which 75 are multi state and 25 are numeric. So the number of meta data points on my system in my opinion is relatively small.

The registers are not settable so nothing can change their value i.e Mango setting point values or something like that.

The problem:

When the meta datasource is active then Mango makes errors on reading the registers values. e.g if the value should be true it goes false for one or two polls. When the meta datasource is disabled then there are no errors and the system runs perfectly.

I logged one point for getting the behaviour of the point which is displayed here:

At 15.00 - 15.59 the meta datasource was active. I disabled it for 10 minutes then the errors stopped. After activating the meta data source again then the errors started again and the CPU on MangoES went high. After 16:49 i disabled the data source again for an hour and the errors stopped etc...

The graph is proof of the strange behaviour on reading the data that the meta datasource is influencing the reading as the point should always be true like it is when the datasource is not active.

The multistate script on the meta data points is following:

function state(kl,mk,on1,on2,end1,end2) {

if (mk.value===true ){return 2};

if (kl.value===false ){return 3}; 

if (end1.value===true ) {
if (on1.value===false ) return 1;  
return 11                                
}

if (end2.value===true  ) {
if (on2.value===false ) return -1; 
return -11                                
}

if (on1.value===true && end1.value===false ) {return 12}; 

if (on2.value===true  && end2.value===false) {return -12}; 

if (end1.value===false && end2.value===false ){return 4}
}

The script is relatively small and easy. I am using it to display the states of the devices by using ng-class in the Angular module.

Currently the system cannot work if this problem cannot be resolved. I was thinking that maybe if we used scripting data source instead of the meta datasource if the module is using too much header but then we cannot use update context option which we desperately need.

[phildunlap]

Hi Thomas,

Do you have all the context points on the multistate meta points set to update the meta point? If so, can you reduce it to at most one point per data source updating the context for the point (such that any one data source poll will only generate one context update for a point)?

Currently this can cause some performance issues, which we'll resolve in a future version.

[ThomasEinasto]

Hi Phil,

Yes I have all the context points on the multistate.

About performance issues.

Could you estimate if the solution would be wise if we made the context update in the Angular module itself and lose all the meta data points.

It would essentially pull out 6 x more points to the page but then we could let ng-class do the meta calculation and we would not have to activate the meta datasource and the problem itself would be overrun by using a different solution in displaying the states.

Thanks,
Thomas

[phildunlap]

I do not know your application well enough to say. If you have the front end doing the calculation it will always have to be doing it, but if you are only considering in the current state (and do not need automated action on certain states) perhaps doing it in the display is okay. This sounds like a job for a meta point, though.

Here's a simply python script to disable all but the first context point, if it's helpful...

import json

configFile = open("/path/to/Mango/backup/Mango-Configuration.json") #note, you will change this
config = json.load(configFile)
configFile.close()

modifiedPoints = [];
for dp in config["dataPoints"] :
  if "context" in dp["pointLocator"] :
    for x in xrange( len( dp["pointLocator"]["context"] ) ) :
      if x == 0 :
        continue
      dp["pointLocator"]["context"][x]["updateContext"] = False
      modifiedPoints.append(dp)

outputFile = open("/path/to/output.json", "w+") #change this too
outputFile.write(json.dumps({"dataPoints":modifiedPoints}, sort_keys=False, indent=4, separators=(',',': ')))
outputFile.close()

Then you can import the new JSON to fix the points.

[ThomasEinasto]

Thanks for your reply.

I will save the script but it is not needed at the moment because we really need that every point in the meta data point updates context and I will probably just stick with the angular right now until the performance issues will be resolved.

The only problem I am concerned about while using Angular is the performance in browser if I load too much points on one page. Because we already have problems with PCs which are not atleast I5 CPU. ( The responsiveness is delayed on slower PCs. )

That's why I am using meta datasource to change the state of the object by using 6 points to calculate it's state inside Mango instead of loading 6 points on one page.

The application consists of divs which change the class of the div according to which point is true or false. There are 2 main points which should be true and false always respectively. I will do this probably with ng-if so that it will override the ng-class.

The automation will be done through scripting datasource because right now the users want to do everything manually without automation.

I will get back with the results when I have finished the page.

Thanks a lot,
Thomas

[phildunlap]

Okay. I was curious if multiple points in the context of one of the meta points were from the same modbus data source. One would be sufficient for getting all updates, and you can do a minor execution delay too (10-20ms or so). If they are on different data sources, the source of the issue may be something else.

[ThomasEinasto]

The points are on one modbus datasource which uses the MangoES RS485 input.

[phildunlap]

Right, so you don't need them all updating the context, since they'll all generate an update event each Modbus poll, so you only need one and perhaps a minor execution delay.

[ThomasEinasto]

Alright,

I will change each datapoint to only be using 1 update context and see if this solves the issue.

Its night in here so i will get back to you tommorrow.

Thanks,
Thomas

EDIT:

How do i set a execution delay 20 ms if there is an int option in seconds only on setting the execution delay.

EDIT 2:

I reconfigured the points by using only one context update without the execution delay and that did not help. By adding the execution delay to 1 second seems to have stabilized the system and the errors are not present for now. The CPU usage is low and memory usage is stable after activating the meta datasource for an hour which is very good.

I will be looking over the system for a day and see if the errors would pop up when the work starts within the system.

Thanks a lot for saving me here!!!

It should still be noted that there is a strange behaviour in the system while using the meta datasource "incorrectly" so you probably should still look into what is the root of the problem.

If needed I can send you my ma.log file.

Many thanks,
Thomas

[phildunlap]

The source of the issue is known, and it involves multiple points from the same data source updating the context of a meta point. The execution delay probably isn't what reduced the load on your system, it is just to ensure all the values from the poll are recorded by the time the meta point runs from the one context update. I suspect your system was still playing catch-up when you observed the execution delay alleviating it.

The one possible exception to that is that if your execution delay is greater than the polling interval your meta point may not be running.

[ThomasEinasto]

Okay,

The system was working around 20 h straight without problems and then just shut down. Only manual reboot through taking the cable out helped to boot the system back up.

As I read the github I noticed that the issue will be solved in 2.8. Do you happen to know the estimate when are you planning on releasing 2.8.0 public ?

[phildunlap]

Is there a message in the log, an hs_err in the Mango/ folder or anything interesting in dmesg?

2.8 should be released either late September or early October but there is not a firm date yet.

[ThomasEinasto]

Hi Phil,

There are no hs_err logs in my MangoES instance after changing the meta datasources like you instructed. The system was stable for a while but then switched off and a manual restart was needed to get mango up again.

As I was checking what may be the cause I found out that using concurrent-carbage-collector to free some memory space was the reason for strange behaviour in the system.

The average uptime was still around 3-5 h.

After removing the CGC the system went stable and then I noticed that there is a memory leak somewhere because right now the system can work around 20 h and then reboots.

The memory usage at boot is around 1 gb and starts growing until Mango reboots. Probably because system kills Mango as it is taking so much memory and then the check.sh script reboots MangoES.

As i understand that removing the CGC set me up with the default GC algorithm but I can't seem to notice if the GC on Mango is freeing up my memory or not.

Its a problem because I think ideally MangoES should be running for days/months without interruption.

I have another MangoES in my office running now 3 days straight without problems. Of course it is just a clean out of the box with only System Information datasources activated. But this instance will be going to our clients also next week with a similar system installed on it as the one which I am having problems with.

Many thanks,
Thomas