CNC USB motion controller

[MechanoMan]

:-), I don't know that I've ever disagreed with Mariss, but a portion of that post is incorrect in the context of the above post. MACH3 and EMC both frequently use kernel and thread times that can be 40us to 50 us and easily have 10us jitter, not sub microsecond accuracy.

But I suspect the post is also out of context, it would make more sense if it was in respose to a suggestion of using USB without intellegence to handle the motion control, so maybe I'm not really disagreeing with him.

Mariss appears to be be responding to a context of using the USB to DIRECTLY pulse a stepper- which IS impossible, it needs to be buffered. Kroko's device buffers, and it takes higher level commands instead of pulses, so the USB limitations are not a relevant issue.

The issue is how accurate the pulsing is so we can compare it to the parallel port and SmoothStepper. I am not saying it MUST be as good as the SS- it's slightly cheaper, and the SS is buggy and every day appears more and more to be a dead product since they appear to have abandoned the driver development in "Beta" state.

OK, yeah, I see where accuracy is possible to the instruction cycle here, which would be 83.3nS giving 0.2% pulse width control for 25KHz, which sounds better than "good".

That would leave the problem that the Taig would only be capable of 37.5ipm, which isn't all that fast as things go. Not bad, though. The parallel port often can't go faster and the 0.2% accuracy is far better than the parallel port will offer.

You've got 480 instruction cycles per PWM. Did you code in ASM or C?

[bsdphk]

Mariss appears to be be responding to a context of using the USB to DIRECTLY pulse a stepper- which IS impossible,

Actually, that is not the case.

USB has two transfer modes, asynchronous, where things happen whenever they happen, and "isochronous" where you preallocate timeslots and get a guaranteed latency, delay and bandwidth as a result.

The basic framerate of USB is 10kHz, but nothing would prevent you from reserving multiple equitemporal slots to achive a higher frequency, so in theory you could have the computer drive the stepper directly over USB.

My guess is that nobody has done this, because isochronous USB transfers is the red-haired step-child in that family: originally it was specified for video and audio use, in the mean time we started to compress that, so it is no longer constant bandwidth and who cares about 0.1ms jitter when the other end of the skype is half way around the Earth ?

Therefore, writing drivers for isochronous USB, or finding programming examples for microcontrollers or USB controller chips, is tricky, and more likely than not, the information you will be provided will be wrong, bugridden and fundamentally misunderstood.

But you _could_ do it, if you wanted to.

It might even be a really smart way to do it, because you could play tricks with looping the send buffers on the host side, so the CPU would not have to care about all the actual pulses, only their frequency and duration.

Poul-Henning

Aka: phk@FreeBSD.org
OS kernel hacker and device-driver author in a different dimension.

[Kroko]

It is a mixture of C and ASM. One cycle normaly has 360 instructions. Something more if new command just came through USB or if command just finished executing.

I'm no USB expert. My understanding is that USB sends a packet every 1ms and that maximum size of packet is 1023 bytes. It is possible to have up to 150 transfers in one frame but that limits packet size. With 150 transfers you only get 1byte packet. You get reliability in exchange for speed. Maximum frequency is 150KHz of one byte data.
The other thing is, that Microsoft does not support multiple transfers.
Perhaps with better processor and come custom drivers it is possible but 18f4550 does not have enough usb ram.

But even if there were no issues with USB, Windows is not a realtime operating system (and neither is Linux). I belive it is imposible to produce acurate pulsing with windows software. So we are back at begining using microprocessors as pulsing engines...

[bsdphk]

But even if there were no issues with USB, Windows is not a realtime operating system (and neither is Linux).

Despite the fact that I write a competing operating system, I have to admit that Linux with real-time extensions does a damn good job.

Most of the latency issues you will see with the Ubuntu+EMC2 combo, is actually caused by the BIOS/ACPI/SMM stupidity which Intel & Microsoft came up with, because Microsoft could not write a stable operating system if their profit depended on it.

I run my Proxxon MF70 on a Via EPIA board, which are not as soaked in the BIOS/SMM/ACPI crap, and I get execllent, consistent low latency.

In Re: USB, you need to read up on that, USB2 introduced microframes which would allow you to increase the frequency considerably.

Poul-Henning

[Kroko]

I just tested CNC USB motion controller on 64bit Vista and it works without any problems.

[bad bearings]

I'm not a programmer, but it seems to me that these delay issues could be overcome by running servos instead of steppers. Why not use usb to drive a servo system? Running a servo in velocity mode. Contouring feedback intervals in the high microsecond range will give good tolerances.

[Kroko]

New version is available for download on CNC USB controller site webpage.

Software now supports DXF format. DXF to GCode and GCode to DXF conversions are possible.

More information is on my 3-axis machine build thread. I report about all things about new developnent off my machine and controller there.

It looks that some professionaly made, ready to use boards will be available. Becouse of professional manufacturing they will be smaller and will have different connectors. If someone is interested...

Here are current specifications:
USB (V2.x) from PC/Laptop
4 axes (step/dir)
PICstep compatible pinout
3 digital outputs (flood, mist, aux)
2 limit switches for each axis (8 total)
25 KHz maximum step frequency
Buffered IO for maximum performance
Manual input via 8 keys (two per axis)
Pause/Resume of execution supported
Simulation of tool path
Standard G-code supported
EMC compatible G-code supported
Tested with SolidCAM, MasterCAM, ArtCAM, CooperCAM, ... generated G-code
Profili generated G-code supported
Import toolpath from DXF file
Export toolpath to G-code
Export toolpath to DXF
G-code to DXF conversion
DXF to G-code conversion

[pminmo]

I might add that it's electrically compatable with the boards on my website and those I posted as open source here years back. The cable just need 180 degree twist.

[Kroko]

Finished and ready to use controllers are available. Check CNC USB Controller page for more information.

[MechanoMan]

I don't suppose you'd be interested in putting out the source code, would you?

[MechanoMan]

What form of communication did you use? Is it ModBus? Can it work with Mach3?
Or is it a homebrewed interface only for use with that PC software?

[Kroko]

I will not publish source code. Sorry.

ModBus protocol is for RS232 and TCP/IP connections only. I'm using HID protocol via USB here.

Mach3 is not needed in this solution.

Mach3 is software pulsing engine which generates step/dir signals on parallel port. Motor drivers are usualy conected to parallel port through break-out board (BOB).
In my solution controller acts as pulsing engine and generates step/dir signals for motor drivers. My software is needed to instruct controller what to do.

Mach3 has a lot of settings because it has to deal with many different setups. My software works with controller and does not need to have so many settings.