cFP-1804 MODBUS settings

[ITEM]

Hi! I communicate to the cFP-1804 as a MODBUS Slave and I am able to communicate but i have not found the proper literature to configure my channel adresses or anywhing else. I am tryin to avoid usin LabView or any related software.  PLEASE Help me!

DANIEL.

[TommyTestBoy]

Daniel,

You cannot configure the FieldPoint hardware via Modbus commands.  You have to configure the 1804 and its modules either through MAX or LabVIEW, or if you connect to the 1804 over serial, then you can programmatically configure the hardware outside of LabVIEW using extended Optomux commands.   Extended Optomux commands are documented in the FP-100x Programmer Reference Manual which is installed with the FieldPoint driver.

-Tommy

[Khalid]

I think Daniel wants to know how to address the Modbus registers on the cFP-1804. You don't have to use LabVIEW to use the cFP-1804 as a Modbus Slave, right? It should be like any other Modbus Slave with a TCP interface.

-Khalid

[TommyTestBoy]

To be clear, yes, you can use the cFP-1804 as a Modbus slave anywhere, you do not need to use LabVIEW.  I may have misunderstood the question - the point of my previous post is you cannot use Modbus to configure your FieldPoint modules (e.g. power up values, watchdog settings, ranges, etc.).  If you are looking for documentation on how to map Modbus addresses to FieldPoint I/O, then there is a document called FPModbus.chm that you can get from the cFP-180x firmware download from National Instruments.  Here is the link to a Knowledge Base that explains how to get the download: http://digital.ni.com/public.nsf/allkb/19f7e58948f4736d8625714600506e9b Hope this helps. -Tommy

[ITEM]

Thank you, yeah that is what I meant. Anyhow. I appreciate the help. THANKS AGAIN.

[Dynamotive]

Hi chaps

I have a potential scenario where I would use multiple cfp1808 backplates with various modules installed.

They would all be connected to a decent spec PC running XP on a dedicated network

I wont be using Labview but talking directly to the modules using modbus over TCP/IP. I have a very good understanding of this protcol having written drivers for PLC's for many years and for various complex reasons wont be using Labview.

I have read the indivdidual datasheets and all modules have various updates times. These times are presumerably the conversion times of the various ADC's etc including filtering etc and not the time to access the modules over ethernet.

Q1. Has anybody had experience with the update rate I can expect to achieve by polling the various Modbus addresses from my PC over a quiet ethernet connection? Is the modbus firmware crippled in anyway to force people to buy labview realtime to get decent performance?

Q2. Does the presence of a slower module effect the performance of a faster one?

Thanks to anyone if they can help of offer advice.

[Aaron_G]

Q1: Can't help you as much with this one. The cFP-1804/8 came out (and started development) well after I left NI. I tend to doubt that they were crippled in performance in anyway when using the modbus interface since they are designed as network IO interfaces and not LabVIEW RT targets.

Q2: A mix of slower and faster IO modules does not have an impact on the performance between modules. The analog IO modules each have their own controller that is controlling the ADC, filters, etc... and placing the results in a shared memory buffer that the network module can access. Each module is asynchronous and independant of each other IO module.  The mix of modules does have some effect on the network traffic when using the NI ethernet protocol. The NI protocol "Logos" is based on a publish/subscribe model that transmits data on change. Thus one high speed module with several low speed modules (and rapidly changing signals) will have a different overall performance than multiple high speed modules. Since the modules are asynchronous from the network controller, the network controller may read the same value from a slower module multiple times, while missing values from higher speed modules.

Regards,
Aaron