# Modbus adressing Akytec

**URL:** <https://forum.inductiveautomation.com/t/modbus-adressing-akytec/51184>\
**Category:** Ignition\
**Created:** [September 21, 2021, 11:47am UTC](https://forum.inductiveautomation.com/t/modbus-adressing-akytec/51184 "2021-09-21T11:47:49Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [September 21, 2021, 1:00pm UTC](https://forum.inductiveautomation.com/t/modbus-adressing-akytec/51184/6 "2021-09-21T13:00:23Z")

</div>

Don't read 4064 with HRF--the table says that one is 16-bit. Only use HRF on the 32-bit floating point registers. Also, these addresses are all "zero-based" instead of "one-based". Ignition's driver defaults to one-based. You probably need to change that in the device settings.

I also noticed in the manual that the log file, if you need it, must be read with function code 20. Ignition's native driver cannot do this. If you need it, you will need something else, like my alternate driver:

> [@Automation Professionals' Advanced Modbus Driver](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/20):
>
> Another pair of release candidates. I was playing with an Automation Direct P1000’s RS485 port this past week and discovered another CRC bug. ): In my prior testing, I was using registers that were steadily counting. The bug I found was that a CRC with bit 15 set was erroneously sign-extended to 32 bits, and then rejected. But the register was changing fast enough the half that were getting through were hiding the half that were being discarded. RTU must not be very popular with any of y’al…

---

_[View the full topic](https://forum.inductiveautomation.com/t/modbus-adressing-akytec/51184)._
