Question:two ormerod-prints can't be controlled by computer at the same time

I have two ormerod-prints.
I configure the IP address of one print 192.168.1.14, the other 192.168.1.15. When I use any of them to connect with my computer alone ,I can control it successfully. But when I want to control them simultaneously by the Web-Client from my computer. I find that I can't control them at the same time.When I use the 192.168.1.14 one, the Web page of 192.168.1.15 will get no access. How can I solve the problem.Thanks for you answers.

There should not be any interference unless the web interface is using cookies (which I doubt). Are you opening 2 different web browser windows, or having them on tabs from the same browser session? Whatever the case, try the opposite and see if that works. Also, what is different between the connections when you are controlling just 1 to 2? Is it just a question of having the inactive Ormerod powered off, or are you changing the network connections?

Edit: I have just looked at my Ormerod's MAC address and have had a horrible suspicion ...
Open a command prompt (DOS window) with both printers connected to the LAN and try to ping both IP addresses of the Ormerods. If you cannot ping both addresses, enter "arp -a" in the command prompt window and post the contents of the line that starts with the IP address of the Ormerod you are able to ping, and the other also if it is present in the list.

Dave
(#106)

Edited 2 time(s). Last edit at 05/05/2014 09:33AM by dmould.

Dave, I think your suspicions are correct. When I was delving around the firmware a couple of weeks ago, I found a MAC address hard-coded in the firmware:

/** MAC address definition.  The MAC address must be unique on the network. */
#define ETHERNET_CONF_ETHADDR0                        0xBE
#define ETHERNET_CONF_ETHADDR1                        0xEF
#define ETHERNET_CONF_ETHADDR2                        0xDE
#define ETHERNET_CONF_ETHADDR3                        0xAD
#define ETHERNET_CONF_ETHADDR4                        0xFE
#define ETHERNET_CONF_ETHADDR5                        0xED

To control both of them, they need to have different MAC addresses. So if there isn't a hardware MAC address on the board, then I guess we need to make the MAC address configurable in config.g.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
Dave, I think your suspicions are correct. When I was delving around the firmware a couple of weeks ago, I found a MAC address hard-coded in the firmware:

/** MAC address definition.  The MAC address must be unique on the network. */
#define ETHERNET_CONF_ETHADDR0                        0xBE
#define ETHERNET_CONF_ETHADDR1                        0xEF
#define ETHERNET_CONF_ETHADDR2                        0xDE
#define ETHERNET_CONF_ETHADDR3                        0xAD
#define ETHERNET_CONF_ETHADDR4                        0xFE
#define ETHERNET_CONF_ETHADDR5                        0xED

To control both of them, they need to have different MAC addresses. So if there isn't a hardware MAC address on the board, then I guess we need to make the MAC address configurable in config.g.

Yes, I just PM'd you on that point. It is very naughty to sell commercial kit without a proper factory-allocated MAC. The first 3 bytes is a vendor ID, allocated by a central standards body, and companies in small-volume production usually buy a sub-block of addresses from a company that "owns" the main block. If there is no proper factory-set MAC address, the unit should be sold with no MAC allocated, and the LAN should be disabled until the customer sets up a "locally administered" MAC address. Bit 0 of the first byte must be 0 for Ethernet (it's the multicast flag), so better check for that in firmware otherwise it can create mayhem on the LAN! Bit order is reversed for TokenRing.

Dave
(#106)

Quote
dc42
To control both of them, they need to have different MAC addresses. So if there isn't a hardware MAC address on the board, then I guess we need to make the MAC address configurable in config.g.

Maybe you could just create a hash with the IP as a part.

Quote
michaelljunggren

Quote
dc42
To control both of them, they need to have different MAC addresses. So if there isn't a hardware MAC address on the board, then I guess we need to make the MAC address configurable in config.g.

Maybe you could just create a hash with the IP as a part.

Good idea! I guess just using the last octet of the IP address as the last byte of the MAC address should be sufficient in most cases.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
michaelljunggren
Maybe you could just create a hash with the IP as a part.

Good idea - even simpler, it would be sufficient to have the first two bytes fixed and the next 4 a copy of the IP address. That would probably be a very quick firmware change. It is only necessary for the MAC to be unique on the local LAN (i.e. the same IP subnet), and as all IP addresses on a subnet must be different, and it is most unlikely to cause a clash with other MAC addresses on the LAN, that would do the trick nicely even if it is completely non-standard (MAC addresses are supposed to be fixed to individual devices like serial numbers, and not be user changeable). The Ethernet driver needs to be reinitialised after changing the MAC - but on the Duet firmware I think it must be reinitialised following an IP address change, so that will be automatic.

That way there's no need for any new G codes.

Dave
(#106)

OK, I'll implement that or something very similar when I get enough feedback on 0.59beta2 to turn it into a proper release.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I really appreciate your solution, may I ask which file is the configuration file that configures the MAC address?

@sevenljy: It's hard coded in the firmware, so it will need a fix to the firmware to work - there isn't a config file you can change. I suggest as a workaround you run only one machine over ethernet, and run the other on USB (you can actually run both on USB with no problem).

I have also raised an issue with this on the official firmware page issue tracker: [github.com]

Ian
RepRapPro tech support

Quote
droftarts
@sevenljy: It's hard coded in the firmware, so it will need a fix to the firmware to work - there isn't a config file you can change. I suggest as a workaround you run only one machine over ethernet, and run the other on USB (you can actually run both on USB with no problem).

I have also raised an issue with this on the official firmware page issue tracker: [github.com]

Ian
RepRapPro tech support

You could also run 2 machines over Ethernet so long as they are not on the same subnet - i.e. they are separated by an IP router (not just a hub or switch) - e.g. you could try using a WiFi to Ethernet dongle in one Ormerod and connect the other via copper, which will work for some (but not all) typical home broadband routers. With a bit of juggling (frigging the ARP tables in the PCs) you could also run one printer from one PC and the other from another PC on the same subnet.

USB does not have the same issue because it does not have the equivalent of a MAC address - the closest equivalent is the VID and PID (Vendor ID and Product ID), which are fixed for all devices of the same type. (These are the numbers that determine which driver the OS uses - except for generic devices such as keyboards, memory sticks etc).

Dave
(#106)

Quote
dmould
you could try using a WiFi to Ethernet dongle in one Ormerod and connect the other via copper, which will work for some (but not all) typical home broadband routers.

All typical home broadband routers I've seen put the wireless and wired networks on the same subnet (same IP range and same layer 2 domain), so it won't make any difference. Some more advanced ones (with firewall-ish features) can have networks in different security zones and route between them (provided you set up access rules that allow it), and there it could work, but that's not at all a common feature on home routers.

There are ways to set this up though (like a second home router having it's WAN port on the existing network, providing a new network for the second Ormerod, and NAT:ing traffic there), but it all gets rather messy.

Quote
jstck

Quote
dmould
you could try using a WiFi to Ethernet dongle in one Ormerod and connect the other via copper, which will work for some (but not all) typical home broadband routers.

All typical home broadband routers I've seen put the wireless and wired networks on the same subnet (same IP range and same layer 2 domain), so it won't make any difference

Ah - but look at your ARP table after connecting from a wired PC to 2 or more WiFi devices off the router. If your router is acting as a simple bridge between wired and wireless sections, then the MAC addresses of the WiFi devices will appear in your ARP table and the method I suggest will not work. But that is not efficient, because it means that all broadcast and multicast traffic (at least) is repeated on both networks which can clog up the limited WiFi bandwidth. More sophisticated routers create 2 ad-hoc subnets on the fly as devices connect (which do not have to have contiguous addresses), and will route between them. In that case you will find that all WiFi devices contacted from a wired PC have the same MAC address in your ARP table - being the MAC of the router - and vice-versa for devices on the WiFi side. Your PC does not know that the packets are being routed.

LAN devices usually have an entry for subnet and gateway and use those to determine where to direct each packet - but in fact it could just as well be done by the router to make the IP stack simpler in the end device. The end device would then treat every IP address as if it were on the local network and the router would respond to ARPs for IP addresses that it is routing, and the end device would not know the difference - and that is essentially what I have seen some WiFi routers do. It is a lot simpler than using ICMP redirect packets or other mechanisms when there is more than one gateway on a local network.

Dave
(#106)

Quote
dmould
Ah - but look at your ARP table after connecting from a wired PC to 2 or more WiFi devices off the router. If your router is acting as a simple bridge between wired and wireless sections, then the MAC addresses of the WiFi devices will appear in your ARP table and the method I suggest will not work.

And that is the case with >99.9% of common home broadband-wifi-router devices, which is exactly my point. Also, saying that it is "not efficient" is not necessarily true (it usually isn't). The wireless network is a shared medium no matter which way you slice it (even if a devices IP stack doesn't "see" a packet, it still occupies "airspace"), and in practice (at least for just about all home users) the amount of broadcast traffic is very low.
Devices that separate wired from wireless (or wireless users/networks from each other) almost always do so for security reasons. When that is done, the most common solution is to just have one single wifi network and one single IP range, but block all client-to-client communication on layer 2 (encryption forcing everything to go via some central point, and that can block unwanted traffic and inject ARP responses so it always gets everything). And there too, multiple devices sharing a MAC address just would not work.

Quote
dmould
LAN devices usually have an entry for subnet and gateway and use those to determine where to direct each packet - but in fact it could just as well be done by the router to make the IP stack simpler in the end device. The end device would then treat every IP address as if it were on the local network and the router would respond to ARPs for IP addresses that it is routing, and the end device would not know the difference - and that is essentially what I have seen some WiFi routers do. It is a lot simpler than using ICMP redirect packets or other mechanisms when there is more than one gateway on a local network.

Well, for starters, if you have more than one gateway on an access network (one with client devices such as laptops, smartphones and 3d printers) you're almost always doing something really weird (I have, and it was). There are some valid reasons for building such a network, but just about none for end-user access networks. Doing small "2-device networks" (client device and upstream gateway) does have some usecases, and some WiFi devices do that, but I have never seen anything other than "enterprise-grade" hardware (such as the stuff deployed in large conference centers, hotels or airports) do that or even have the capability.


Anyway, we're derailing. The only actual solution to the actual problem at hand is to make sure the Duet firmware gets its MAC address in a slightly less braindead fashion than statically encoded in firmware. While I would ideally want to have it as a configurable option in g-code, having it use some static prefix (from some unregulated part of the address space or some defunct vendor code or something) + a few of the lest-significant bits (16-24, or maybe all 32) of the IP address would work in just about every practical scenario (unless someone is running a printerfarm with tens of thousands of Ormerods on a single subnet).

I guess the Duet board just doesn't have a properly assigned MAC address? I've fiddled with some other Arduino ethernet interfaces, and a couple of them came with a sticker with the MAC address you had been granted by the network gods, but you then had to configure it yourself for the device (and the rest just didn't have one). Does the Duet have some other form of serial number or something that can be machine-read and used?

Quote
jstck
I guess the Duet board just doesn't have a properly assigned MAC address? I've fiddled with some other Arduino ethernet interfaces, and a couple of them came with a sticker with the MAC address you had been granted by the network gods, but you then had to configure it yourself for the device (and the rest just didn't have one). Does the Duet have some other form of serial number or something that can be machine-read and used?

Any company manufacturing a commercially sold device containing a LAN interface should have a procedure whereby each device has a unique MAC put into it before it reaches the end user, and that should be in a place that is non-volatile as far as anything the normal end-user will be doing (e.g. only programmable via JTAG or an undocumented command etc.), and must survive firmware updates. The company first needs to purchase a block of addresses from the "network gods" (IEEE) or another company selling sub-blocks, and then it's up to the manufacturer to ensure that numbers within that block are each only assigned to one device. You can enter the first 3 bytes of a MAC to find the company that owns it here [standards.ieee.org] If you enter "arp -a" in a command prompt you can have fun looking up the manufacturer of all the devices listed in the MAC addresses.

Like IP addresses however, you can use locally administered MAC addresses (which probably by accident applies to the fixed address used in the Ormerod). Bit 1 of the first byte indicates a locally administered address if set, and so the firmware modification should ensure that any MAC address produced has that bit set - and as said previously, bit 0 must be reset. I suggest the existing 0xBE, 0xEF followed by the IP address would be as good a method of deriving a MAC address as any other, and pretty much guaranteed to be unique on any subnet.

Dave
(#106)

Quote
dmould
I suggest the existing 0xBE, 0xEF followed by the IP address would be as good a method of deriving a MAC address as any other, and pretty much guaranteed to be unique on any subnet.

Alternatively, use FE:ED as a vegetarian option (having the second-most-significant nibble be 0E or 0A just so happens to work).

Quote
jstck
Well, for starters, if you have more than one gateway on an access network (one with client devices such as laptops, smartphones and 3d printers) you're almost always doing something really weird (I have, and it was).

You may be surprised. Products have become quite sophisticated these days, and "invisible" local subnets are no longer that uncommon, having been created in an ad-hoc fashion and routed in the manner I previously described or via ICMP redirect packets. So it is not necessarily the user that is "doing something weird" but some network device or application you installed. I know of at least one home router that assigns different ranges within its local subnet for WiFi and cabled subnets and routes rather than bridges between the two sub-subnets. The plug & play invisibility of networking these days can be a PITA, because it is not always obvious how your data is being routed even inside your own house. When I type "ipconfig" in a recently installed Win7 PC at home, it shows that I have 3 network interfaces - the Ethernet card I know about and two "Tunnelling Interfaces" that I have never knowingly installed. As soon as I plug my mobile phone into a USB port, yet another interface is created by the phone's driver software that I installed on the PC, and I can access the Internet via my phone with the Ethernet cable unplugged - effectively using the phone as a WiFi dongle. But - if the WiFi drops out I risk having the phone switch to an expensive cellular data connection without me knowing (and it can create its own WiFi hotspot for other people to connect to if configured to do so). Shortly after I plugged a new TV set into the mains with no other connections to it, it brought up a couple of popups that I clicked "OK" to without fully reading (yes, foolish I know, but I was sorting out cabling and didn't pay much heed). To my amazement it started updating its firmware from the Internet even though my home broadband was not active at the time due to me re-routing my phone cable. Heavens knows where it found a connection. I installed some BluRay authoring software onto another PC a few months ago. I had only read up on the capabilities of the software that I was interested in, and just skimmed though its other features I did not need. Playing with my phone one evening, I discovered that I could watch a full-length movie on it should I ever want to - but the amazing thing was that it was getting the movie from my PC's hard drive - the software I had installed had made the movie available for streaming over my WiFi and advertised its presence to my phone.

Dave
(#106)

sevenljy, I have implemented IP-dependent MAC address in version 0.59-dc42 of my firmware variant, so that you can control multiple Ormerods on the same network. You can download it here [github.com] (follow the link, then use the Raw button).

The recommended web interface code to use with it is 074, available here [github.com].

Edited 1 time(s). Last edit at 05/09/2014 02:54AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I really appreciate your help.