I'm pleased to announce CNC USB motion controller. Check project home page for more information.
Andrej
Printable View
I'm pleased to announce CNC USB motion controller. Check project home page for more information.
Andrej
I'll soon start building low cost 3-axis machine with basic tools which will be powered with CNC USB motion controller and PICStep drivers. I'm waiting for material to be delivered.
I'll create a build thread so that you could see progress.
Until then you can check my CNC hot wire foam cutter. Cutting foam wings is realy simple with this setup.
That's pretty cool! I've a shop full of professional cnc equipment and I couldn't do that! I'm impressed!
But you used a PIC18F4550?
That can't step very evenly at all. None of the PIC line have useful specs in this area.
I spent awhile drawing up similar plans before seeing that the PIC18 line just won't perform satisfactorily, due to the 10MHz instruction cycle. It needs to be around 10x-100x faster to perform "well" for CNC use.
Actualy PIC18F4550 performs just fine. With 12MHz instruction cycle (this PIC runs at 48MHz) I get around 25kHz maximum step rate which is more than enough for stepper motors with 8x microstepping which is what I'm using.
Other systems and popular parallel port solutions work in similar range. 100x faster means 5GHz frequency which is faster than most processors available. If you need that kind of performance I sugest you go analog with servo motors.
After all, this is 100$ solution not 100.000$.
Andrej
But 25khz is not nearly enough.
Assuming the steps go to a Gecko, that's 10 microsteps/fullstep, and a Taig 20 tpi leadscrew:
That's a theoretical max of 37.5 ipm. But, that's only ONE speed and not applicable to most any CNC case.
The problem of reality is that you've probably got pulses broken down into 40us timesteps of resolution. If a program asks for 30 ipm, that needs 50us steps. The only way this will be accomplished is to space step pulses steps 40us, 40us, 40us, 80us, 40us, 40us, 40us, 80us. That's FAR too rough to step "properly". There's a huge deceleration asked for during the 80us-step and then acceleration before the next 40us. That's also a big phase error and can easily cause lost steps. It's only able to regulate the pulse width "well", such as as +/-10%, at 3.75ipm. In that case you'd have 400us, 400us, 400us, 440us, 400us, etc. I believe it would still have measurably degraded performance over 1% pulse width control.
Even assuming I'm mistaken and this can actually adjust spacing to intermediate spacings between 40us and 80us, the total PIC18F4550 capability cannot physically exceed 83nS steps, and in reality it's not possible to get that kind of resolution. That's where I concluded it's generally NOT possible to do with a PIC18F when evaluating my project earlier.
MechanoMan has a valid point. A 25k kernel with 1/8th microstep drivers has exhibited issues with other cnc software. It's infrequent, but it does happen. And it's a difficult issue for the user to pin down because their system runs fine for thousand of lines of G-code then all of a sudden, one line on one part repeately won't work correctly.
Cplds are better suited for this sort of thing, fast and cheap. see mariss' tutorial. If you really want to use a microprocessor check out the cypress psoc a sort of hybrid with analog and digital blocks.
Amplexus Ender
CPLD's don't have the ALU and math functions necessary to do motion control. You would have to design the ALU and math processing which would be a waste of time since micros and FPGA's already exist. CPLD's would augment a micro nicely to free up tasks that are a waste for a micro.
Yeah, I've not programmed FPGAs myself but that task definitely looked like FPGA domain.
A CPLD for the lowest level "counting" tasks paired with a microcontroller also sounds practical, but I couldn't say.
Smoothstepper was a pretty good implementation... but for some odd reason they seem to have abandoned the project in the beta state. It's still got bugs and they haven't released a new revision of the beta plugin since Jan. They never documented the interface so no one else can use it or try to make a better plugin.
You are completely right that faster is better and there are issues at high speeds. This isues are general and are not specific for my PIC18F4550 board.
All step/dir controllers exhibit the same issue. Faster controller just means faster machine with same issues. Mach and EMC software solutions and other similar harware solutions have the same problem. Some of them are faster (but not for much) but issues are the same.
Bigger and faster is more expensive. Why don't we all drive Ferrari cars?
My controller is cheap and produces satisfactory results for hobby use and that is good enough for me. Perhaps my reaction is too emotional. I'm proud on my controller and it hurts me that you're flaming it without ever seeing one.
Check my 3-axis built thread. This controller will control low cost machine that I'm building.
I just realized what you mean with rough resolution.
My controller adjusts spacing of pulses. It has resolution of 0.08333us and maximum frequency about 25kHz. Time between two steps is a multiple of 0.08333us. So if 40us is possible so is 40.08333 if we want to go little faster and 40.16666 if we want little faster...
Becouse of low frequency maximum speed is limited but that does not affect resolution.
Kroko
here are some comments by mariss about usb
#17 08-18-2005, 08:09 PM
Mariss Freimanis
Gold Member Join Date: Mar 2003
Location: United States
Posts: 2,053
It's hopeless to even try. Here's why:
Step pulses have to be timed to sub-microsecond accuracy.
Don't believe it? Try this: 20,000 pulses per second have 50 microseconds of time between pulses (1/20,000 = 0.00005 seconds). 19,999 step pulses per second have 50.0025 microseconds between the pulses. The difference is 2.5 nano-seconds (2.5 billionths of a second). Small time-scales indeed.
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.
Neither you nor your printer much cares if data is delayed anywhere from 1 uS to 1,000 uS. Your step motor drives will care a lot though and they will not run.
Mariss
Amplexus Ender
:-), 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.
While 1ms latency is a USB issue, it's also kind of a myopic look at how to use USB. If you consider that you can stream large amounts of data via USB in some of the more exotic modes of USB, the latency essentially isn't a huge issue. Read up on isochronous transfers in USB.
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.
Target speed - approx 5 - 6 in / second, so call it 150 mm / sec. (Edit - thanks Kroko for the math correction - guess I was tired)
Target resolution - approx 0.1mm linear motion per stepper motor step.
Microsteps - assuming 10 micro steps per step, 200 steps per rotation, so 2,000 micro steps per revolution.
The router is belt drive. Each belt is driven by a 100mm pitch diameter timing pulley, with a 2:1 reduction from the stepper motor.
Using my math, each time the timing pulley makes one revolution, the belt will move
Dia x Pi = 100mm x 3.14 = 314mm.
Each revolution of the stepper motor will move the belt 1/2 of this, so 314/2=157mm.
Each microstep of the controller will move the belt 1/2000th of this, so
157mm / 2000 micro steps = 0.0785mm, which is close enough for me to 0.1mm.
I think I am ok so far, but please feel free to check my math.
As far as speed, I am not as certain on this calculation, but here goes:
25 KHz pulse rate x 0.0785 mm per pulse = 1900 mm/ sec. (edit - Thanks Kroko for catching my typo / math error)
This seems to be well within my accuracy and speed needs unless I am missing something.
The post is indeed somewhat out of context, i posted it to bring up latency issues in usb.
usb3 may make all of this moot. I will do some reading on isochronous transfers if I find a bit of extra time. Is there an advantage to usb over parallel ports other than the fact that it is ubiquitous?
Amplexus Ender
Hi, I posted on this thread with my question because as a potential customer for a new product, I am attempting to make sure that it would work for my application. Clearly there is a separate discussion going on regarding its applicability and capability that I have also of course read.
As far as USB vs parallel, I guess the bottom line is that none of my existing computers have a parallel port (all laptops) so that means I would be buying a dedicated desktop just to run a DIY hobby router. If this controller can help allow me to use my existing laptop by just plugging in an external controller to the USB, then that is pretty high value to me. Doing the design work inside and just carrying it to the garage as needed is quite appealing. I know that this whole Laptop + USB driven area is pretty dicey, so I don't go into this lightly.
I think the pcmia parallel port cards will work perhaps better than usb, also free or dirt cheap desktops are easy to find.
Amplexus Ender
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.
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.
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
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
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?
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.
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...
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
I just tested CNC USB motion controller on 64bit Vista and it works without any problems.
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.
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
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.
Finished and ready to use controllers are available. Check CNC USB Controller page for more information.
I don't suppose you'd be interested in putting out the source code, would you?
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?
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.
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.
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.
Can I use G40-G41-G42-G43-G44 codes by your system?
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.:confused: