Illegal Function alarm

I am reading data from a modbus ip device and have data points configured to access coil status registers. When these points are enabled, I receive alarms like the following:

'Measurements A': Baseline A1 P1 WL1: Illegal function

What does this mean?

Here's the configuration of a typical point:

"loggingType":"ON_CHANGE",
"intervalLoggingPeriodType":"MINUTES",
"intervalLoggingType":"INSTANT",
"purgeType":"YEARS",
"pointLocator":{
"range":"COIL_STATUS",
"modbusDataType":"BINARY",
"additive":0.0,
"bit":0,
"multiplier":1.0,
"offset":110,
"settableOverride":true,
"slaveId":1,
"slaveMonitor":false
},
"eventDetectors":[
],
"engineeringUnits":"",
"chartRenderer":{
"type":"IMAGE",
"timePeriodType":"MINUTES",
"numberOfPeriods":60
},
"dataSourceXid":"DS_DATA_A",
"defaultCacheSize":1,
"discardExtremeValues":false,
"discardHighLimit":1.0E-4,
"discardLowLimit":-1.0E-4,
"enabled":false,
"intervalLoggingPeriod":15,
"name":"Baseline A1 P1 WL1",
"purgePeriod":1,
"textRenderer":{
"type":"BINARY",
"oneColour":null,
"oneLabel":"On",
"zeroColour":"#ff0000",
"zeroLabel":"Off"

Are you sure the range should be Coil Status? That's the first thing i would check.

Yes, these should be coil status values; they represent on/off switches used for controlling how the device calculates results. The user needs to be able change them.

What if you enable points one at a time or in groups in order to determine if a particular point or points are causing the problem?

Individually or in groups doesn't matter. Enabling any of my coil status data points causes this alarm. What is interesting is that if I enable all of the binary data points that reside in the same modbus address (e.g. address 133, bits 0-5), only one of them produces alarm (the lowest bit). Disabling that one just causes the next highest one to alarm.

If this is a I/P data source, any chance you could expose it temporarily to internet access so that i can try it myself?

I've discovered that I'm getting these illegal function errors on input status data points as well.

Another discovery: enabling "Contiguous batches only" alleviates the problem. Could there be an conflict between mango's disparate value mechanism and the the device's attempt to modify modbus registers?

As far as I'm concerned, if turning on contiguous batches only resolves these errors without sacrificing performance, then I'm happy.

Hi Steve,

I'm glad it's worked out. Note that your equipment is returning misleading error responses. If choosing contiguous batches fixes the problem, it means that the problem was "illegal register address", not "illegal function".

I think this has been explained elsewhere, but the problem is thus... Say you want the values in registers 10 and 12, but you don't care about 11. It can be faster to do a single request for 10-12 than two requests each for 10 and 12. But some equipment will complain if it doesn't store anything at register 11. In these cases you can force two requests by clicking to only batch requests over contiguous register ids.

Sorry, my previous post was incorrect. Testing against a larger system with multiple data sources shows that the contiguous batches setting has no effect on the occurrence of the illegal function alarm.

I will attach the modbus4j exceptions being produced.

Hmm... After looking at the code, i can't see how that condition would happen. First, what version of Mango are you using? Second, can you forward an export of your data source config?

I'm using v1.9.0.

Is it allowable for me to define multiple data sources that all communicate with the same ip host/port? I started seeing these errors after splitting my 900+ data points between 18 data sources all going at the same host/port. I wanted different data sources so I could use different update times for various groups of data points.

Let me know so I can rearrange my data points, if necessary, and retest before I send you my large set of DP definitions. Thanks.

Ok, I've reproduced this again with a small set of data points. The included numeric data points work correctly; the binary coil status data points produce the illegal function (address) errors.

Works fine for me, but i'm using a different slave. If you want more personalized help on this - in particular getting things working with your device(s) - use the contact us page to request support services. Turnaround is much faster, and we'll get to the bottom of the issue.

Oh, BTW, in that export, all of the "dp40012" points are coded as Coils, but - considering the "40012" and the fact that the bit number is set - it looks like you meant them to be holding registers.