Com'X510 Custom Library Generated Devices Does Not Work

[KuanKhoon]

Good Evening,

Not sure if I have gotten any steps wrong but I do not seem to be able to get custom library generated devices to work. I have a small Modbus RS0485 network at home with the following devices connected at the respective Modbus slave addresses below,

Address 1 : Intentionally Left Unpopulated (prevents clashes when new devices are brought online)

Address 2 : PowerLogic PM3255

Address 3 : PowerLogic iEM3155

Address 4 : Veris HW Wallmount Sensor (Humidity & Temperature)

Address 5 : Veris CW Wallmount Sensor (CO2, Humidity & Temperature)

Address 6 : Veris CW Wallmount Sensor (CO2, Humidity & Temperature)

Address 7 : Veris CW Wallmount Sensor (CO2, Humidity & Temperature)

I went about testing the Com'X 510 as follows,

1) Added the PM3255 via the in-built library of devices and all parameters reads fine [ PM3255 (In-Built Device Library - Voltage).jpg ]

2) Deleted the PM3255 generated in (1) and proceeded to add a custom library [ PM3255 (Custom Library - Voltage - Frame Edit).jpg ]

3) Set the custom device to "big endian" [ PM3255 (Custom Library - Voltage - Big Endian - Frame).jpg ]

4) Observed that the voltage reading now does not appear on the device page [ PM3255 (Custom Library - Voltage - Big Endian - Device).jpg ]

5) Deleted device generated in (4), and set the custom device to "small endian" [ PM3255 (Custom Library - Voltage - Small Endian - Frame).jpg ]

6) Observed that the voltage reading still does not appear on the device page [ PM3255 (Custom Library - Voltage - Small Endian - Device).jpg ]

7) All the while from step (1) to (7), my modscan is polling the PM3255 through the Com'X510 via port 502 and [ PM3255 (Custom Library - Voltage - Modscan Capture).jpg ]

I repeated the above procedures for my Veris HW and CW sensors, and found the following,

1) All custom library parameters are not registering on the device page

2) All parameters are still fully readable on the modscan application (meaning no communications issues)

3) Custom units keyed into the custom library frame edit page does not appear on the device page

Appreciate the input of others who may have observed similar issues with the custom library device generation on the Com'X510 (and potentially also on the Com'X200/210).

[JamesJeanette]

Hi Kuan.

Let's pull in some engineers to help see if they find the issue.

Until then, have you had a chance to review: ?

- FYI - Can you help?

James

[KuanKhoon]

Hi James,

Thanks for your assistance. I have experience since the beta version of Com'X200 in terms of custom device generation and have also significant experience with the EGX300 in terms of custom device generation. In fact, I have gone as far as altering the firmware .UPD file to give me 1 minute logging on the EGX300. **Hacker Mode**

[Anonymous user]

Hello Kuan

About CW and HW ,

I have noted a small mistake in the custom model due to modscan labels "address'" :

The word "register" is coming from the PLC programmation and starts from 1 (it may also be prefixed by 30 or 40)

The word "address" is used by modbus and starts from 0.

Modscan uses "Register" (even if the field is labelled "address") while

the Com'X custom library uses "address"

==> for a Veris CW sensor in order to read register 30001 to 30003 (as shown on modscan)

it is necessary to build a custom model starting at address 0 (and not 1)

I have a question about the way you connect your Modscan to the Veris :

Thanks to your screenshot, I can see that, when you do the test on the Com'X, you connect directly the Veris to the serial port of the Com'X.

But I cannot see how is the modscan PC connected to the Ceris :

do you remove the Com'X master, (and use the Modscan as a modbus-RTU master)

    In that case you must use the same slave ID from Com'X and from Modscan

or do you use the "modbus gateway" feature of the Com'X (and use the Modscan as a modbus-TCP client of the Com'X) ?

    In that case you must use the slave ID from Com'X and the local ID from Modscan

I will check the PM3255 issue

    Regards

    Jef

[Anonymous user]

About PM3255 voltage :

Create a modbus-RTU model

Set "Endianness to "Big Endian"

Create a modbus frame starting at address 3027, for 6 numbers

Map the voltage as following (Voltage A-N= 3027, Voltage B-N=3029 and Voltage C-N=3031)

Declare a modbus slave, it should works as the following:

You can also import my model to test it

     Regards

     Jef

[Anonymous user]

About the PM3255

I have noted that one test has been done with the Com'X 510 trying to reach the PM3255 as the slave ID 1, which is not supposed to exist,

That may explain the issue.

Please note that when you have the "!" yellow sign, you can get more details on the error by letting the mouse over :

     Regards

     Jef

[KuanKhoon]

Hi Jef,

Thanks for your deep dive analysis into the situation. Modscan32 was connected to the Veris CW and HW sensors through Modbus TCP/IP via the ComX 510 utilising port 502. That is how I confirm that there are no wiring or physical communications issues present when executing the custom device generation. If the Modscan32 registers a reading, the communications would be working as expected.

As to the modbus "address" versus "register", think it would be prudent to put an addendum inside the TVDA or user manual to ensure that the person commissioning the ComX devices understand the need to decrement the modbus addresses obtained from the compliant devices when they enter that into the custom library page. This is very often an easily glossed over fact that they are different.

All our modbus enabled devices declares their "register address" (note : we mentioned 2 very different terms in one single phrase) hence Voltage A-N which is declared as 3028 now needs to be decremented by 1 when inputting to the custom library frame edit entry. All these makes for very inconsistent commissioning requirements and can result in confusion. To streamline all these from the end user point of view, what they see if what they key into the device will be the best. No adding 1 or subtracting 1, consistent commissioning process.

Any feedback regarding the custom unit not showing? I am quite surprised that the ComX series does not have a standard reading called "temperature" and units "F" or "C" when the ComX analogue inputs supports PT100 temperature probes.

Best Regards,

KK

[KuanKhoon]

Forgot to address one point you brought up. The PM3255 on slave ID 1 screenshot was one which I was testing what will the GUI show if the communications to device was completely invalid versus invalid modbus register parameters. It is loosely related to the custom device generation testing above as I wanted to ensure that it is not a ComX to Modbus RTU communications issue that is hindering the successful integration of the Modbus RTU.

[KuanKhoon]

Hi Jef,

I followed the address decrement 1 to get the modbus register reference for PM3255, iEM3155, Veris CW sensor and HW sensor. I am getting some very funny results on my Com'X 510.

Using the PM3255 and iEM3155 custom library to generate a device results in the below screenshots,

The Veris HW and CW sensors are giving me rubbish values (I show the CW sensor only below, the HW is similar),

The CO2 ppm at the time was around 500 and humidity is around 70% and temperature is 29.5 celcius. Note the custom units for temperature is not showing.

I have also attached the custom library files, if you can import them into the Com'X 510 on your side to test and isolate if my unit here is faulty (or has faulty firmware). By the way, the hardware and firmware details as below,

Application version	1.0.12
MCU board FW version	2.2.6
Root Partition version	4.1.6
Soft Partition Version	1.0.12
Hardware version	5

[KuanKhoon]

Another thing, you mentioned in the earliest post that the word "register" is coming from the PLC programmation and starts from 1 (it may also be prefixed by 30 or 40). Hence I take that if the Com'X510 is requesting a register, we key in the register that is declared by the manufacturer and we are good to go.

Below, is the screen shot of the "diagnostics" page on the "read device registers" tab,

This is what was documented in the Veris datasheet,

Why is the Com'X510 not reading the first register when it was commanded by the interface to do so?

[KuanKhoon]

Hi Jef,

Was testing the ComX 510 further to zoom into the custom device generation and found that if any devices reads INT64U or integer 64 bit unsigned, device generation will fail. This is shown as below,

and the results as below, product creation error on the device page,

Once again we execute using the INT64 version (of which is wrong as our per phase energy register on the PM3255 is declared in INT64U) without changing anything else,

the device generation is successful, obviously the readings are totally incorrect,

You can check that on your end and update this thread with your findings also. Thanks!

[Anonymous user]

I have noted that something is may be not clear :

Each time you create a modbus device, you must enter 2 identifiers :

• the Slave ID and
• the  Local ID.

The Slave ID is the modbus slave ID used by the Com'X to communicate with the modbus device,

it must match the value that is configured in the physical device itself

The Local ID is the modbus slave ID used by a Modbus-TCP client to communicate with the modbus device,through the Com'X

This is a virtual slave ID

Example :

a ComX 510 (IP 192.168.0.10) reads PM3255 and iEM3155 (directly connected to its serial port,

but also a PM850 and a PM710 connected through an EGX300

Hello Kuan

The Com'X uses slave ID 2 in order to access the iEM3155,

The Modscan / PC uses slave ID 5 in order to access to the same iEM3155,

This modbus gateway feature is interresting in case there is a Firewall between the Modbus-TCP application and the Com'X.

This enables to access all devices with only one exception route in the firewall

     Regards

     Jef

[Anonymous user]

Hello Kuan

I aggree, Modbus is a very old and simple protocol, it is its strength but also its weakness.

About registers and addresses, in order to understand the difference, it is necessary to know that there are 4 types of object in modbus protocol :

Digital inputs (Boolean that cannot be modified by the PLC)     can be read by FC02

Coils (and internal boolean that can be modified by the PLC)     can be read by FC01

Inputs register (Analog input that cannot be modified by the PLC)     can be read by FC04

Holding registers (Internal registers that can be modified by the PLC)     can be read by FC03

In Electrical distribution the protocol has been very often simplified in order to keep only the holding registers,

and in that case, it is not easy to understand why people are not just using the word "register".

In the Com'X, we have implemented the 4 reading function codes, and that's why the parameter is the address and not the register

(Because the word "Register" would not be consistent when entering a boolean frame).

Anyway, your remark is very interesting, and I will push to improve this feature.

     Regards

     Jef

[Anonymous user]

About temperature

The variable exist, but is not ordered in an alphanumeric order

(The order of the variables depends on the most commonly used variables)

You can find the Temperature at the end of the list (after the electrical variables)

The unit includes °C and °F

Regards

Jef

[KuanKhoon]

Hi Jef,

Unfortunately your network does not apply to me. I did mention earlier that all my devices are connected

via one single RS-485 daisy chain to the ComX510. I repeat the daisy chain addresses below for your convenience,

(Note: I have not updated my network diagram with the ComX510. The EGX300 has been substituted with the ComX510)

Modbus Slave Address 1 : Intentionally Left Unpopulated (prevents clashes when new devices are brought online)

Modbus Slave Address 2 : PowerLogic PM3255

Modbus Slave Address 3 : PowerLogic iEM3155

Modbus Slave Address 4 : Veris HW Wallmount Sensor (Humidity & Temperature)

Modbus Slave Address 5 : Veris CW Wallmount Sensor (CO2, Humidity & Temperature)

Modbus Slave Address 6 : Veris CW Wallmount Sensor (CO2, Humidity & Temperature)

Modbus Slave Address 7 : Veris CW Wallmount Sensor (CO2, Humidity & Temperature)

Appreciate your input to the issues raised which I summarise below,

1) Custom library utilising INT64U results in failure of device generation

2) Custom units are not showing on the device view even when entered in custom library

3) Diagnostic page issues. Keying in the register number 1 does not read register 1 on the Veris CW device eventhough it is as declared.

Best Regards,

KK

[KuanKhoon]

Hi Jef,

Beg to differ. on the above. I cannot find the temperature variable in the ComX510 drop down list. Below is the screen captures for the frame edit "name" drop down

Please check if you are using the ComX200/210. We are discussing about the ComX510 here. In fact, from the above, I can also see that the ComX510 does not have the "level" in the name selection also.

Best Regards,

KK

[Anonymous user]

you have entered the following settings :

==> the Com'X is correctly configured to read data in the CW sensor (Slave ID=5 : this is consistent with your drawing)

But if you want to read the same data from modscan/PC, you must configure your modscan to read data in slave "1"

(Your modscan / PC must be consistent with the "local ID"setting)

In the screenshot of modscan, this was not the case,

     Regards

     Jef

[Anonymous user]

I am using Com'X 510 version 1.1 !

It should be available very soon

Sorry for the mistake.

I cannot downgrade my Com'X 510

     Regards

     Jef

[KuanKhoon]

Hi Jef,

Not quite sure what is the rational of having some slave address remapping capabilities. Can you enlighten the community the intended use of this feature?

This feature poses significant risks to our power monitoring expert projects which will eventually use ComX devices in place of EGXs when obsolesces hits the EGX range of products and before Link150 is launched. If someone alters the ComX settings, it will break the communications between the PME and the Modbus RTU devices.

Anyway, I have set all the slave ID and local IDs to be the same. Hence the polling of the devices on Modscan32 will be identical to that of the ComX510. Below are the results of tandem polling of the ComX510 and the Modscan32 tool,

For slave ID: 4, local ID: 4

From Modscan32 on 192.168.20.3:502 for device ID: 4

The Veris HW polling frame in the custom library is as follows,

Repeated for slave ID: 5, local ID: 5

From Modscan32 on 192.168.20.3:502 for device ID: 5

The Veris CW polling frame in the custom library is as follows,

The values obtained from the ComX510 is completely wrong. We are not sure how did the device obtain the zero values or the 1500 value for the ppm CO2 level.

[Anonymous user]

I will first reply to your question

"what is the rational of having some slave address remapping capabilities"

A first quick answer is :

    "This was a feature of the EGX300, and the Com'X 510 is supposed to replace the EGX300"

But we have now to understand "why this feature was developed in the EGX300 ?"

The reason is that :

1. it simplifies the configuration in case a modbus-TCP client such as a Scada is connected to the devices through a firewall.
2. In future version, this will enables to offer a modbus gateway for other protocols
   

In order to illustrate the first point (simplify configuration with a firewall):

Let us suppose that we have 3 PM800 directly connected to the serial port of the Com'X, and 3 other PM800 connected through an EGX100.

Each group of PM800 have slave ID from 1 to 3,

In the Com'X configuration :

the 3 PM800 ("A" to "C") directly connected have local ID 1 to 3, and

the 3 PM800 ("D" to "F") connected through an EGX100 have local ID 101 to 103.

The architecture is the following :

In the Local scada, there are 2 possible configurations :

1) Without the "Proxy" feature (Scada configuration in  red) :

the scada reads the values of the PM800 "A" to "C" in the Com'X, and reads the values of the PM800 "D" to "F" in the EGX100

2) Using the "Proxy" feature (Scada configuration in  blue)

the scada reads all the values of the PM800 "A" to "F" in the Com'X.

In this case there is no real advantage to use the "Proxy" feature

Things will be different in the case of a remote scada that must go through a firewall :

As the remote scada is outside the local network it is necessary to setup some exception rules in this firewall

There are 2 possible configurations :

1) Without the "Proxy" feature (Scada configuration in  red) :

there must be 2 exception rules in the firewall, and the remote scada must differentiate the com'X and the EGX by using different ports

2) Using the "Proxy" feature (Scada configuration in  blue) :

1 exception rule in the firewall is enough, and the remote scada has only to communicate with only one modbus-TCP server (and only one port)

In this case, if we use the "proxy" feature, it is much easier for the IT to manage its firewall

By advance I can just mention that the development team is working on a zigbee interface, and a "Zigbee to modbus gateway" feature

In this new feature that will be implemented in the Com'X, the local ID will be used in order to present a Zigbee device as a virtual modbus slave

Regards

Jef

[Anonymous user]

Hi Kaun,

I had a similar issue on a Com'X 200 at the start of the year. If you go on the yellow warning triangle it gave a message something like Unexpected result.

I've only read your original post and not other answers but it sounds similar.

Are you using Internet Explorer to set up the custom device types?

This does not work - Use Chrome to set up and save.

I could view using either once they had been created.

Hope this helps

[KuanKhoon]

Hi Neil,

Was a little caught up in work and the testing took a back-burner for a while.

Tested the configuration using Internet Explorer (Windows XP, 7, 8, 8.1), Microsoft Edge (Windows 10) and Firefox 39.0. All fails.

Tested your suggestion using Chrome and it work!

Now this is interesting as our PME software and SBO all have levied warnings of using Chrome to access the platform stating unspecified errors may occur and the ComX 200/210/510 platform needs to use Chrome.

Think this is for the development team to reply, why all these inconsistencies?

[Anonymous user]

Kuan,

It took 3 months of pain for me to find this as I was new to Com’X 200s and concentrated on my lack of skill.

The device was being used by a tenant on a site where the landlord had PME 7.0.1.

I had to use the PME PC for configuration so I am aware of the chrome/PME issue also.

I believe the issue is being fixed in a new firmware release which may have happened by now.

Best regards,

Neil Dove BEng (Hons)

VAR Services Ltd.

27 Main Road

Jacksdale

Nottingham

NG16 5JU

Tel 01773 603110

Fax 01773 603112

Mob 07899 996551

<mailto:neil.dove@varservices.co.uk> neil.dove@varservices.co.uk

<http://www.varservices.co.uk/> www.varservices.co.uk

Registered Office: 7 Brinsley Hill Jacksdale Nottingham NG16 5HT

Registered Number: 3153229 England

The information in this email is confidential and may also be privileged. If you are not the intended recipient, please notify us immediately. You should not copy this e-mail or its contents or use it for any purpose nor disclose its contents to any other person unless authorised to do so.

Although this email and any attachments are believed to be free of any virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by us for any loss or damage arising in any way from receipt or use thereof

[JamesJeanette]

Hello KK,

We do recommend Google Chrome for the Com'X platform.  We are also aware of some issues using other browsers, and we do have this on our list to enhance within the Com'X...but I do not have a date in which I can share yet.

[KuanKhoon]

Hi James,

The thread is getting a little too long to read. I'll start another thread to update some recent finding after updating to firmware 1.1.44.

Best Regards,

KK

[JamesJeanette]

Thanks KK

[JamesJeanette]

Hello everyone.

We have released Com'X 510 Firmware Version 1.1.45

Bug Fixes:

* [artf147374] : Custom Models - The custom device types units selection is not honored

* [artf147373] : Custom Models - The use of a fractional "Factor" is not properly supported in the Com'X 510 for all register formats

* [artf148188] : Custom Models - Function code x03 is used when x04 is specified

* [artf147384] : Custom Models - Overlapping frames causes topics to go offline

* [artf148273] : artf148273 : Energy Dashboards - Date Picker in Dashboards Does Not Honor The Date Time Format

On The Exchange Community:

https://community.se.com/docs/DOC-13405

On Shopping Kiosk:

http://shoppingkiosk.schneider-electric.com/doc_info.aspx?DocRef=ComX510v1-1-45_Firmware_EBX510&isdv...

I have also applied the update to our Com'X 510 demo in case you do not have time to upgrade yours.

Link: http://comx510.myenergyserver.com

Username: demo

Password: Com’X510

James

Robert Jennings

jef Maubert