nic card with the RT os on a target PC not getting on the network

[stefankns]

Just to give you more input on the 82579LM issue:

I just tried to activate the 82579LM again. It shows up as eth0, but disabled. Still ping is ok, because the external 82574L is still the primary adapter.

When changing the primary adapater to eth0 (82579LM) no ping answer anymore (fully installed system). I think I do not need to mention that I move the network cable to the right NIC board. In the driver summary on the target screen, the link is shown as "U" (Up?) and sometimes "T" (transmit?) is blinking, but not on the time basis of the ping. In the network properties of the windows host PC the received packets counter is no increasing anymore. But Link is shown as up.

I will revert the setup now and test the EtherCAT master tomorrow.

[Texas_Diaz]

With what we know now, your guess sounds quite logical - there's probably something else at play here, probably some interaction within the OS filesystem based on the disk controller you're using that you likely wouldn't be able to debug yourself.  Do you have an IDE Compatibility Mode option in your BIOS to set a compatibility mode for your disk, and does it have a "RAID" option?  We don't support RAIDs in RT, but some BIOS's with the RAID compatibility option turns on/off functionality on a disk controller that we've found we need to handle "Specially" - it would be interesting to see if Reliance works in RAID mode (if your BIOS supports that kind of thing).

Oh, so your 82579LM still doesn't work - the "T" is probably being displayed when the DHCP packet is being sent out, and if the "R" for "receive" doesn't show up then that means the receive engine likely isn't working.  That would explain things.  Yeah, I think the only way to debug this would be instrumenting a version of the driver where we can see what's going on.

-Danny

[stefankns]

Thanks a lot for the help so far! I will let you know the results of my testing tomorrow, when I am back at the test stand.

If you see a way of debugging the 82579LM issue that would be great. As I said, I can test some debugging enabled driver if that helps.

Thanks

Stefan

[stefankns]

No good news. I did several tests today and I can only state, that the EtherCAT master is not stable in this setup. Every second start of the target or so I start up already in disconnected state for all slaves. I tested it with a "clean" project with just an EtherCAT master and all slaves added. Scan engine setting is to go to active mode at startup. With the old RT target there was no problem with startup. The EtherCAT master is actually on the external NIC (PCIe card) with a 82574L chipset (only possible setup as long as the internal 82579LM is not working)

I have already changed the controller settings from "AHCI" to"IDE" and reinstalled the system with FAT and 2012SP1 one more time.

So there still seems to be a problem with the network traffic/stability. Do you think it might help so switch off all internal NICs and try a dual port LAN card on the free PCIe slot? Is it recommended to have the TCP/IP traffic and the EtherCAT on a different driver or card or does it not matter?

/Stefan

[Texas_Diaz]

Hey Stefan,

Sorry about the lag, I've been ill the past day or so.  I will admit that I've written an EtherCAT network driver but I don't know enough about the stack to know what you mean by "not stable" - do you mean there's possibly too much jitter in the system for EtherCAT to make its timings?

Here's a couple things to try:

1. USB SMI Jitter is a massive drag on the system, you're looking at periodic jitter on the order of a second (where it should be on the order of ten microseconds).  Disable USB within the BIOS of the system to remove this (sometimes it's only necessary to disable "Legacy USB").
2. The ethernet device, depending on the hardware architecture surrounding how the PCI "chip" is placed on the PCI bus, can also generate large amounts of Jitter when issuing and servicing interrupts.  If you're using LV RT 2012SP1 you want to change all network devices in the system (except the EtherCAT Master NIC) to "Polling Mode" instead of "Interrupt Mode" - Polling mode does not use interrupts, and thus is more deterministic; however, Polling mode is going to be slower (you're going to get a maximum throughput rate of about 30MB/s).  

It shouldn't matter if you're using an internal versus an external NIC for EtherCAT, unless there are additional bridges between the NIC and the PCI bus that might be causing jitter or bus collisions.  I would try these two things before trying to use a dual-NIC card.

-Danny

[stefankns]

Hi Danny,

Unfortunately both things are already in our setup. Legacy USB is disabled in the BIOS as well as the USBEnable=FALSE flag in the ni-rt.ini is set. The communication network adapter is set to polling mode. Jitter is not actually the problem any more. I think we tweaked that very good already (important, because we have an application with 125µs cycletime). Just to give you more background we already have a working software on a desktop target but that target is getting to slow while development continues. This is why we try to move to the i7-3770 based, new target.

With instability I mean, that we get disconnects of the EtherCAT slaves. Because I can not really debug, what fault triggers the disconnect state in the Master Online State in the EtherCAT master dialog, its hard to say what is going on.

Hence I kind of gave up on the internal NICs right now and moved on to an external PCIe card. I tested an Intel PRO/1000 Dual Port Server Adapter (EXPI9402PT -> 82571GB chipset) yesterday and with this card, the system runs flawless up to now.

I think that supports your suggestion about an issue with the bridge between the PCI bus and the NIC. On the other hand, the setup with the internal 82579LM deactivated, TCP/IP via internal 82574L and EtherCAT via an external (PCIe) 82574L was not working. So in a way, the internal NIC must "disturb" the other LAN connections. I did a fast check with XPCtarget from Mathworks (another RT plattform we have in use) and here the ping is no problem, so I think I can rule out a general hardware problem with the 82579LM.

I am at a point where I have to realize, that I can not debug it more on my own.

Nevertheless I try to get a BIOS update for the motherboard. The motherboard is still quite new, so maybe that helps.

I still would appreciate if you could send me a debugging driver (instrumented as you called it) for the 82579LM. The actual test stand is a prototype and I hope to be able to skip the external NIC in the serial design. But for that, the internal NICs must do their job first.

Thanks so far

Stefan

[Texas_Diaz]

Yeah, I hope I didn't give you the wrong idea - I don't think there's anything wrong with the 82579LM device on your system, but the PharLap ETS driver we supply for the 82579LM is very specific to the hardware Intel provides us and that we use on our National Instruments PXIe-8135.  The good news is that the provided 82579LM implementation has worked on all of the devices we've tested thus far, but the bad news is that you've got one that doesn't work; and that's not unexpected.  The 82579LM is just one component in the networking mechanism for a single network port - there are a half-dozen components that work together and the vendor can choose to swap out parts in the design to save costs.  As vendors and suppliers come up with new components for the chain, the open source and Windows drivers are updated quickly to support these new devices - but the PharLap ETS driver is not.  There are also a TON of parameters in the FLASH used for the 82579LM that control how the device behaves, and we're kinda relying on those parameters being compatible to what our default FLASH image has (we don't modify or override those parameters, whereas maybe we should be).

I will have more time starting Monday to provide a driver with instrumentation, but I'll be totally honest and say if we don't find the issue very quickly it's likely we won't be able to resolve this.  And I am not completely comfortable with the odd behavior you're finding with the 82574L, so I only hope our effort won't be totally in vain.  

-Danny