You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

PLC training tools sale

Reply
 
Thread Tools Display Modes
Old November 8th, 2018, 04:30 PM   #1
plcbeginer1
Lifetime Supporting Member
United States

plcbeginer1 is offline
 
Join Date: Oct 2018
Location: Springtown
Posts: 16
Allen Bradly Logic 5561 PLC

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
  Reply With Quote
Old November 8th, 2018, 04:32 PM   #2
Ron Beaufort
Lifetime Supporting Member
United States

Ron Beaufort is offline
 
Ron Beaufort's Avatar
 
Join Date: Jul 2002
Location: Charleston, SC
Posts: 5,443
you have to ZIP the files before you can attach them to the forum post ... that's just a rule that the forum has ...
__________________

2-B ?
Best regards, ----+----] [----+------------( )----
Ron | |
PLC Training Boot Camp | 2-B |
+----]/[----+

I once was lost, but now am found, was blind, but now I see.

  Reply With Quote
Old November 8th, 2018, 07:45 PM   #3
Ken Roach
Lifetime Supporting Member + Moderator
United States

Ken Roach is offline
 
Ken Roach's Avatar
 
Join Date: Apr 2002
Location: Seattle, WA
Posts: 14,259
Quote:
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 ?
  Reply With Quote
Old November 9th, 2018, 05:23 AM   #4
plcbeginer1
Lifetime Supporting Member
United States

plcbeginer1 is offline
 
Join Date: Oct 2018
Location: Springtown
Posts: 16
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
  Reply With Quote
Old November 9th, 2018, 05:55 AM   #5
JohnCalderwood
Member
Scotland

JohnCalderwood is offline
 
Join Date: Feb 2014
Location: Stirling
Posts: 617
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.
  Reply With Quote
Old November 9th, 2018, 06:34 AM   #6
plcbeginer1
Lifetime Supporting Member
United States

plcbeginer1 is offline
 
Join Date: Oct 2018
Location: Springtown
Posts: 16
Ok, will try when I get in front of it.


Thanks for the reply!!
  Reply With Quote
Old November 9th, 2018, 10:11 AM   #7
plcbeginer1
Lifetime Supporting Member
United States

plcbeginer1 is offline
 
Join Date: Oct 2018
Location: Springtown
Posts: 16
*DNT file

dnt_zipped.zipHere are the files in zipped format. I will send over the screen shots shortly.




Thanks!
Grant
  Reply With Quote
Old November 9th, 2018, 10:45 AM   #8
plcbeginer1
Lifetime Supporting Member
United States

plcbeginer1 is offline
 
Join Date: Oct 2018
Location: Springtown
Posts: 16
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
  Reply With Quote
Old November 9th, 2018, 12:08 PM   #9
Ken Roach
Lifetime Supporting Member + Moderator
United States

Ken Roach is offline
 
Ken Roach's Avatar
 
Join Date: Apr 2002
Location: Seattle, WA
Posts: 14,259
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.
  Reply With Quote
Old November 9th, 2018, 04:46 PM   #10
plcbeginer1
Lifetime Supporting Member
United States

plcbeginer1 is offline
 
Join Date: Oct 2018
Location: Springtown
Posts: 16
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
  Reply With Quote
Old November 10th, 2018, 07:06 AM   #11
Geospark
Lifetime Supporting Member
Ireland

Geospark is online now
 
Geospark's Avatar
 
Join Date: Feb 2012
Location: Kildare
Posts: 2,414
Quote:
Originally Posted by plcbeginer1
...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.

Quote:
Originally Posted by plcbeginer1
...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
__________________
"A little nonsense now and then is relished by the wisest men".
  Reply With Quote
Old November 10th, 2018, 08:32 AM   #12
plcbeginer1
Lifetime Supporting Member
United States

plcbeginer1 is offline
 
Join Date: Oct 2018
Location: Springtown
Posts: 16
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
  Reply With Quote
Old November 13th, 2018, 09:53 AM   #13
Geospark
Lifetime Supporting Member
Ireland

Geospark is online now
 
Geospark's Avatar
 
Join Date: Feb 2012
Location: Kildare
Posts: 2,414
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?
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...

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?

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/...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?

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
__________________
"A little nonsense now and then is relished by the wisest men".
  Reply With Quote
Old November 13th, 2018, 11:11 AM   #14
plcbeginer1
Lifetime Supporting Member
United States

plcbeginer1 is offline
 
Join Date: Oct 2018
Location: Springtown
Posts: 16
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
Attached Images
File Type: jpg 072.jpg (157 Bytes, 7 views)
File Type: jpg 073.jpg (157 Bytes, 5 views)
File Type: jpg 074.jpg (157 Bytes, 4 views)
  Reply With Quote
Old November 13th, 2018, 11:53 AM   #15
Geospark
Lifetime Supporting Member
Ireland

Geospark is online now
 
Geospark's Avatar
 
Join Date: Feb 2012
Location: Kildare
Posts: 2,414
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
__________________
"A little nonsense now and then is relished by the wisest men".
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
Idea: Put all of the logic for a PLC program in a function block. theColonel26 LIVE PLC Questions And Answers 24 November 10th, 2016 12:40 PM
HMI and PLC Ladder Logic Report Hendu74 LIVE PLC Questions And Answers 1 January 9th, 2013 07:52 PM
Downloading Allen Bradley PLC Data to a Access Database bigvicfella LIVE PLC Questions And Answers 5 January 25th, 2007 01:31 PM
Please recommend the right PLC among Allen Bradley PLCs vislab LIVE PLC Questions And Answers 5 December 20th, 2006 12:22 AM
PLC logic and Scada Control CodeLearner LIVE PLC Questions And Answers 17 April 13th, 2005 05:49 AM


All times are GMT -5. The time now is 10:43 AM.


.