Chinese CNC 3020 / 6040 - USB variant

the newer EPS32 wouldst be a big advantage as it has 3Cor 2Realtime for CNC users
its relative new and People will come up soon with it
it has TASK options so you can run the CNC on one Core and the Communication on a other sharing VAR in task flow.
this gives a more likely USB driver

So you would propose taking the trajectory planning away from the Linuxcnc infrastructure ?
Wouldn't this just be the system Mach uses with Mach compatible USB motion controllers ?

MrJTJinx wrote:

Im not beating down on the parallel port as much as i am the retentive nature of programmer to not expand beyond their imagination. The question is why not create a USB variant why only stick to the parallel port.
Im looking for a GUI which will afford me the ability to do tool length, probing and possibly canned cycles. These are all functions which can be managed by the application (as Linuxcnc does). There are thousands og GRBL users out there who are crying out for a better GUI. Lets face it we all want Pathpilot. Even it is more user friendly than the dedicated controls used by industrial manufacturers such as Haas. The users of GRBL are well aware of its limitations ie lack of spindle sync so if its the same limitations with a USB version of Linuxcnc, so what. At least it would improve the GUI and give GRBL users some more toys.
As it happens AsRock have not been very reliable machines just for reference.
How dificult would it be for a genius programmer to write a HID into linuxcnc.

As the parallel port disapears then there is a much greater requirement for data aquisition cards to fill there place, these cards are inherently expensive making a self build cnc machine that much more expensive. Once a self project starts to exceed £4500 we may as well buy a second hand cn machine like a Haas VF1 for just a couple of thousand more.

Sorry for the long quote.....I don't like to cherry pick.

So you want a cnc machine to become a Human Input Device ?

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.

But it seems they use them fundamentally different.
I just read the opening paragraph here (I see it may be out of date): github.com/grbl/grbl
So I am surmising that one writes a gcode text file and then sends it to the Arduino.
I also assume that there are some controls to on the GUI to do basic controls of the Arduino.
But in the end the Arduino does the planning of moves.

linuxcnc on the pc does the planning of the moves and sends speed commands to the hardware.
The hardware (mesa board/motor driver) have no idea about anything but the requested speed.
It's very hardware flexible but it means the interface connection must be reasonably fast and consistently spaced.

Hopefully one can see the difference between the different approaches and maybe why USB is not a good fit.

Pilotpath allows what it does in the GUI because linuxcnc has a move planner that allows those things.
If Grbl doesn't support things you want in the GUI then I would bet it's because the Arduino doesn't support those things.
Getting linuxcnc to talk to the Arduino wouldn't change that.

Now make the Arduino so it doesn't do planning just adjusts motor speed to match speed commands and do that over an interface that can support those commands in realtime and then it's a match for linuxcnc.
But at that point why not use mesa boards.

Machinekit works very hard to support small linux machines to embed in machines if you don't want a desktop to run it.

But it is interesting to hear about different ideas and we sure could use some more developers in linuxcnc if any Grbl guys want to tailor linuxcnc more for printing.

Chris M

But it seems they use them fundamentally different.
I just read the opening paragraph here (I see it may be out of date): github.com/grbl/grbl
So I am surmising that one writes a gcode text file and then sends it to the Arduino.
I also assume that there are some controls to on the GUI to do basic controls of the Arduino.
But in the end the Arduino does the planning of moves.

Pretty sure you have that right, Chris. All the GUIs for the GRBL platform are otherwise known as 'GCode Streamers', because that's all they really do - they simply stream each line of GCode direct to the Arduino and let it decide how best to execute it. The GRBL firmware uploaded to the Arduino has some scope for customisation before compiling it in the Arduino sandbox application (eg which axes to home first, default feed override limits etc) plus the user can configure some key functions in the Arduino using a terminal once the firmware is in there (eg, max velocities, limits of motion etc). I built an A3-sized laser engraver using it a couple of years ago and for something basic like that it is actually pretty foolproof and easy to deal with.

I used to be somewhat cautious about Linuxcnc's reliance on the parallel port for entry-level users, but having used it for several years now I don't have an issue with it. While the PP is definitely an ancient (and arguably endangered) standard, it's still possible to buy a $10 PCI card to drop in to just about any desktop PC to get access to one, which still makes access to the minimum IO requirements crazy cheap. Some new PCs are still being made with them. Old PCs turn up with them for next to nothing all the time if you know where to look.

I've just made the jump to Mesa over ethernet, and for such a high performance interface system it's still a massive bargain in comparison to the competition. Smoothieboard/SmoothStepper is around $150 - $200US. A hobbyists Mach licence is $200US. For that money I could buy 4 Mesa cards, run Linuxcnc on as many computers as I can get my hands on and still have change left over.

Even the recent experiments by Skunkworks, Gene et al running LinuxCNC on the Raspberry Pi 4B elsewhere on this forum are exciting, as it indicates that a dedicated plug 'n play motion control system (software, computer and IO card) for less than the cost of one SmoothStepper is now completely viable.

I personally don't care what cable I use to connect the computer to the mill. I only need it to work.

I think what is missing in this conversation is recognition of different paradigms between these different platforms.
Grbl has one paradigm
Mach has another
Linixcnc has another

Quite simply you can't fight the Paradigm a system is built around as its quite painful. YOu have to pick one and then stay within its boundaries.

Mach is closed source so the user has no way to influence the paradigm.

Grbl is open source so if you want to change it and there is enough memory left, you can do what you want but its really restricted by the limited capacity of the platform.

Linuxcnc is open source and has fewer restrictions due to the platform but its a very different paradigm to everyone else. Some of us think those differences are very powerful. There are many many hardware options it can control and whilst the newer USB3 might be able to keep up with it in real time, there is no compelling reason for anybody to write the required real time driver.

The other application that requires real time processing is music. I'm not much into music but I do know that that is a problem on the windows platform which is not real time. There are some special drivers available but I think latency remains an issue.

Yep Rod, I really think you nailed it in your first 4 lines.

Very well said.

I was quite unaware Banana Benders could be so eloquent

Guys you are missing the basic concept. With linuxcnc transmitted over lan to a mesa card. That instruction could be parsed and sent out over many different transmission protocols as basic gcode instruction which grbl is capable of using.
the real time bit is a fallacy. ok grbl only handles 30k speeds, smoothie 250k (still accepts grbl styled instruction) so if the hardware is handling the operation it is no different that an instruction sent to a mesa card all be it slower for design reasons. windows based hobby machinists are not looking to become experts in linux or have a PC sat on a desk only used for one thing. My current machine handles cad, cam, simulation and the machine GUI. Apart from Fusion 360 how many other cad packages are written for linux. The discussion has gone from how can USB be achieved to excuses and outright denial that its even possible. That little serial message sent to a mesa card can be output via a usb port. speed is an issue but that can also be manipulated, Im sure the original spec for a parallel ports data rate is far less than that of even USB1.
many linux and indeed mach3 setups are using old parallel ports and bit banging the drive pulses. if the instruction was output as a gcode instruction to the usb instead of been bit manipulated to pulse the parallel port pins then that is what we are asking.

The advantage linuxcnc has as a gui over current grbl control panels is the canned cycles and probing (an extended gcode commeand set). Grbl will never handle these commands that is correct but if those command were written and transmitted as move instructions and the math was handled inside the gui then it is most definately possible - guess what linuxcnc does exactly that before bitbanging the pulses out of a parallel port. I may not be a programmer but when it comes to phsyical hardware and interfacing communications i do know a thing or two.
I have worked on forign vessels with a whole array of survey gear and had to get it all to talk to each other and a good old windows pc, worked with Industrial and fibre networks and automated my fair share of factory plant using control softwre such as Iconics not to mention PLCs. I get the distinct impression programmers can only do whats safe and what they know. No matter where this thread goes the answer will always be NO, Im not going to continue with this thread as its not ever going to be productive. Windows has won.

MrJTJinx wrote:

Guys you are missing the basic concept. With linuxcnc transmitted over lan to a mesa card. That instruction could be parsed and sent out over many different transmission protocols as basic gcode instruction

Thats not how it works. You are still in the wrong paradigm.

Linuxcnc does not send gcode to the Mesa becasue Linuxcnc is the motion controller. That means it consumes the gcode.

What happens is that Linuxcnc tells the MESA stepgens to oscillate at a given frequency. Thats what the Mesa card does happilly forever until it is told to stop or vary the frequency. Linuxcnc can tell it to vary that frequency 1000 times a second.

Linuxcnc has already parsed the Gcode Well before hand and converted it into instructions to the Trajectory planner that are buffered. So by the time Linuxcnc starts telling the stepgens to generate steps, the gcode has essentially been thrown away as its done its job.

So when people say you could write a USB3 driver, it has to be capable of sending that set of low level instructions in real time.