magnaparva Posted April 13, 2017 at 03:09 PM Share Posted April 13, 2017 at 03:09 PM I have been having a lot of problems getting the Ethernet Extensions to work reliable when used together. My test configuration consists of 3 master bricks, 2 Ethernet Extensions, 1 Raspberry Pi running brickd and a Windows PC running C#. The Windows PC is running the latest C# bindings and code very much from the Rugged Approach tutorial (full code at end). TEST 1: Connecting to any IPConnection individually (by commenting out the Connect command for the other two) works very reliably and takes consistently about 0.05s. TEST 2: Connecting to the Raspberry Pi and any one Ethernet Extension work equally reliably, and also takes about 0.05s to connect. TEST 3: Connecting to the Raspberry Pi, one of the stacks to my Windows PC running a local brickd and USB connection (changing _HOST to be 127.0.0.1) and any one Master Extension work equally reliably as TEST 2. TEST 4: Connecting to the Raspberry Pi and two Ethernet Extensions works only roughly 65% of the time (though somewhat oddly often takes 9.06s). When it fails it seems to consistently fail with the last stack to be called (i.e. if I change the order that the _TFStack.Connect commands are called it is the last one which will fail). Please find my code below, note that that there is a Authenticate command at the end and _HOST which will have to be adjusted for your setup (and I know the code is not particularly clean, just hacked together for testing purposes). Has anyone else had any problems connecting to multiple Ethernet Extensions? using Tinkerforge; using System.Diagnostics; public class EthernetMasterTesting { private const string _HOST1 = "192.168.1.1"; private const string _HOST2 = "192.168.1.2"; private const string _HOST3 = "192.168.1.3"; private const int _PORT = 4223; private static IPConnection _TFStack1 = null; private static IPConnection _TFStack2 = null; private static IPConnection _TFStack3 = null; static void Main() { long totalTime = 0; int numberOfTests = 5; for (int i = 0; i < numberOfTests; i++) { if (_TFStack1 == null) { _TFStack1 = new IPConnection(); _TFStack1.Connected += ConnectedCB; _TFStack1.Disconnected += DisconnectedCB; _TFStack1.EnumerateCallback += EnumerateCB1; } if (_TFStack2 == null) { _TFStack2 = new IPConnection(); _TFStack2.Connected += ConnectedCB; _TFStack2.Disconnected += DisconnectedCB; _TFStack2.EnumerateCallback += EnumerateCB2; } if (_TFStack3 == null) { _TFStack3 = new IPConnection(); _TFStack3.Connected += ConnectedCB; _TFStack3.Disconnected += DisconnectedCB; _TFStack3.EnumerateCallback += EnumerateCB3; } System.Console.WriteLine("Connect Requested"); Stopwatch sw = new Stopwatch(); sw.Start(); try { _TFStack1.Connect(_HOST1, _PORT); } catch (System.Exception e) { System.Console.WriteLine("Could not connect 1"); System.Console.WriteLine(e.Source + " : " + e.Message); } try { _TFStack2.Connect(_HOST2, _PORT); } catch (System.Exception e) { System.Console.WriteLine("Could not connect 2"); System.Console.WriteLine(e.Source + " : " + e.Message); } try { _TFStack3.Connect(_HOST3, _PORT); } catch (System.Exception e) { System.Console.WriteLine("Could not connect 3"); System.Console.WriteLine(e.Source + " : " + e.Message); } sw.Stop(); System.Console.WriteLine("Took " + sw.ElapsedMilliseconds / 1000.0 + "s to connect stacks."); totalTime += sw.ElapsedMilliseconds; System.Threading.Thread.Sleep(1000); if (_TFStack1.GetConnectionState() == IPConnection.CONNECTION_STATE_CONNECTED) _TFStack1.Disconnect(); if (_TFStack2.GetConnectionState() == IPConnection.CONNECTION_STATE_CONNECTED) _TFStack2.Disconnect(); if (_TFStack3.GetConnectionState() == IPConnection.CONNECTION_STATE_CONNECTED) _TFStack3.Disconnect(); } System.Console.WriteLine("Average Time to connect stacks " + totalTime / (numberOfTests * 1000.0)); System.Console.WriteLine("Press enter to exit"); System.Console.ReadLine(); } private static void EnumerateCB3(IPConnection sender, string uid, string connectedUid, char position, short[] hardwareVersion, short[] firmwareVersion, int deviceIdentifier, short enumerationType) { if (enumerationType == IPConnection.ENUMERATION_TYPE_CONNECTED || enumerationType == IPConnection.ENUMERATION_TYPE_AVAILABLE) { if (deviceIdentifier == BrickMaster.DEVICE_IDENTIFIER) { System.Console.WriteLine("Brick connected " + uid + " on Stack 3"); } } } private static void EnumerateCB2(IPConnection sender, string uid, string connectedUid, char position, short[] hardwareVersion, short[] firmwareVersion, int deviceIdentifier, short enumerationType) { if (enumerationType == IPConnection.ENUMERATION_TYPE_CONNECTED || enumerationType == IPConnection.ENUMERATION_TYPE_AVAILABLE) { if (deviceIdentifier == BrickMaster.DEVICE_IDENTIFIER) { System.Console.WriteLine("Brick connected " + uid + " on Stack 2"); } } } static void EnumerateCB1(IPConnection sender, string UID, string connectedUID, char position, short[] hardwareVersion, short[] firmwareVersion, int deviceIdentifier, short enumerationType) { if (enumerationType == IPConnection.ENUMERATION_TYPE_CONNECTED || enumerationType == IPConnection.ENUMERATION_TYPE_AVAILABLE) { if (deviceIdentifier == BrickMaster.DEVICE_IDENTIFIER) { System.Console.WriteLine("Brick connected " + UID + " on Stack 1"); } } } private static void DisconnectedCB(IPConnection sender, short disconnectReason) { System.Console.WriteLine("Disconnected"); } static void ConnectedCB(IPConnection sender, short connectReason) { try { sender.Authenticate("SUPERSECRETPASSWORD"); sender.Enumerate(); } catch (System.Exception e) { System.Console.WriteLine("After connected failed to authenticate or enumerate"); System.Console.WriteLine(e.Source + " : " + e.Message); } } } Quote Link to comment Share on other sites More sharing options...
borg Posted April 13, 2017 at 04:06 PM Share Posted April 13, 2017 at 04:06 PM Thank you for the test code, i will try it out next Tuesday (don't have the time today and there is a holiday tomorrow and next Monday in Germany). From looking at the code, it should definitely work without any delays! Quote Link to comment Share on other sites More sharing options...
magnaparva Posted April 13, 2017 at 04:45 PM Author Share Posted April 13, 2017 at 04:45 PM This is a fairly critical issue for us as our project requires at least two Ethernet Extensions in it's current configuration, so any suggestions would be greatly appreciated. Have a good Easter break Quote Link to comment Share on other sites More sharing options...
magnaparva Posted April 18, 2017 at 03:36 PM Author Share Posted April 18, 2017 at 03:36 PM I did not realise I had to manually set the MAC address on each Ethernet Extension based on the sticker under the Ethernet socker. Now that the MAC addresses have been set, TEST 4 works perfectly with a 0.05s average time to connect. Quote Link to comment Share on other sites More sharing options...
borg Posted April 18, 2017 at 03:56 PM Share Posted April 18, 2017 at 03:56 PM You shouldn't need to set the MAC addresses. They should come pre-configured with the MAC address that is on the sticker. We even pay for the addresses to get them properly from IEEE. Do all Ethernet Extensions that you own have the same address or only two that you had? I can only imagine that there was some kind error during our initial testing/flashing setup and we accidentally wrote the same address to two extensions. Quote Link to comment Share on other sites More sharing options...
magnaparva Posted April 18, 2017 at 04:00 PM Author Share Posted April 18, 2017 at 04:00 PM I only have two accessible at the moment, and they both had the same address 40:D8:55:02:A0:00 which does not match either of the stickers. Quote Link to comment Share on other sites More sharing options...
borg Posted April 18, 2017 at 04:10 PM Share Posted April 18, 2017 at 04:10 PM Oh, that is not good. That could mean that we had a problem during a whole batch. I will pick some Ethernet Extension from our stock at random and read the MAC address. If i find one with MAC address 40:D8:55:02:A0:00 we will probably have to re-configure all of them . Thank you for the hint and sorry for the problems! Quote Link to comment Share on other sites More sharing options...
GoranP Posted April 18, 2017 at 05:18 PM Share Posted April 18, 2017 at 05:18 PM Hello. That was very interesting news. I had for a while ago almost the same problem. I had two Master Brick's, each with a Ethernet module. Each of them had a separate IP-address. No problems to connect to stack 1 or two, it was running good. But starting both the stack's, with two separate Python programs, impossible. My first idea then was, "I have done some configuration error". Anyhow, there was no time for faultfinding, so i made another solution to solve my problem then. Now I understand why it didn't work ... After I was reading your last reply's, I took out the 2 Ethernet modules I had in my "spare" boxes. When testing both of them with Brick Viewer, both of them where showing the same MAC address as you mentioned, (40:D8:55:02:A0:00), not as printed on the labels. One of these modules was ordered in middle Jan -17, the other one in Febr. -17 // Göran P Quote Link to comment Share on other sites More sharing options...
borg Posted April 18, 2017 at 08:29 PM Share Posted April 18, 2017 at 08:29 PM Not sure what happend there . Our OUI/company id is 40:D8:55 with one assigned address block of 02:A0:00 to 02:AF:FF. So obviously something went wrong during our automated configuration process if at least 4 Ethernet Extension have the starting address assigned. I have to assume that a whole batch (250pcs) wasn't given a proper MAC address. As far as i can tell at the moment, all but 29 Ethernet Extensions of that batch have already been sold... Edit: I checked all of the Ethernet Extensions and all of the ones we have in stock have the correct MAC address. Quote Link to comment Share on other sites More sharing options...
magnaparva Posted April 19, 2017 at 09:14 AM Author Share Posted April 19, 2017 at 09:14 AM @GoranP, I am glad to hear I was not the only one with this problem, I immediately assumed it was something I was doing wrong with my code... @borg I don't know when you generated the images on your website, but the automated configuration process might have been having issues longer than you think. The MAC address for the screenshot on https://www.tinkerforge.com/en/doc/Hardware/Master_Extensions/Ethernet_Extension.html#ethernet-configuration has the same 02:A0:00 ending. Quote Link to comment Share on other sites More sharing options...
LulaNord Posted April 25, 2017 at 04:53 PM Share Posted April 25, 2017 at 04:53 PM Hi...i am a new user here. In my case i had two Master Brick's, each with a Ethernet module. Each of them had a separate IP-address. No problems to connect to stack 1 or two, it was running good. But starting both the stack's, with two separate Python programs, impossible. turnkey pcb Quote Link to comment Share on other sites More sharing options...
magnaparva Posted April 25, 2017 at 04:59 PM Author Share Posted April 25, 2017 at 04:59 PM @LulaNord that would also make sense if the MAC addresses are the same and they are connected to the same network switch. The routing table in the network switch would not know how to handle the traffic. https://serverfault.com/a/462190 Quote Link to comment Share on other sites More sharing options...
borg Posted April 26, 2017 at 09:33 AM Share Posted April 26, 2017 at 09:33 AM @LulaNord: Do your Ethernet Extensions have the same MAC address too (02:A0:00 in the end)? I am still confused about this problem. I found that if you reset the EEPROM the configuration of the Ethernet Extension defaults to the 02:A0:00 MAC address. You can reset the EEPROM with the Brick Viewer in the Master Brick Tab through the "Configure Extension Type" popup. If you set type to Ethernet it will write a default Ethernet configuration to the EEPROM which has this MAC address. This is meant for cases where a configuration has become completely broken or if the EEPROM for some reason looses a configuration and the Extension can not be discovered anymore (the type of extension is stored in the EEPROM too). We need to document this feature better, it is probably completely unclear for most users what this "Configure Extension Type" feature does. Did any of you reset the EEPROM with this by any chance? Quote Link to comment Share on other sites More sharing options...
magnaparva Posted April 26, 2017 at 09:51 AM Author Share Posted April 26, 2017 at 09:51 AM @borg not me, I did not even realise that popup dialog existed. Quote Link to comment Share on other sites More sharing options...
Loetkolben Posted May 3, 2017 at 02:48 AM Share Posted May 3, 2017 at 02:48 AM Hello borg, very interesting Story to read. Please note: User "LulaNord" could be a bot. His only entry is just a copy of a block of sentences prior written. Please check to avoid problems. Der Loetkolben Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.