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