HC900 Modbus TCP anomaly reading

[etr]

Hello, i have a curios problem in a modbus tcp reading from a client.
The HC900's answer for the variable 20 (holding register 6375) is clear in the Hybrid Control Designer (the variabile is a simple counter of flow gas counter). The ammount of value is incremented every pulse from a digital input (total + 1).
But when i send the request from a client modbus, the value's variable is different (completely). For example the value is frozen from this morning, probably when the machine started up.

The others value read directly from analog inputs are correct.

Only this value elaborate from some blocks show this problem.

I can't understand the cpu's logic for elaboration the exchange area memory modbus.



Best regards, Ennio

 

[lfe]

is that a 32bit variable, a float or a long integer?

If yes, it is likely that you have an endianness problem, one client understands that the first of the two 16bit words is the most significant and the other understands the opposite.

 

[etr]

Hello lfe, i don't have a order byte problem on the float register.

The registers from analog input are in syncro beetween HCD and client (every second). The value from variable, no.

The modbus request is the same (3x), the problem is the same also with different modbus client.

Best regards.

 

[Contr_Conn]

Modbus is known for misinterpretation of addresses where addresses on the wire are -1 of actual registers numbers. Depending on device and software you may need to use a shift by one.
So try to read 6374 or 6376 instead.

 

[etr]

Contr_Conn is not so easy. It's not a mapping problem because the variables 20 and 17 are exactly at address wrote in the manual (with a shift of -1).

The update of this registers is the mistery because the variable 20 (a counter) is fix from this morning, in the modbus tcp visualization but in the HCD i see the increment ! And the variabile 17 (another counter) is integrate with a delay of 30 minutes with fix steps (always on the modbus client) when instead in the HCD i see every step (1 by 1).

This is not possible when i have in other part of modbus mapping the exactly values refreshed every second.

Best regards

 

[danw]

How do you know variable 20 is at register (4)6375? And that the other variables are within several registers, plus or minus of variable 20?

 

[etr]

I see the address of variable 20 on the Honeywell HC900 documentation. It' s the same that i used to read the analog input and digital output from the PLC.

The "physical" address work fine, others two variables, no.

Best regards

 

[danw]

The fixed Modbus register map for Variable 20 is (4)6375, in the HC900 Comms manual 51-52-25-111.

1. Are you positive that tag you are looking at is a analog variable on the input of a function block, like a counter, or as the example below shows, a summer block?

example: Tag = F2Z1BIAS
Variable 15
Modbus address 6465
format: Float 32

Have you examined the properties of the tag to confirm its assigned variable number and its Modbus address and data format?

2. >Only this value elaborate from some blocks show this problem.
How many places is Variable 20 used?

Why would you use it in more than one place?

3. Can you post a screen shot of the logic where variable 20 is used?

 

[JHarbin]

The HC900 Modbus TCP is so simple. Yes, you have to pay attention to word and byte order, but you have to do that anytime you have a Modbus register (float).

Dan's included image shows both the Hex and Decimal registers for the fixed map.

Of course, if you use the custom map, you don't get that information, but since you put the tags and variables in the map where you want them, you know where they are. Even in the custom map, you can show Hex or Decimal without having to figure out the correct form required by your client.

 

[etr]

https://photos.app.goo.gl/kEey3cVFeCwvcY596

https://photos.app.goo.gl/sFXuhvbRbygUcaq17


Can you see the values? In the same time. The registers in the client have a shift offset.

Ennio

 

[JHarbin]

I can see the pictures but it isn't clear to me what you are seeing. The watch window list number 20 isn't the same as variable number 20.

Provide the information as danw illustrated.

I'm offering to help because the HC900 is one of my favorite controllers. I am programming one right now. I've programmed well over a hundred with thousands of Modbus TCP registers connected to various clients.

 

[etr]

Hi JHarbin, i received a suggest to exchange the variable 20 to a fixed Modbus variable (address over 45000, exactly 45057, 45055 for my modbus client) but the result is the same.

This is my opinion : the problem is a mismatch beetween the elaboration block sequence and the modbus refresh, inside HC900. There is something in the used logic, the customer program, that collide with a right use of these function.

For me it's very easy integrate a digital signal from a gas flow counter into a register in many language, into many devices of different mark. But this is a customer device and i didn't want to modified.

https://photos.app.goo.gl/LLLegJiDh9AdFBsd9

In the picture there is the customer programm for the flow integration.
An easy sum every pulse of IMP_QUANTOMETRO (on the left, digital signal). This was the request from me to the customer programmer.

Ennio

 

[JHarbin]

That seems like a very complicated method to count. I would just us a counter block. I'd probably place it in fast logic rather than standard logic and you don't need the trigger block. It will only count each pulse one time.

If you are comparing the two variables, it probably has to do with the scan rate and the block ordering. Again, if you use a counter or counters in the fast logic, you will eliminate many of those issues.

It is under Counters/Timers and is the Up/Down Counter.

 

[etr]

I can only suppose that the counter limit at 999999 is the reason for this solution of software for the counter.

Ennio

 

[JHarbin]

Several ways around that limitation. It only takes a few blocks more. You will eventually run into the limit of floating point values so you should handle that explicitly rather than letting it just happen. If you are looking for more precision, you might want to consider 32 bit unsigned integers anyway.

Honestly, I'm still not sure what problem you are seeing in your client. If you are trying to compare the client to the HCD software in monitor mode, then you will be dealing with differing update rates.

Can you be more specific about what the perceived problem is as well as which values are being read (tagnames) as well as modbus registers?