Allen Bradly Logic 5561 PLC

plcbeginer1

Lifetime Supporting Member
Join Date
Oct 2018
Location
Springtown
Posts
18
Hello all,
I have an Allen Bradly Logix 5561 which talks to an ethernet card then to a DeviceNet 1756 DNB card which then communicates to several other devices.


The DeviceNet has no errors on it and shows address 00 (address assigned to this device and then says run. However the "Turck" controller is flashing GREEN which means it is connected to DeviceNet but does not exchange any information.
The I/O section of the "Turck" controller is blinking RED.



I have tried to enclose the *DNB file and also the *ACD files, however it says they are "invalid files".
Does anyone know what that means?



Please help!


Thanks
Grant
 
the "Turck" controller

Turck makes quite a few devices. The most popular of their DeviceNet modular I/O adapters are the BL20 (open style) and BL67 (washdown) modular adapters.

The fact that the 1756-DNB is not displaying a fault code for the Turck adapter suggests that the Turck adapter is not in its scanlist. That would also be consistent with the flashing green network LED on the adapter itself.

Are you adding this adapter from scratch, or trying to diagnose why it is not working ?
 
Hello Ken,


thanks for the reply.
I have checked the scanlist for the 1756 DNB and the Turck controller is listed, however when I see if the the 1756 DNB is 'configured' it says no.
The 'Turck' controller has been in place for quite some time (years) and I even replaced the unit with a NEW controller--same problem.


I could send some screen shots over.
Should they be in a zipped file as well?


Regards
Grant
 
Screenshots as jpg files should come through.

But the DNT file will be interesting.
On the Logix5000 hardware tree, where the 1756-DNB is listed, if you right-click onto properties, and the RSNetworx tab, that should show a shortcut to the DNT file associated with the project, if it exists in the same PC as the RSLogix software.
 
Hello Ken,
I attempted to load some Zipped pictures(screen shots) and while doing so the process was terminated and said I must talk to an administrator?

This is the message I received.


Your submission could not be processed because a security token was missing.

If this occurred unexpectedly, please inform the administrator and describe the action you performed before you received this error.




Thanks
Grant
 
Not sure what's going on with the screen shot.

I remember your initial post on this, and there's sort of a moving target because you've reconfigured and reloaded and replaced multiple parts of the software and hardware.

So let's take one step back: why were you troubleshooting this system in the first place ?

I assume your current goal is to establish communications between the PLC and the Turck network adapter.

If you can, please describe exactly the modules that make up the Turck network adapter assembly, including every part number and a description of their position and quantity.
 
Hi Ken,


Ok, here it goes. I inherited this down system, so I am attempting to get it running again.


First off the system is referred to as a Deep Reactive Ion Etcher made by Alcatel, commonly referred to as a Alcatel Seeder 100.


With that being said, the Turck (addressable)p/n SDNL-0404D-1003 controller that feeds the other 7 Turck Non addressable controllers ( I do not have the part# currenty) which has most of the I/O readouts on them. They have such items as pump start/ stop, position sensors (in/ out) connected to them.


The same condition exists (Turck controller not functioning), how ever I did manage somehow to resolve the error 77, and 78 on the DeviceNet card.

The addressable "Turck" controller is flashing green LED on the 'network' side and also a flashing RED LED on the I/O section.

From what I have read it is connected to the PLC/ DeviceNet however it will not accept data.


Does that help?
Thanks
Grant
 
plcbeginer1 said:
...Turck (addressable)p/n SDNL-0404D-1003...

Hi Grant,

You are using an SDNL Turck fieldbus gateway/coupling module, as opposed to a SDNB stand-alone fieldbus module. The stand-alone modules have only a fieldbus connection, such as DeviceNet, to exchange I/O data between their on-board local I/O and a scanner. They cannot link to sub-bus I/O extension modules. They can only link to another stand-alone fieldbus module, and so on.

The gateway/coupling modules ( SxxL) have both a fieldbus (bus) connection and a piconet IP Link connection. piconet IP Link is a ring topology, fibre-optic sub-bus extension network. The gateway/coupling module is the master for the IP Link extension network. This extension network allows you to connect up to 120 extension I/O modules off the gateway using a sub-bus at speeds up to 2Mbps. This sub-bus is using IP Link protocol and not the fieldbus protocol (DeviceNet). The IP Link protocol data from the extension I/O modules is mapped to the gateway/coupling module to be exchanged over the fieldbus (DeviceNet) back to the scanner (1756-DNB).

The model SDNL you are using also has 4IN/4OUT local digital I/O on-board. These are mapped directly to the DeviceNet registers in the SDNL gateway and are not part of the IP Link data structure.

The other 7 I/O modules you are referring to are most likely SNNE extension I/O modules connected via fibre-optic ring back to the SDNL IP Link master gateway/coupling module.

plcbeginer1 said:
...The addressable "Turck" controller is flashing green LED on the 'network' side and also a flashing RED LED on the I/O section...

If the fieldbus LED is flashing Green on the SDNL then the gateway/coupling module is valid on the DeviceNet network and should not be causing any errors at the 1756-DNB. Having a "00" status on the 1756-DNB would support this. However, and as you pointed out yourself, flashing Green means there is currently no data being exchanged. This means there is something wrong with the I/O data the SDNL gateway is configured to poll...

If the IP Link error LED is flashing then there is a problem with the IP Link protocol - no transmission or faulty telegrams. I would look for the last extension I/O module and work backwards until you find a module that appears healthy. The link between the healthy module and the next faulty module is most likely where the fault is. The issue could be a poorly made-off or connected fibre-optic plug/cable assembly. They can be up to 15m in length and may be field assembled, so human error, vibration, etc., could be a factor in these cases.

Also, there could be a faulty extension I/O module, no power going to one or more I/O modules (or plugged out), or a missing I/O module, as you say this was a "down" system for some period.

From what you have described, the IP Link sub-bus is most likely the culprit here and the wider DeviceNet network is otherwise healthy.

Regards,
George
 
Thank you for responding George!!


Out of desperation, I have looked at the fiber-optic IP Link sub-bus. Perhaps there is something I have overlooked.

Maybe I should invest in purchasing the fiber-optic cables?


Since there are several 'downstream' from the Turck coupler that are flashing 'RED', should I replace them to isolate the problem?


I have removed the I/O connections from the Turck coupler (as well as the ones downstream) one at a time - to troubleshoot, however the status did not change.


Thank you again!
Grant
 
Sorry for the delay in responding. I'm quite busy so I'll give you all this while I can...

plcbeginer1 said:
Out of desperation, I have looked at the fiber-optic IP Link sub-bus. Perhaps there is something I have overlooked.

Maybe I should invest in purchasing the fiber-optic cables?...

Hi Grant,

Do you mean purchase "manufacturer assembled" fibre-optic cables to replace existing "field assembled" cables?
Can you confirm whether or not there is an existing fibre-optic sub-bus in place?

Carrying on with the assumption (for now) that there is a sub-bus...

plcbeginer1 said:
...Since there are several 'downstream' from the Turck coupler that are flashing 'RED', should I replace them to isolate the problem?...

If you mean the Red LED is flashing on "some" of the 7 extension I/O modules then how many exactly are flashing or which ones if numbered in any way?

Have you confirmed if those 7 modules are SNNE extension modules?

If SNNE - what is the Green LED doing on these modules - OFF/flashing?

What are you referring to replacing? - fibre-optic cables or modules themselves?

Are the modules close to each other or are they situated some distance apart on the machine?

Please try to paint as best a picture as you can for us so we can tip the questions/answers balance a little here.

------

Further diagnosis info for the flashing sequence of the Red I/O LED on the SDNL gateway itself (not the extension modules)...

The red I/O LED flashes with two different frequencies in order to indicate an error. The error is encoded in the flashes as follows:

Fast flashing - Start of the error code
First slow flashing sequence - Error code
Second slow flashing sequence - Error code argument

When you see the Red I/O LED flashing fast, this means it is about to announce the error code and error code argument, one after the other. After flashing fast it will pause and then start the first slow flashing sequence for the error code. Note the number of flashes for the first sequence - this is the "error code". It will pause again and then start the second slow flashing sequence. Note the number of flashes for the second sequence - this is the "error code argument".

Once you know the error code and argument, you can look up what it means...

Example:

error code = 3 flashes - indicates an interruption in the IP Link bus.
error code argument = 2 flashes - indicates the interruption is after extension module number 2

Information on the error codes and arguments can be found on Page 30 in the following PDF Guide under the Indicators and Switches section:-

http://pdb2.turck.de/repo/media/_en/Anlagen/SDNL-0404D-xxxx.pdf

That Guide also has good information on the I/O Mapping and Assembly Objects.

------

I also think we should come back to this...

Ken Roach said:
...The fact that the 1756-DNB is not displaying a fault code for the Turck adapter suggests that the Turck adapter is not in its scanlist. That would also be consistent with the flashing green network LED on the adapter itself...

I had read in one Turck manual that the flashing Green fieldbus LED on the gateway indicates that it is active on the DeviceNet network but is just not exchanging I/O data with the scanner (1756-DNB). However, having read the above manual, it adds an important further possibility here...

Green Flashing
Boot Up OK, Device has executed Duplicate MacId Check and
is ON-Line. The SDNL-0404D-xxxx is not allocated by a Master
/ Scanner
, no Data Exchange with a Master / Scanner

Aside from the possibility of no data exchange, there is also the possibility that the gateway has not been allocated by the scanner. The gateway is a basic DeviceNet "Group 2 Only" device - the DeviceNet specification has a "Group 2 Only Connection Set" where a very basic DeviceNet slave, such as the SDNL gateway, must first receive an allocation message from a DeviceNet scanner before it can begin producing and consuming I/O data with that scanner. This led me back to your dnt files...

The other day I had looked at one of your dnt files (AMS100-112.dnt) in RSNetWorx for DeviceNet and the gateway is indeed included in the Scanlist of the 1756-DNB and the I/O data is mapped. There are 8 devices in the Scanlist. However, today I had a quick look at the other dnt file you provided (DeviceNet.dnt) and there is a couple of things of note:-

1. "AMS100-112.dnt" has 8 nodes, whereas "DeviceNet.dnt" has 9 nodes. There is an extra device - 1203-GU6 SCANport Adapter at node 04?

2. In the "DeviceNet.dnt" file, under the 1756-DNB scanner, all of the 9 devices are listed as "Available Devices" but none of them have been added to the Scanlist?

Why did you provide 2 dnt files, which are somewhat different, and which dnt file is valid for the actual system? The "AMS100-112.dnt" file sounds like it is from the actual machine but let's be sure here.

I also notice that you've said your gateway is an "SDNL-0404D-1003", whereas the gateway device added to both dnt files is an "SDNL-0404D-0003". This may not matter as I think the only difference is physical - "-1003" has 2 fieldbus ports, "-0003" has only 1 fieldbus port. This shouldn't matter for the EDS file. I have all the EDS files for the Turck piconet gateways registered and there is no selection for "-1003", only "-0003". If it were me and the EDS file is meant for both models then I would have made the selection say "-x003".

Another thing to note for the gateway in RSNetWorx is the fact that the "I/O Data" tab shows "0 bytes" for all message types (Strobed, Polled, etc.). The EDS file also reflects this. I think, from memory, this is because the gateway only builds the process image at startup, as it discovers what extension modules are on the sub-bus. The 1756-DNB scanner has Polled 19 bytes input and 11 bytes output configured for the gateway, so once the gateway builds the process image for the expansion modules the number of I/O bytes should fit this 19/11 byte configuration. We can only decide if this 19/11 bytes setting is correct once we know the exact expansion I/O module list.

------
To determine if the gateway process image is active to the scanner...

Have you got the Turck IO-Assistant 2 software and a service interface cable (I/O-ASSISTANT-KABEL-PICONET No.6824399) for configuring the SDNL gateway module? This can further help diagnose these issues. You can look at the current status of the configuration parameters, such as "auto configuration" = "active" or "process image" = "active" (I/O data to scanner). You can select things like whether you want "Manual reset" or "Auto reset" for the parameter "behaviour on IP-Link error" - if your IP-Link sub-bus suffers a single error it can auto reset the gateway to try to re-establish the link. Manual reset requires a power cycle of the gateway, and so on.

If you are online the "Image" tab displays the modules in a realistic view with the LED status for each module and the address number above them. This way you can more quickly determine which module(s) may be the root cause, if indeed this is where the issue lies.

You can also view the diagnostics tab for any detected issues.

It's been a few years since I worked with these modules, but it's all coming back to me, slowly. I'd love to be in front of this system with you as it would save all this typing but such as things are we'll do our best from afar.

Regards,
George
 
DeviceNet Issues

Sorry for the delay in responding. I'm quite busy so I'll give you all this while I can...

Quote:
Originally Posted by plcbeginer1
Out of desperation, I have looked at the fiber-optic IP Link sub-bus. Perhaps there is something I have overlooked.

Maybe I should invest in purchasing the fiber-optic cables?...


Hi Grant,

Do you mean purchase "manufacturer assembled" fibre-optic cables to replace existing "field assembled" cables? (manufactured fibre-optic cables from Turck)
Can you confirm whether or not there is an existing fibre-optic sub-bus in place? (yes)

Carrying on with the assumption (for now) that there is a sub-bus...

Quote:
Originally Posted by plcbeginer1
...Since there are several 'downstream' from the Turck coupler that are flashing 'RED', should I replace them to isolate the problem?...

If you mean the Red LED is flashing on "some" of the 7 extension I/O modules then how many exactly are flashing or which ones if numbered in any way? (some of them are flashing red, none are green, except the SDNL coupler-which flashes, the rest are SNNE versions)

Have you confirmed if those 7 modules are SNNE extension modules? (SNNE)

If SNNE - what is the Green LED doing on these modules - OFF/flashing?(off)

What are you referring to replacing? - fibre-optic cables or modules themselves? (Do not know -what is recommended?)

Are the modules close to each other or are they situated some distance apart on the machine? ()M1, 2,3,4 are next to each other, M5,M6 are maybe 2 feet away, while M7 and M8 are located and powered some 3 feet away

Please try to paint as best a picture as you can for us so we can tip the questions/answers balance a little here.

------

Further diagnosis info for the flashing sequence of the Red I/O LED on the SDNL gateway itself (not the extension modules)...

The red I/O LED flashes with two different frequencies in order to indicate an error. The error is encoded in the flashes as follows:

Fast flashing - Start of the error code
First slow flashing sequence - Error code
Second slow flashing sequence - Error code argument

When you see the Red I/O LED flashing fast, this means it is about to announce the error code and error code argument, one after the other. After flashing fast it will pause and then start the first slow flashing sequence for the error code. Note the number of flashes for the first sequence - this is the "error code". It will pause again and then start the second slow flashing sequence. Note the number of flashes for the second sequence - this is the "error code argument".

Once you know the error code and argument, you can look up what it means... (the M8 module or coupler flashes three red, then four, and then fast flashes which tells me the there is an OPEN IP link)

Example:

error code = 3 flashes - indicates an interruption in the IP Link bus.
error code argument = 2 flashes - indicates the interruption is after extension module number 2

Information on the error codes and arguments can be found on Page 30 in the following PDF Guide under the Indicators and Switches section:-

http://pdb2.turck.de/repo/media/_en/...0404D-xxxx.pdf

That Guide also has good information on the I/O Mapping and Assembly Objects.

------

I also think we should come back to this...

Quote:
Originally Posted by Ken Roach
...The fact that the 1756-DNB is not displaying a fault code for the Turck adapter suggests that the Turck adapter is not in its scanlist. That would also be consistent with the flashing green network LED on the adapter itself...

I had read in one Turck manual that the flashing Green fieldbus LED on the gateway indicates that it is active on the DeviceNet network but is just not exchanging I/O data with the scanner (1756-DNB). However, having read the above manual, it adds an important further possibility here...

Quote:
Green Flashing
Boot Up OK, Device has executed Duplicate MacId Check and
is ON-Line. The SDNL-0404D-xxxx is not allocated by a Master
/ Scanner
, no Data Exchange with a Master / Scanner
Aside from the possibility of no data exchange, there is also the possibility that the gateway has not been allocated by the scanner. The gateway is a basic DeviceNet "Group 2 Only" device - the DeviceNet specification has a "Group 2 Only Connection Set" where a very basic DeviceNet slave, such as the SDNL gateway, must first receive an allocation message from a DeviceNet scanner before it can begin producing and consuming I/O data with that scanner. This led me back to your dnt files...

The other day I had looked at one of your dnt files (AMS100-112.dnt) in RSNetWorx for DeviceNet and the gateway is indeed included in the Scanlist of the 1756-DNB and the I/O data is mapped. There are 8 devices in the Scanlist. However, today I had a quick look at the other dnt file you provided (DeviceNet.dnt) and there is a couple of things of note:-

1. "AMS100-112.dnt" has 8 nodes, whereas "DeviceNet.dnt" has 9 nodes. There is an extra device - 1203-GU6 SCANport Adapter at node 04? (I am not sure, I must look at the earlier screen shots)

2. In the "DeviceNet.dnt" file, under the 1756-DNB scanner, all of the 9 devices are listed as "Available Devices" but none of them have been added to the Scanlist?

Why did you provide 2 dnt files,( good question, do not know why the machine has two files) which are somewhat different, and which dnt file is valid for the actual system? The "AMS100-112.dnt" file sounds like it is from the actual machine but let's be sure here.(how or should I deleted one of the .dnt files?)

I also notice that you've said your gateway is an "SDNL-0404D-1003", whereas the gateway device added to both dnt files is an "SDNL-0404D-0003". This may not matter as I think the only difference is physical - "-1003" has 2 fieldbus ports, "-0003" has only 1 fieldbus port. This shouldn't matter for the EDS file. I have all the EDS files for the Turck piconet gateways registered and there is no selection for "-1003", only "-0003". If it were me and the EDS file is meant for both models then I would have made the selection say "-x003".

Another thing to note for the gateway in RSNetWorx is the fact that the "I/O Data" tab shows "0 bytes" for all message types (Strobed, Polled, etc.). The EDS file also reflects this. I think, from memory, this is because the gateway only builds the process image at startup, as it discovers what extension modules are on the sub-bus. The 1756-DNB scanner has Polled 19 bytes input and 11 bytes output configured for the gateway, so once the gateway builds the process image for the expansion modules the number of I/O bytes should fit this 19/11 byte configuration. We can only decide if this 19/11 bytes setting is correct once we know the exact expansion I/O module list.

------
To determine if the gateway process image is active to the scanner...

Have you got the Turck IO-Assistant 2 software and a service interface cable (I/O-ASSISTANT-KABEL-PICONET No.6824399) for configuring the SDNL gateway module?(NO) This can further help diagnose these issues. You can look at the current status of the configuration parameters, such as "auto configuration" = "active" or "process image" = "active" (I/O data to scanner). You can select things like whether you want "Manual reset" or "Auto reset" for the parameter "behaviour on IP-Link error" - if your IP-Link sub-bus suffers a single error it can auto reset the gateway to try to re-establish the link. Manual reset requires a power cycle of the gateway, and so on.

If you are online the "Image" tab displays the modules in a realistic view with the LED status for each module and the address number above them. This way you can more quickly determine which module(s) may be the root cause, if indeed this is where the issue lies.(Nice)

You can also view the diagnostics tab for any detected issues.

It's been a few years since I worked with these modules, but it's all coming back to me, slowly. I'd love to be in front of this system with you as it would save all this typing but such as things are we'll do our best from afar.

Regards,
George
__________________
"A little nonsense now and then is relished by the wisest men"




Hello George,


thanks for taking the time to provide some interesting points about our system!I have responded to your concise and original questions with RED type.


I will look at:
1. The Turck guide for interpreting the error codes
2. Check on the availability of the Turck troubleshooting device.
3.Include a few screen shots of the wiring for the Turck units.
It is important to know that Turck units 7&8(SNNE) are located approx three feet away on the same system, referred to the "load lock area"


Thank!
Grant
 
Hi Grant,

Thanks for the answers...

When you say "some" - can you be more specific?
Of M1-7 - which are flashing Red?

If M1,2,3,4 are mounted right beside each other then most likely they are IP Linked using bridge couplers which are solid fibre-optic interconnects (no cable), but they could be short cabled either. Once correctly plugged in, these are less likely to give trouble. I would be hoping M1-4 are not flashing Red and the errors start after this point. The following would support this...

From the LED status on the SDNL (error 3, argument 4) -

It looks like the IP Link issue is after module 4, which is after the first group of bridged modules - M1,2,3,4.

From the LED status on the extension modules (Green - OFF, Red - flashing) -

This indicates that those modules are receiving faulty IP Link protocol data i.e. a very bad connection.

So the 2 foot fibre-optic link between module 4 and 5 is most likely the culprit? Is this field assembled can you tell? If so, you could plug out the in-going end to module 5 and check the light image coming through from module 4. You should see a bright and even light emission. Also, and even if the light emission looks good - check that the fibre is not too short or extended beyond the end of the connector tip. Whether that looks good or not, maybe check all the others up to M7 similarly.

Unfortunately your screenshots are still not loading correctly, or at least I cannot view them?

I'm off home now so I'll deal with the dnt file side of things (if needs be?) once we get the IP Link side root caused.

Regards,
George
 

Similar Topics

Hello All, new to this board and especially to AB plc's. I was checking to verify the items on the Device Net by using the node...
Replies
0
Views
1,168
We are trying to poll data coming from a PLC for remote monitoring we have the IP address of the PLC and the default port number and the path is...
Replies
25
Views
408
Anyone know what these statistics mean or if there is a page that explains it more? I couldn't find anything on Rockwell's website or literature...
Replies
0
Views
53
Hello everyone, I am an engineering student who took on a project to design and build a control system for an industrial coffee roaster as my...
Replies
16
Views
4,282
Hai All, We are trying to communicate allen bradley L33-ER processor with Iconics OPC server suite 5.5.Can someone tell me what are steps we need...
Replies
1
Views
931
Back
Top Bottom