CLX RIO PLC5 Analog

[Mike_RH]

Since the comms are good to the ASB, What addressing type (1/2, 1 ,2 slot) are you using?
Which physical slot are the analog modules in?
What module groups are they? Does that match the configuration in the MSG ?

 

[Jordan546]

Does anybody have written logic and messaging for a standard IFE and or OFE in CLX? These will be set up with no scaling and no offsets. They are plain Jane settings. If I can get some that I know is working then I can try and test that. I am starting to lose my mind with reading manuals and data tables trying to figure out what exactly is wrong here. As I said before the RIO function is working correctly and I am trying to configure just the ANLAOG modules 1771-IFE and 1771-OFE2. I have set up the data array and the message is giving me the error listed above. So I must be missing something trivial. So if anybody has working logic for this application it would be greatly appreciated if you could post it and I can work from there.

I am able to run Analog using CLX for 1756 IO and I can run the 1771 IO and RIO from another PLC5 so there is something in this message instruction I am having issues setting up. I am about to say enough is enough and drop in a 1771 processor and message all of the data to the CLX via ethernet. This completely undermines the purpose of the upgrade though.

 

[Jordan546]

Since the comms are good to the ASB, What addressing type (1/2, 1 ,2 slot) are you using?
Which physical slot are the analog modules in?
What module groups are they? Does that match the configuration in the MSG ?

im using single slot addressing and the physical layout as listed above is

1771-ASB
Power Supply
1771-IFE
1771-OFE2
1771-OAD

This is only a half rack(4 slots) so the rack is full.

When operating the OAD i choose to use "PLC5_Remote:O.Data[3].x"

I have the Analog modules configured when you add a module to the RIO as [1:0] and [2:0]. I then use the message configuration tab and drop down list to these modules. The error as it shows I am getting is that the RIO does not exist or the message time out.


ps sorry for so many posts in between as I did not see the second page of this post.

 

[AllanJacobs]

just for laughs change your path in the messege to Remote_1771_IFE and/or Remote_1771_OFE

 

[Eddie Willers]

You'll find some very old and slightly misleading technotes out there about the CIP Path for a RIO Block Transfer instruction.

In v8 and older firmware, you had to add the Block Transfer Modules to the adapter configuration and make the Path go all the way to the 1771 module object itself.

In v10 and later firmware, the CIP Path only needs to go as far as the DHRIO module itself, and the Module Address box (RIO, Channel B, Rack 1, Group 1, Slot 0) takes care of directing the message to the module.

I had to remind myself of this using the Knowledgebase this morning.

General recommendations:

If you're caching connections, make sure both the BTR and BTW are configured to cache connections.

Be sure that pairs of BTR and BTW instructions cannot execute simultaneously. I like the old method, which used just "XIO BTR.DN XIO BTW.DN" as the preconditions for both messages.

What is the exact and complete error code, including Error Code, Extended Error Code, Error Path, and Error Text ?
EDIT: you did post that in Post #8, error code 0xD0.

 

[Jordan546]

I tried that now and it just automatically reverts the text to RIO.

 

[Jordan546]

What is the exact and complete error code, including Error Code, Extended Error Code, Error Path, and Error Text ?

A picture is posted several posts back of the exact error and the look of the logic is posted directly above. both the read and the write are configured to cache.

 

[Eddie Willers]

Error code 0xD0 is generally a CIP connection failure, like the message can't find the DHRIO at the path you designated.

Hmm.

How do the Channel B Link Status and Channel B Protocol Errors tabs look for that DHRIO module ? There are DHRIO error counters there that might give you some useful info as well.

 

[Eddie Willers]

It's actually suggested after v10 to *not* put the analog modules into the I/O tree, but rather to just address them in the Block Transfer instruction.

 

[Ron Beaufort]

just a quick thought - is your 1771-IFE module a type:

1771-IFE/A or
1771-IFE/B or
1771-IFE/C

the A and B series only used 37 words of configuration data - the C series would allow up to 39 words ...

 

[Jordan546]

Ok give me a minute on that one again. My system and the test bench are on two different networks so I am constantly changing IP addresses and cables. I really need another network card in this computer.

 

[Eddie Willers]

My colleagues use and like USB/Ethernet dongles for exactly this sort of thing.

Power everything off, grab a cup of coffee and a pencil, and go through the hardware carefully.

Your 1771-ASB would have to be from the early 1980's to not support block transfers, but that's not impossible. If you somehow have a 1771 chassis from that era it might not, too.

Gather the Series letters and part numbers of everything, including that power supply. Note the DIP switch settings both on the 1771 backplane and on the 1771-ASB module.

 

[Jordan546]

The Link status is attached and since my clipboard now is not working the protocol errors are all 0 except the abort and that was a 1 after i triggered the write.

Ron the module I am using is a 1771-IFE/C

 

[daba]

Just a thought that the BTW may be failing because the Channel Min and Max Scaling parameters are all set to zero in the configuration BTW data ??

 

[Jordan546]

Gather the Series letters and part numbers of everything, including that power supply. Note the DIP switch settings both on the 1771 backplane and on the 1771-ASB module.

What would the ASB and backplane dip switches affect on the Analog if the communication iteself is working?

I am now noticing that the Run light on the IFE has started flashing green since i removed it to double check the letter