Flex I/O Analog configuration in ControlLogix

[JohnCalderwood]

Hi Guys,you know it is serious if I am asking questions....

We have a ControlLogix PLC that was migrated from a 1771-PLC5 using Rockwell's hardware conversion kit and their software conversion. This was done by a 3rd party supplier, who are no longer on site.

The remote racks are on Remote I/O and are Flex I/O (1794-ASB) with a mixture of analog and digital modules. They are connected using a DHRIO module in the ControlLogix main chassis.
The analog cards are now communicated with using MSG instructions, whereas as before they were BTR/BTW instructions, and on the Hardware I/O configuration we could see the individual channels on the analog cards, including data and signal type (4-20mA).
The existing analog signals that were there in the old PLC are working perfectly, but I have a feeling that not all the channels were configured, as when we now try to add a signal to an analog input card (1794-IE8) it cannot be read.

On the PLC hardware tree, we can only drill down to the racks and adapter modules, but even when we try and "discover modules" there are none seen.
What we would do in the past (on the PLC5) was access the channel info and change the 4-20mA to 0-10V, and back, then accept edits, which would download configuration to the module.

Now I have no access to the modules like that.....

It only appears to be on the Flex I/O via DHRIO cards, as we can see properties on the Point I/O modules and other Flex I/O racks, but they are through ethernet adapters.

Any helpful suggestions are appreciated.

John

 

[Paullys50]

It's been a few years, but the MSG instructions act like the BTW/BTR that you are used to seeing in the PLC5. If you open the MSG configuration it should be setup as a BTW/BTR IIRC. Flex over ethernet on a controllogix is very easy, it's all configurable from the hardware tree. But not so with the RIO adapter. Pretty much lean on your BTW/BTR experience and read the manual on MSG instructions.

I'm sure there are tech notes about it as well.

The MSG should be writing similar configuration data to the FlexIO as the previous BTW/BTR did. So if you review what is being sent by the MSG you should be able to correlate it to the BTW/BTR world. I would give the integrator a call, I'm sure they'd give you a quick run-down.

 

[JohnCalderwood]

geez......

ok, so we have lost the lovely picture of the module setup that made it easy to understand.

I got an email from Rockwell Support and for the 1794-IE8, he directed me to section 4-5 of the User Manual, and as it is now a MSG instruction for the modules, you have to interrogate the bit patterns based on the manual's setup tables.

It also did not help that the conversion gives you these new rungs for MSG and tells you they should be "Manually Verified", but they throw in preconditions for the MSG Write and Read that are not suitable for every occasion (power up and rack fault). Once these were set to write on a regular basis, then it appeared to work.....

As you say Paully, compare the versions and make sense of what we had and what we now have - just as well we also have the old PLC5 version of the program.

 

[OkiePC]

I am in about the same boat as of today. The PLC-5 to Controllogix migration at a customer was done apparently by minimalists. The BTR and BTW for each of about 8 analog modules is programmed simply to trigger each when it is not enabled. This might be fine and dandy when everything is perfect, but... the customer had another issue on the same RIO network. They lost two obsolete softstarters (SMC dialog) and replaced them with SMC Flex and 20-COMM-R modules.

I am not 100% sure, but it appears that when fiddling with the settings (while the rest of the machinery attempted to run) that the BTR/BTW got fouled up. Maybe the DHRIO module "filled a queue or buffer"? Maybe the Flex I/O modules said "enough is too much" and brain-locked? There was no error checking going on and with all those writes and reads happening as fast as possible, all of the analog signals "froze".

I added some quick and dirty rungs to check the ER bits of the MSG (block transfers) for each and a counter to show me that they were indeed getting errors (Windoze didn't show me the money ). I set the counter to a preset of 50 and when DN, I set the TO bit of the MSG instructions. For some of them, this was enough to set her straight and away she went. For others, I had to power cycle (RIUP) the analog modules to make them "wake up".

I did not yet add conditions to the MSG (BTW) for the analog configurations to limit their frequency and did not modify the rung logic of the instructions just yet, I was just trying to get the machine to run (1/3 of it can still work with good analog data) so I could try to figure out what went wrong in the set up of the SMC Flex modules.

So, I need to find the best (or better) rung structure to trigger the BTW messages for analog configuration as well as proper error checking for the BTR messages. It has been too many years since I worked with the PLC-5, but I believe I should be able to mimic the rung structure that I have used in the past and perhaps interlock them.

I can't post the code, but I can maybe come up with some snippets and get some info about the routine frequency and other basic info. I think my issue with the SMCs may warrant another thread if I can't figure it out with a little sleep and some research. It might be a 3-wire vs. 2-wire thing, a wiring issue or a plain and simple difference between the SMC Dialog and the Flex. Anyhow my main question is like John. What bits can I query that best can tell me if a module has been removed or lost its configuration? and any tips or examples of "good" rung structure would be welcomed.

This is for 1794-IE8 and 1794-OF4 modules.

Thanks,
Paul

 

[Paullys50]

Been awhile for me too, but for the configurations of the IO cards, that BTW really only has to happen when everything first powers up. The configuration won't change so no need to constantly write the same configuration data over and over.

IIRC the PLC5 could generate some of that BTW/BTR code structure for you or and example was in the help files. I think the write configuration was just on first scan, and perhaps a second parallel trigger to manually trigger it if needed. Pretty sure we just mimic'd that recommended structure. I don't have RSLogix5 installed right now so I can't confirm my reference, but it's something to go on.

For the actual analog data, then to get it as fast as possible the BTR (analog in)/BTW (analog out) was setup to constantly trigger off the enable, think we had some error detection logic as well just to reset it. I'll try to dig something up.