Unable to communicate with Visilogic on Modbus Communication

[Ebenezer]

I am trying to communicate with PH Sensor via Modbus, I was able to communicate with the PH Sensor on my laptop using ModScan64 Software using Register Address 8193 as provided by the manufacturer, but I was unable to communicate with it on Vislogic. I connected the Sensor via MJ10-22-CS66. I also set DIP Switch at the back for RS485 yet no communication.

Using ModScan64, I was able to get the parameters for:

8193 for ORP Value

8194 for PH Value

8196 for Temperature

Please how do I write these Register Addresses on Visilogic to poll the data for these parameters from the PH Sensor?

Please find attached the program and the document for the sensor

sup-ph8001-ph-sensor-user-manual.pdf ph 8002 communication.pdf PH Sensor.vlp

[Ausman]

Remember the PLC offset by 1 for register addressing

[Ebenezer]

I have done that, no value. 

[kratmel]

Try 8193 (8192)...

[Ausman]

Also, you're asking for 6 consecutive registers to be read.  The sensor may not like doing such a read.   Given your addresses are 8193, 4 & 6, you could drop your read attempts back to 4 initially and see if that works.  If it doesn't then drop your read length to 2, which should cover 8193 & 4.  If THIS doesn't work, try reading only ONE register. 

Various sensors have different ways of handling sequential and non-sequential numbers.  Quite a few I work with I have to read individual registers to get everything i want out of the unit.  For multiple registers needed, this can be very annoying.  I have one modbus device where everything useful is not sequential, it has internal usage in between,  and it also doesn't like a long sequential read so I can pick registers I want from the total read.   Has to be one by one......

I had a quick look at your vlp, and it all seemed ok apart from my suggestions, but I might have missed something else.

If none of that works, then it is likely that the sensor is not using holding registers, try another type.  Sometimes "standards" are not used.

cheers, Aus

[sgull]

You have 0 in total sessions and also 0 in acknowledgements.

are you sure that this modbus function is in a net that is being called?

[Ausman]

Denis, when I looked at the vlp, it's in the main routine.  I assumed that what is shown is via a fresh init.  But it does give rise to Ebenezer trying an online trigger of the function, in case something is astray with the calling method, that I haven't seen.

Further to my post above, Ebenezer, when you did your testing with the PC, did you try consecutive reads and did it work ok? 

Also,  have you tried inverting the connections to the sensor?  And termination resistors in and out of the circuit?  485 has quirks, and sometimes what is meant to be.....isn't!

cheers, Aus

[Ebenezer]

Dear Ausman and Sgull, thanks for your support. I dropped the length of the vector to 1 yet, it dd not read. Find attached image of the values I got when using ModScan64 with my laptop 

[Ausman]

Annnddddd, what about the connections etc?

[Ausman]

After looking in detail at your screenshot again, I've just realised what Kratmel was saying earlier.  You are actually asking for too much in the RHR, as the function block already knows  the type of register.

Kratmel rightly suggested changing the D# to 8192.  I initially thought he was referring again to the offset I had spoken of.  I think this is the hiccouph.  Change it to just 8192 and you should be able to do consective reads, and then pick out what you want.

cheers, Aus

[Gabriel Franco]

According with Modscan results, you must modify Modbus block:

- Slave ID: 1

- Slave start of vector: 8193

- Vector length: 10

[Ausman]

Just noticed something in your Modscan screenshot.  You are communicating to ID 1.  Yet in your PLC ask you are trying to reach ID2.  You need to change your sensor's ID, using Modscan to set the sensor's ID to 2 (or higher). 

Many Modbus devices default to ID1, and building your plc program to allow the plc to change the parameter, and also not have conflicts in addressing, is a good idea.  For instance, I often make the PLC ID 10.  This is purely abitrary, but it is NOT 1.  So any new modbus device can be put on the line, and the plc can set it appropriately using built in coding.

cheers, Aus