FieldPoint Family

cancel
Showing results for 
Search instead for 
Did you mean: 

cfp1808 as dumb IO

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?

Q3. Can I poll the channel in groups, if so, across multiple modules in the same rack?

Thanks to anyone if they can help of offer advice.

0 Kudos
Message 1 of 7
(5,071 Views)

This is the same answer I posted to your similar query in the other thread.

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

Message 2 of 7
(5,060 Views)
Aaron
 
Thank you for your reply. Just to clarify a point, if I use and 1808 and access channels with modbus over tcp/ip this is completely seperate to using the event driven logos protocol?
 
I want a fine degree of control over the reading of the channels and although there will be network traffic from the PC to cfp1808 requesting data (ie modbus read holding register commands) is it your opinion that this might be faster than using the event firing logos protocol? I would have a number of channels that I want to read at 100Hz and a number at say 1Hz. The former would be used in a soft realtime process and the latter would be slower channels perhaps temperatures. Please bare in mind that the moment I get a reply from the device using my raw socket approch I can act upon the data in the same executable process whereas logos event firing into labview or into a process using an OPC server will have a time penalty.
 
In the system there is a requirement for 3 cfp1808's with a varity of slow and fast channels, if I were to replace these with embedded controler types running labview realtime I can imagine that local io per each channel would be much faster but if a feedback channel or process output channel for a particular process happened to reside in one of the other two embdedded controls what would be the update time for channels to be shared accros modules? Would this be faster or slower than my manual brute force reading and writing of channels from a central PC using raw sockets in an efficient win 32 process. It is my gut feeling my technique would be faster as I would be able to poll the important process channels at the required rate where as like you suggest the logo protocl may stall the update when sending data with mixed module update times.
 
It is a cost consious project, I know that using a central PC running a simple c++ program is far cheaper than 3 embedded controllers all running labview realtime but because I dare to suggest not using labview rt or otherwise I am not getting very helpful advice from my local NI rep, I think quite frankly at this level they dont know. What I really could do with is speaking to a member of the cfp1808 development team, but any help or advice from anyone even if it is an opinion is helpful to me.
 
Thanks and Regards
 
Andrew
0 Kudos
Message 3 of 7
(5,056 Views)
Andrew,
Yes, using the cFP-1808 with ModbusTCP is different than using the cFP-1808 with Logos.
 
The cFP-180X series started development after I left NI, so I can not answer your questions definitively since I have not seen any benchmarks or comparision tests. Likewise, I do not know some of the low level implementation details so I have to make assumptions as to how I think it likely behaves. My guess (and this is only a guess) is that the implementation has the network module continuously scanning the IO modules for the current values and buffering data locally. Then, on a Modbus read, the locally buffered data is transmitted in response to the read. I would suspect that a write command would immediately be written to the IO module rather than locally buffered. Overall, based upon some LabVIEW RT programs written by co-workers for testing purposes for high speed broadcasting, I suspect the Modbus TCP approach may provide better performance in some ways than the Logos approach.
 
Logos does not necessarily stall data with a mix of high speed/low speed modules. Rather, the network module scans all IO modules, compares current values to last values, sees which values have changed (or changed greater than deadband), and transmits all of the changes, then repeats. Thus high speed rapidly changing signals will be transmitted more frequently than low speed or infrequently changing signals. The high speed signals rapidly changing signals are limited based on the speed at which the network module is scanning all of the attached IO modules, not on the slowest update rate.
 
Regards,
Aaron 
0 Kudos
Message 4 of 7
(5,006 Views)

Aaron

 

Thanks for your response. There is only one way to find out I guess and that is to try it. Therefore I have ordered a cfp1808 and a bunch of modules. I will post my findings (in about 3 weeks) for the benifit of anyone else who may want to do this.

Regards

Andrew

0 Kudos
Message 5 of 7
(5,002 Views)
Andrew,
 
How is your project moving along for you?  Is it working out?
 
Thanks,
Hany
0 Kudos
Message 6 of 7
(4,687 Views)

Hany,

Excellent. The performance of the direct modbus over Ethernet connection is very good. In terms of update time over the wire it does not seem to matter what modle I am reading or writing to. I dont have detailed timings but it is brisk, basically the packet comes back within a few ms indicating 100 Hz is possible.

One good feature is that you can still use Measuremetn and Automation explorer to configure the channels (filters etc) and read back the engineering units rather than the 16 bit adc conversions ( you can read both) the EU values come back as 4 byte floating point numbers that requires a tiny bit of unsafe code in C# to force the 32 bit data into a float.

One slight down side is that is is necessary to read each module independantly (1 to 8 channels) as there are massive gaps in the modbus memory map. If you try and read from an unallocated register a modbus error packet is returned. This means that I have to have multiple read - write request repsonse packets but this is OK as it means I only write to relays and outputs when they change in my program and ready things like temperature much slower than analogs I am using in slightly faster processes. I think if you wanted 100Hz from say all 8 modules it would not be possible but from one or two it is OK.

Overall, It is a very good product and will use it again. It was chosen because of the varity of signal conditioning avialable and customer preference for NI, there are cheaper modbus devices on the market I suppose. I have used modules from Acromag but the firmware in those hang for me and I think NI CFP is a far better product.

Dont know how it works in the Labview world as I currently dont use this.

Hope this helps someone.

Andrew

0 Kudos
Message 7 of 7
(4,678 Views)