Chinese 3040 machine

GroupDIY Audio Forum

Help Support GroupDIY Audio Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Well, this is like machine insurrection, I screwed something with windows 7 and it doesn't start now on the old Pentium 4, I got an Arduino to try GRBL, having trouble to install drivers in two different computers...

I tried with every BIOS configuration for LPT port with no luck, I will try to install XP, maybe the non earthed pcbs were causing malfunction?
 
dirtyhanfri said:
I'll use it mainly for light engraving and pcb milling, now I have to find a old computer to run it, or maybe try with arduino/grbl, but as far as I know, stepper drivers in Arduino shield format are not suitable for current reasons, anyway I have found some Pentium4 computers with parallel port for around 20-50€, so not a big problem..

Wait a minute! A product sold in 2015 uses a parallel printer port for its interface? What kind of fuckery is that?
 
It works!

Just installed XP, Mach3 and it came to life, now I'm gonna try and try to mill some scrap pieces...

Looks like windows 7 was causing some issue with LPT port...

Yes Andy, it's related to Real time performance, anyway I've seen controllers with Ethernet connection, I have to look about it, switching back to a ancient Pentium4  just for some lines of code is a huge PITA
 
dirtyhanfri said:
Looks like windows 7 was causing some issue with LPT port...
Windows 7 completely virtualizes the port. XP might still allow direct access.

Yes Andy, it's related to Real time performance

Oh, I get it. The mill has zero intelligence in it; the PC does all of the decisions about what to move and when and to where.

That can still be done with over USB (that's what so-called "WinPrinters" do), but that would require a redesign of what is obviously an ancient interface.
 
Tradition in "open" CNC systems is that you only have a simple stepper motor interface - enable, direction and step. This ensures cross compatibility and ease of parts swapping.

Drive this with a hardware-control parallel port, or use any type of USB- or network interfaces with any form of onboard processing "intelligence". The point is that anything intelligent locks you down to a specific software.

Jakob E.
 
gyraf said:
Tradition in "open" CNC systems is that you only have a simple stepper motor interface - enable, direction and step. This ensures cross compatibility and ease of parts swapping.

Drive this with a hardware-control parallel port, or use any type of USB- or network interfaces with any form of onboard processing "intelligence". The point is that anything intelligent locks you down to a specific software.

So instead you're locked into an obsolete interface which is supported only by obsolete operating systems.

gotcha.
 
Actually it's easy to get an ancient computer to run it, I spent 20€ on it at 10 km of my home (found it in a classifieds ads web, lots of old computer almost for free...) and it's better to have a dedicated computer for the task.

About the OS, has anyone tried with EMC/LinuxCNC? looks like a good alternative, lighter than Windows and designed for use the parallel port in real time exclusively ...

Or you could run it via GRBL with an Arduino Uno and plug it to your laptop via USB, maybe for simple tasks it's ok, I'd like to give it a try...

 
There _are_ alternatives out there;  I use PlanetCNC, which is a USB solution from some guy in Slovenia.  It works well.  But, who cares if parallel ports are obsolete if they still work?  They're people on here recording with all tube gear...
 
Or, in more detail for Andy's sake:

cheap stepper drivers don't include the motion control intelligence necessary to make the machine run.  There are many, many ways to go about it;  there are cheap usb options (tinyg), more expensive usb options, very expensive PLC units, and so on.  But, the cheapest and easiest way to get the machine running is just to use a standard PC and bang out the step & direction pulses onto the different pins of the parallel port, which goes directly into the stepper driver.  It's not cutting edge, but who cares?  If you don't like it, there are plenty of other ways to do it, and it's a hell of a lot cheaper and easier than the other solutions for hobby CNC.
 
It's actually very interesting:  modern PC's have abandoned the notion of "guaranteed latency" for external peripherals,  favoring maximizing bandwidth over multiplexed channels.  I did some testing around "isochronous" USB interfaces (naively thinking this shouldn't be too hard of a problem to solve), and even buried in the specification are "latency bounds", which is extremely unhelpful in these CAD applications.  If you can guarantee a "fixed" latency between sending an instruction and having it dispatched at the HW being controlled then real-time stuff like CAD/CAM becomes a real PITA.

There's solid engineering history behind using the parallel port:  people forget that PC's used to have memory-mapped parallel port registers, and you could invoke operations on them with very tight ISR's wrapped around calls to "outportb", which was a fancy macro around the OUTB x86 instruction, which has been around since the late 80's.  This could be guaranteed to be almost "atomic" and run in a handful of cycles.  You could call OUTB and see your end on a scope within several hundred nanoseconds, making it perfect for this sort of control.

Very difficult to emulate nowadays, but I would think a combination of 32 bit microcontrollers running dedicated stacks, perhaps over a re-purposed Ethernet interface, would make this manageable.  In fact even on a cheap 50MHz 32-bit ARM processor, the latency when bit-banging GPIO's is actually faster than antiquated parallel port interfaces, <hand wave> provided you can get the "step/direction" instructions to the microprocessor in a timely fashion </hand wave>.  Ethernet has guaranteed latency as a function of wire length, so that's why I think it may be good for this sort of thing.

Perhaps there's a market for something like this?
 
Matador said:
It's actually very interesting:  modern PC's have abandoned the notion of "guaranteed latency" for external peripherals,  favoring maximizing bandwidth over multiplexed channels.  I did some testing around "isochronous" USB interfaces (naively thinking this shouldn't be too hard of a problem to solve), and even buried in the specification are "latency bounds", which is extremely unhelpful in these CAD applications.  If you can guarantee a "fixed" latency between sending an instruction and having it dispatched at the HW being controlled then real-time stuff like CAD/CAM becomes a real PITA.

There's solid engineering history behind using the parallel port:  people forget that PC's used to have memory-mapped parallel port registers, and you could invoke operations on them with very tight ISR's wrapped around calls to "outportb", which was a fancy macro around the OUTB x86 instruction, which has been around since the late 80's.  This could be guaranteed to be almost "atomic" and run in a handful of cycles.  You could call OUTB and see your end on a scope within several hundred nanoseconds, making it perfect for this sort of control.

The PC wasn't designed to be a deterministic programmable logic controller; that you could get the sort of performance needed to drive a CNC machine was a function of its simple architecture -- with that direct hardware access you describe -- and its single-tasking operating system.

See, people also forget that PCs ran a simplistic single-tasking operating system that handed off peripheral access to the BIOS. And people also forget that the hand-crafted timing one invented to control a peripheral would be thoroughly screwed when a faster processor came about. Yeah, going from 4.77 MHz to 8 MHz caused a lot of real problems.

People also forget that you couldn't do anything else with the PC while it was printing out your homework or driving your stepper motor controller.

Now introduce a multitasking operating system which out of necessity has to abstract peripherals. Application programs have to go through device drivers which managed the hardware access, and attempts by applications to access hardware directly are greeted with access faults. (Or nowadays the OS won't even run those programs.)

Very difficult to emulate nowadays, but I would think a combination of 32 bit microcontrollers running dedicated stacks, perhaps over a re-purposed Ethernet interface, would make this manageable.  In fact even on a cheap 50MHz 32-bit ARM processor, the latency when bit-banging GPIO's is actually faster than antiquated parallel port interfaces, <hand wave> provided you can get the "step/direction" instructions to the microprocessor in a timely fashion </hand wave>.  Ethernet has guaranteed latency as a function of wire length, so that's why I think it may be good for this sort of thing.

The 32-bit ARM you'd consider for this project is so much more powerful than the 8088 that it's not funny.  Hell, Silicon Labs has a whole portfolio of 8051s which run circles around the 8088.

So why not put the timing logic in the machine's ARM? Invent some kind of language so you can send commands over your favorite interface to the machine. The ARM can interpret the commands and translate them into the timing needed to drive the mechanisms. This makes more sense than letting the PC do all of the heavy lifting. And a lot easier to debug, I'd imagine.

-a
 
That's what most of the external interfaces do;  the computer feeds gcode to the uC, which then figures out acceleration curves (and whatever else) and sends the appropriate signals with the appropriate timing to the stepper drivers.  But, it costs more to do this than to just use the parallel port and drive the stepper drives directly.

Seriously, the parallel port thing works fine.  There's nothing wrong with it.  This isn't an application where the best and latest is always necessary.  Mach3 has been around forever and works reliably. 
 
I have to say after a few days using it I'm happy with it, knowing it's limitations...

After getting used to Mach3 and basic CAM routines it's quite intuitive, I've even edited code manually almost from day one with no surprises, been able to get autoleveler working on Mach3, being a absolutely newbie I'm happy with it.

I milled some basic things on wood and a pair of pcb's, I broke some bits, of course, but I start to get confident about using it.

The parallel port isn't an issue by itself, the issue in my gig is the ancient  computer having that port, even editing code with notepad is slow with that computer...

The hardest step for me is the Gcode generation process
 
..but most modern hardware is not really supported by the OS's that will run direct-hardware access: Finding a new motherboard that will support win98 drivers (or earlier) is not easy these days!!

Parallel port by itself is no fun from xp and forwards, where there is no direct hardware access layer.

Jakob E.
 
Andy Peters said:
ruffrecords said:
gyraf said:
Parallel port by itself is no fun from xp and forwards, where there is no direct hardware access layer.

Jakob E.

Ah, the joys of closed source software.

Can you do direct parallel-port access with a modern version of Linux?

-a

There is a Linux distribution with real time kernel patches added that is aimed directly at CNC applications; It is called Linux CNC. AFAIK, the Linux Kernel still includes parallel poprt low level drivers. The latest version of Linux CNC is a 'live' one that can even be run from a flash stick. (A live Linux  distribution is one that you can boot straight into on any computer that can boot the media and it will run without being installed. It may be slower than if it were installed but it allows you to try it in complete safety). Any modern Linux distribution will install itself alongside windows XP and automatically create you a dual boot menu so you can run either windows or Linux on the machine.

Cheers

Ian
 
I'm following with interest.
I have a Small CNC machine (not a 3040, but a zen tool works one).

I tried running it with mach3 etc, and was always disapointed.

I'm now thinking about running it with GRBL, with a Octoprint head running on a raspberry pi.

 
Yesterday I got to work a Pentium4 @3Ghz with 2Gb of RAM and dedicated graphics card, installed XP, Mach3 and some CAD/CAM software, no internet, no firewall, anything but CNC related Software, it's day and night difference compared with the computer I've got hooked to the machine right now, still have to make some tests with Mach3, but looks promising, Driver Test says everything is ok, and LazyCAM looks quite usable (it crashes my old computer).

Now If i can make it work through Remote Desktop via local net I'll be happy. I plan to build an enclosure for the CNC, a vacuum cleaner and the computer

ruffrecords said:
There is a Linux distribution with real time kernel patches added that is aimed directly at CNC applications; It is called Linux CNC. AFAIK, the Linux Kernel still includes parallel poprt low level drivers. The latest version of Linux CNC is a 'live' one that can even be run from a flash stick. (A live Linux  distribution is one that you can boot straight into on any computer that can boot the media and it will run without being installed. It may be slower than if it were installed but it allows you to try it in complete safety). Any modern Linux distribution will install itself alongside windows XP and automatically create you a dual boot menu so you can run either windows or Linux on the machine.

Cheers

Ian

I feel curiosity about LinuxCNC, I've got a unused HD drive I could use to install it. being a Mac/Ubuntu user for the last 20 years doesn't make easy get used to windows enviroment, but I had enough of dealing with computers by now (the last month I switched my three work computers to Windows 7 - XP and fixed some family computers, I'm a bit tired of installing OS's)

Rochey said:
I'm now thinking about running it with GRBL, with a Octoprint head running on a raspberry pi.

I was about to try GRBL too, but had some issues with Arduino drivers, anyway, at least beeing a newbie, I think it's worth learning Mach3 or similar, I'm not sure if you can change things like feedrate in real time using GRBL, or if you can pause and continue a program if something goes wrong, at least, I think Mach3 gives you a deeper understanding of what's going on
 

Latest posts

Back
Top