How do I connect a Ruida Controller with Ethernet? (cont)

[evanevery (Ed)]

Continuing the info from the FAQ How do I connect a Ruida controller with Ethernet?:

The reason the above posts suggests “pick a different set of ‘hundreds’ from where your PC is” is because the Ruida TCP/IP Stack is broken and NOT PROPERLY IMPLEMENTED.

Without getting too technical: as long as you choose a Ruida IP address which shares the same first three “parts” (octets) of your PC’s IP Address then you should be OK. It doesn’t really matter what you choose for the last “part” is as long as the first three match. (…and of course the address needs to be unique)

For those who would like a technical explanation:

Ruida never asks for a Subnet Mask during configuration. This should be a Red Flag for anyone who understands how IP addressing works. Ruida ALWAYS assumes a Subnet Mask of “255.255.255.0” regardless of whether it is appropriate for use on YOUR network or NOT. This is simply a very sloppy and incorrect assumption but it should also be easy to fix (if Ruida truly cares). All they need to do is ask for the proper Subnet Mask instead of just using 255.255.255.0 in all cases. They are assuming that every always uses a Class-C network which is simply NOT the case!

For example. My network is a Class-B network (172.20.0.0) and fully compliant with the RFC1918 spec for address ranges reserved for private use. (You might be familiar with 192.268.0.0 or 10.0.0.0 and if you are wondering where these numbers come from and why they are so popular - RFC 1918 will tell you) Anyway, here are my network details including my PC address and the address I WANTED to use for my Ruida Controller:

Network: 172.20.0.0
Mask: 255.255.0.0
Gateway: 172.20.1.1
Lightburn PC: 172.20.100.4 (All my workstations are on 172.20.100.?)
Rudia: 172.20.8.1 (All my CNC Equipment is on (172.20.8.?)

Normally this should not be a problem. It certainly isn’t for all the other hundreds of device on my network. However, I was forced to set the TCP address of my Ruida controller to:

Ruida: 172.20.100.254

…and then my Lightburn PC could communicate with it. However, no other devices (other than those with 172.20.100.?) addresses can communicate with it. All Ruida needs to do is “Ask” what the existing subnet mask is for the network LIKE EVERY OTHER TCP DEVICE DOES. In fact, the Ruida controller can not even communicate with the Gateway it specifically requested (at 172.20.1.1) because it doesn’t share the same first three octets!

So, you might say, “so just use the “forced” address”. However, if you have a larger network, and you actually ORGANIZE and MANAGE your devices (for routing, vlan, or other purposes) then you “DO” care. Again, by using an inappropriate subnet mask, a good portion of the devices on my network can not communicate with the Ruida. Machine shops with larger networks are definitely going to see this issue.

I did send an email to both Ruida and OMTech so we’ll see where it goes. But if you wonder why you are being forced to choose an address for your controller, which may not be appropriate for your network, this is the reason.

The good news it’s a simple fix if Ruida cares to implement it…

[Dave01 (Dave V)]

FYI, Ruida is not DHCP, it is a static address programmed in the controller. I believe default is 192.168.1.100. To change it to anything else, you have to go into the controller and manually change it. If the rest of your system is DHCP, I would put it at an address outside of the DHCP zone to avoid any conflicts.

[evanevery (Ed)]

This has NOTHING to do with DHCP.

This has EVERYTHING to do with the manual configuration at the Ruida controller.

(There are no conflicts with DHCP address assignments on my network.)

The problem is, quite simply, the Ruida Controller ALWAYS uses a hard coded subnet mask of “255.255.255.0” and that is ONLY appropriate for the very smallest Class-C networks. That subnet mask will not work properly on any network other than the very smallest.

The PROPER solution, quite simply, is for Ruida to ask for the correct subnet mask when it is being configured. They do NOT do this. They should. Its a very simple fix but Ruida would have to be the one to implement it.

[Dave01 (Dave V)]

Ah, I didn’t catch the subnet issue. I will pass that on to their IT department. I haven’t checked my controller, It’s been a long time since I put it on the network, and can’t say either way on the subnet. I’ll drop a line if I hear something.

[patricr (Patrick Rose)]

Have you tried (https://www.virtualhere.com/) software on a RPi?

You can use your normal network number scheme and just share the Ruida from USB. You can use it free for one device.

[Dave01 (Dave V)]

Well, bad news good news. I heard back from my guy, and in bad English, it was basically ‘we didn’t think about that.’ Good news is that it will be passed down to the firmware people to look at integrating it in. Bad news is that it will not be a quick fix, good news is that it will be fixed.

[evanevery (Ed)]

I’ll take the good news!

Actually, from a software perspective, it is a very easy fix. All they need to do is ASK for the proper subnet mask on the console during TCP/IP config (instead of always assuming it will be “255.255.255.0”) and then implement whatever is provided by the user. I am quite sure they are using some established TCP/IP library for their microcontroller so all they should have to do is supply the CORRECT value instead of just using the same one over and over.

I’m expecting the “Not a quick fix” aspect is with respect to actually getting something moving and not the actual code change itself…

At least it sounds like they now understand where the shortfall is and that they are willing to make the necessary changes…

[Dave01 (Dave V)]

Part of the ‘not a quick fix’ is they have a lot of resources working on the new software. It’s a total remake of RDWorks. The beta was very clunky, but showed a lot of promise for the direction they are taking it.