[Kroko]

...
USB can have 1,000 microseconds of latency (delay), sometimes much less, sometimes much more. How is this exquisitely sensitive step pulse timing going to be preserved then? Answer: It can't...

You are completely correct if we assume that step/dir are going through USB. In my case computer sends commands (similar to g-code but highly optimized) to controller and controller has a buffer for 20 commands.

Most PCMCIA cards don't work becouse they are not true paraller port cards but USB->parallel converters. There is one card thar works from Trans Digital. Problem is that it requires PC card slot and most modern laptops have only Express slot. I got answer from them and they claim that it is impossible to create such a card for Express slot.

[Kroko]

Hi, if you don't mind, I would like to post my targeted setup as an example and see if this controller would be viable for my use.

I quickly checked your math. I found two mistakes. 6 in/sec is 150 mm/sec and not 15. And at the end 25 KHz pulse rate x 0.0785 mm/pulse = 1900 mm/sec.
I guess my controller will work fine for you.

In my foam cutting machine with 8 microsteps I use M8 screw for spindle and I need 2560 steps for 1mm of travel (that is 0.000390625 mm/step). Maximum teoretical speed is around 10mm/sec. In reality I get 5.5mm/sec without losing steps. I start losing steps becouse of motors and not controller.

With 16mm/4mm spindle and 10 microsteps maximum teoretical speed is around 50mm/sec.

For faster speed I recomend servo motors and not steppers. It is not only limitation of controller. Stepper motors are not designed to work at high speeds.

[harryn]

Hi - Thanks for the math check - I guess I was more tired than I thought last night. I edited my original post with the corrections.

So, the idea is that I can just take this board and your software, and it will work on most modern laptops with Windows Vista Business 32 or 64 bit through a standard USB 2 port and it should work?

Thanks

Harry

[Kroko]

I didn't try 64 bit Vista. There is no reason not to work but I'll try and report. I just need to find one.

Andrej

[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: [email protected]
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.

[MechanoMan]

What version of G-code does it support though?
That's a problem. There are machine differences in G-code, which is why many CAM programs allow you to select the end machine. This is a nonstandard machine which no CAM makers are specifically trying to support (and testing their support for), except for your own CAM tools. Now it may not be all that much of an issue, differences in target machines don't come up every time, but it could still come up.

[Kroko]

Controller behaves just like EMC2 and should work exactly the same. G-code type is RS274NGC.

If CAM works with EMC2 it will work the same way with my controller!

I was aware of this issue that is why I chose well known and well documented standard.

[pikocnc]

Can I use G40-G41-G42-G43-G44 codes by your system?

[Kroko]

G40, G41, G42 (cutter radius compensation) and G43, G49 (tool offsets) are implemented.

Current version has a bug in simulation and reports errors with some parameters but I will correct this in a few days.
I must also check why this error wasn't catched with unit tests.