PLC5-40, 1771-IFE Analog channels SLOW!!

Hi: I recently tried connecting 2 new single-ended 4-20mA analog inputs to an existing 1771-IFE. The IFE is in a RIO chassis. The values coming in from the new inputs (via block transfer) were only updating about every 7-10 seconds. The card jumpers were set correctly, and we discovered that the other existing input values from the card were just as slow. Installed a brand-new IFE but no change. Tried all settings and logic to run the BTR as fast as possible, with no setting changes making any difference. I do see that the program has 23 BTRs and 23 BTWs for PanelViews, DeviceNet nodes, analog outputs, flowmeter cards, etc. There is only 1 A/I card on the system. Is the number of BTRs/BTWs too high? Nothing else seems slow to update. First time I've seen this one. Thoughts?

If the program is trying to run all the BTR's and BTW's on that channel "as fast as possible", then you might be running out of buffers. The PLC-5/40 has a lot of Block Transfer capacity but you should have a look at the overall configuration and how the BT's are programmed.

Are you measuring the update times by looking at the time between changes to the analog value, or between /DN bits on the BTR ?

Are you sending configuration BTW's constantly to the module, or just when it's initialized and needs one ?

Have you checked the error and retry counters for the RIO channel to see how reliable the overall comms is ?

I did a little memory checking and verified that Bit 00 of the first word in the BTR data image is the "PU" Power Up bit that indicates the module is powered up but has not yet received a valid configuration BTW.

It is very normal to send a configuration BTW to this model of analog input module only when the BTR is completed with a .PU bit = 1.

Thanks Ken! I'll check some of those settings.

This is stretching my recollection a little, because it's been a long time since I had stick time with a PLC-5.

That screenshot is the RSLogix 5 formatted configuration window for a 1771-IFE. It knows the module is in Rack/Group/Slot = 2/6/0.

Those windows were a way for the software to show you the formatted and human-readable contents of the configuration data blocks. The software even had the ability to create and insert, semi-automatically, block transfer logic that addressed the data table sections that were used with those block transfers. That's the "Insert Ladder Rungs" feature.

But if you're going online with a project that wasn't set up with those windows, I'm not sure how RSLogix knows where the data blocks are for that module. Maybe it works backwards from BTR/BTW instructions that are addressed to a specific R/G/S address.

So I would go to the actual ladder logic for those BTR and BTW instructions and examine the contents of the BTW data block very carefully, maybe manually working backwards from the layout in the user manual to figure out if they're really set for no filtering.

A diagnostic question: on what are you basing your conclusion that the input data is changing only every 7-10 seconds ? Are you just looking at it in a data monitoring window expecting the data values to differ by a few counts, or are you putting in trap logic to determine how long a value stays the same, or are you putting in trap logic to see how often a value gets written to the BTR target data file ?

It's my *guess* that a 1771-IFE that's only updating its data every 7-10 seconds is really only getting a successful BTR every 7-10 seconds, rather than filtering out the data signal onboard with a very long time constant.

Counting 0->1 transitions of the BTR's .DN and .ER bits over the course of a few seconds is one way I might choose to diagnose what's going on with the BTR itself.

I do not know if the 1771-IFE takes a few seconds to get itself ready to collect data after a configuration BTW. I don't think it does, but again I always write my logic to send the BTW only when necessary so maybe that's an issue.