Chinese CNC 3020 / 6040 - USB variant

I have worked in engineering for thirty years and worked on everything from space to subsea, if i was a programmer i probably would have. Could you write it or are you simply giving a helpful instruction via hot through your pants.

One good point was made by MrJTJinx.

Why is Ethernet acceptable to interface with a downstream motion processor like the 7i76E, but USB not? Obviously the twisted pair cabling is far harder against EMI, but what is it with Ethernet that makes it better and acceptable solution for RT applications?

Mike did make the essential point about LinuxCNC. It is open source. A USB driver will be written for it when someone really wants one, and will be included in the main release if an majority of the core developers agree that it should be included. It seems like nearly no one who actually uses LinuxCNC sees any value in persuing such a path though.
Mark

There are a couple of issues here but the main one I see is lack of a reliable open source realtime driver for USB.

USB3 is quite capable of supporting high performance real time and USB2 can support real time with a 125 usec granularity.

But why would you choose USB when Ethernet has the advantage of vastly better noise immunity+cable reach, and has
had reliable and stable RT capable drivers for years.

Also note that any LinuxCNC USB CNC interface hardware would also need to be real time, that is you could not use an existing
USB motion control device with LinuxCNC, so to have USB motion in LinuxCNC you would need both the host side real time
driver and some real time USB interface hardware.

(I am not considering the option of modifying LinuxCNC to support buffered devices)

Where Grbl and indeed Linuxcnc share a comonality is in the use of an external interface devices like 7i76E or in the case of grbl an arduino of some description.
linuxcnc having evolved from the bang bang operation of parallel port pins is now transmitting a command string, how the data is transmitted is a matter of choice in hardware. If you can output serial instruction via Lan then you can certainly send it via RS485 or USB. I’m sure its not beyond possibility or capability to transmit the same string that is output to lan is also sent via a serial USB output. Where timing is an issue, there must be a variable which controls the data transmission rate via lan which could be reduced to transmit a data string at an acceptable USB speed. If the string were parsed to send commands (in grbl format) to GRBL based systems the user profile of linuxcnc as a user interface would increase your group profile to 200%. Why we are asking for a linuxcnc approach is because we want a better user interface (basically pathpilot) as the current grbl gui's are limited in functionality. canned cycles, tool changes and probing can all be provided by a gui. Linuxcnc does just that. It’s doing what we are looking for but being protected and limited by the linux community. The open source idea was never intended to be so exclusive. It’s only a small part of the ambitious desire of your readership to build a cnc machine. PCW until consideration is made to support grbl freeloaders like me there is likely to be a large internet population who are going to remain very disapointed and resentful of linux programmers. Its a double edged sword - we hate microsoft but unfortunately dont find linux friendly and encouraging. Shame as after all it is more superior.

All Machines can easy be changed by a 7i92m 65USD and the 5AxisChina BOB at 10USD to run as expected and Ethernet benefits

I think you are some what confused as to how a Linuxcnc\Mesa comb system work and the difference between a grbl based system.

GRBL is a gcode interpreter, ie gcode is sent via a serial port (USB) and the grbl firmware on the adruino board does the trajectory planning, and handles the stepper timing, plus a few other things. I haven't used grbl for a while. The grbl gui is nothing more than a way to send gcode to the grbl board. If the grbl firmware does not support a particular gcode a gui wont be able to add that function. So if the grbl firmware doesn't support canned cycles a fancy gui wont be able to add that function.

Using Linuxcnc to send gcode to a grbl board (if the code was added) would cripple Linuxcnc's functionality. Let's not go into the 64 bit PC vs a 8 bit AVR.

If memory serves me correct the Mesa board receive timing info from the Linuxcnc system (after having interpreted gcode and done the trajectory planning) to control the steppers or servos......I maybe over simplifying this or be wrong.

The open source idea is not a secret exclusive club to keep people out......Just because a particular OSS project doesn't have your wants or needs or the developers do not wnt to take the project down the road to suit your wants and needs doesn't make it exclusive. It just makes it a project with a particular direction that doesn't go past your way. The only exclusivity I can see is that being a reasonable human that can get along with and work with others is an advantage.

As for grbl senders not being available for a Linux system, that is a load of Male Bovine Excrement, many of the senders are cross platform, many are Java based, so the support is there, jusr look at the grbl github page. If there was no Linux support to send gcode to a grbl board the RPi platform would not be an option. So by Linuxcnc NOT supporting grbl I can't see how anyone could be "resentful of Linux Programmers".

After having used grbl, Mach and Linuxcnc\Mesa combo I know what I like and feel is the most flexible. Linuxcnc & Mesa are awesome for what I do.

As for Linux not being friendly and encouraging.......I can't every remember a Linux user replying to another Linux user with a problem with "have you installed all the latest drivers ?" The first thing they may do is ask the person with the problem a little bit more information about there particular system and the hardware.

There is nothing meant to be personal in this post.