cFP sampling/communication issue

[Enki]

Hi,

I'm currently using a cFP-2120 module with a AIO-600 module that I'm attempting to sample a voltage at 500 Hz that I am then sending back to a Host PC via TCP communications loop. I've set up a timed loop with a RT FIFO to transfer the data between the sampling loop and communications loop. The Comm loop is a simple state machine type that flips between TCP read and TCP Write provided there is no error. There is another timed loop that runs at a lower priority that reads less speed intensive values and does some controlling, not too concerned about it finishing late as long as its not introducing too much jitter. Somewhere between my RT Target, which I've set up to use the 2120 LED's to indicate late loops and indicate empty FIFO buffers, and my host pc I'm losing sampling data. I should be able to/need to catch 500 points per second on this voltage channel.

TCP communications programming is relatively new to me; so, I wouldn't be surprised if I'm losing data via TCP communications. I've included my VI's in anyone is interested though they are in a dev state and not streamlined for ease of reading or with proper documentation yet.

[Neville D]

I haven't looked at your VI's, but the sample rates for FieldPoint are quite slow. Are you sure 500Hz is possible for the hardware?

If it is, then you might try reading more samples and sending those in one shot instead of pt by pt.

ie read 100 samples, and beam them across via TCP.

Note that in terms of performance of RT targets, Fieldpoint targets have the worst performance.

Neville.

[Enki]

QUOTE(Neville D @ Nov 6 2007, 05:48 PM)

I haven't looked at your VI's, but the sample rates for FieldPoint are quite slow. Are you sure 500Hz is possible for the hardware?

If it is, then you might try reading more samples and sending those in one shot instead of pt by pt.

ie read 100 samples, and beam them across via TCP.

Note that in terms of performance of RT targets, Fieldpoint targets have the worst performance.

Neville.

The hardware spec lists its update rate at 1.7kHz, maybe I've misread that into thinking its capable of the 500Hz sampling frequency. I've also changed the advise rate for the device to 1ms, previously I had it set at 2ms.

I've played with reading in multiple samples and then transmitting them back in one block, but have actually gotten worse results from that than a straight pt by pt. Though I'm not fully sure how to implement that particular architecture.

[LAVA 1.0 Content]

QUOTE(Enki @ Nov 7 2007, 12:59 PM)

The hardware spec lists its update rate at 1.7kHz, maybe I've misread that into thinking its capable of the 500Hz sampling frequency. I've also changed the advise rate for the device to 1ms, previously I had it set at 2ms.

I've played with reading in multiple samples and then transmitting them back in one block, but have actually gotten worse results from that than a straight pt by pt. Though I'm not fully sure how to implement that particular architecture.

That spec may aply to just using the cFP as an I/O device from a PC.

Loop rates inside the cFP are dog slow if you are doing anything useful.

10Hz PID loops may work but I'd be nervous about promising anything faster inside the cFP.

Ben

[Neville D]

I skimmed through your code a bit.

I notice you are reading TC modules as well. As far as I remember they are pretty slow to update. Do you think that might be possibly affecting your update rate? The relay modules (if they are mechanical) are quite slow as well.

Another thing: do you really need data at 500Hz from so many channels? You could either read it slower, or read & react to the faster data rates, but transmit data up at a slower rate. Maybe every 10 reads average results and transmit that.

Your 3 loops are running in parallel quite fast without a breather for any of them if they start to interfere with each other. Have you tried getting rid of one of the loops to see if that speeds things up? Maybe you could interleave the TCP and DAQ loops. i.e read DAQ, transmit out, then read DAQ again (to prevent parallel loops from starving each other of time).

Like I said before the Fieldpoint isn't the most powerful platform. Also daq on it is implemented differently from other platforms. DAQ involves the processor to actually read bits of info from the various modules. Which is why if you have a lot of modules, lots of communication and high data rates, it may not be able to keep up.

I would try 1 module at the full 1.7kHz w/TCP comm and see if you get that working. Then keep adding channels until it isn't able to keep up.

Sorry, I haven't worked with Fieldpoint in a few years, but from what I remember it worked very well for low update rates. I never tried updates faster than about 10Hz, and viewed the results over a web browser to the front panel.

We built a hydrogen fueling station, and for fault tolerance, we hooked up the User Interface directly to the FP hardware via relay modules, and the software reacted to those button presses rather than comm over TCP to a host PC. The host was simply a way to monitor the action.

Neville

[Enki]

QUOTE(Neville D @ Nov 7 2007, 01:32 PM)

I skimmed through your code a bit....

Neville

Thanks, I don't actually need to read anything but the one voltage channel on the AIO-600 at 500 Hz, I checked the Comm VI to verify that I didn't upload an older version and the second read loop is actually running at 50ms with only the one voltage in the loop by itself being read at 2ms. I've tried skimming out everything but the one loop with the Voltage read and the Communication loop, but still end up losing data somewhere. I've tried interweaving the read and communications using a timed sequence inside a while loop (currently discarding any data while it initiates a connection with the host), though not gotten any better results via that method either.

neB,

You may very well have a point about that spec being applied as a I/O device and not to the real time system itself. I've been talking to NI in Austin, TX as well to see if they know of anything. Though they seemed to think that my architecture was correct for the application and we did play with slightly slowing down the communications loop so it doesn't dominate the cFP processor, though after we tried a few things they decided they needed to do some independent research and that they would get back with me on a possible solution. Though I am starting to think that I may have just read the specs incorrectly and may just have to split out that particular channel and record it via another method and then weave the data back with the rest being read on the cFP.