I do understand what you are saying. I am probably being too terse with my replies. At maximum step rates, the multiplexed lines, that is, the direction output pins, are available for (slightly) less than one ISR period. Even if, for example, the LCD is sent data every 1000th ISR, the time to set the LCD data pins and toggle the LCD_EN pin is quite short because it must be completed before the next step pulse. At lower step rates, there is plenty of time. I don't know what step rate is 'too fast' for LCD (and switch) control...Originally Posted by James Newton
Well, that's what separates the men from the boys. ;-)
I think you've made a good choice with your board layout because you can fit 8, 14 and 20 pin devices in the same socket. The 28 pin chips I listed would wreck that flexibility because power, ground and oscillator pins are utterly different.
For some tasks, that "$8 CNC controller" is the right tool. But for 'real' motion control, the processing power just isn't there, especially given how cheap a PC running EMC can be - free!
Just for my curiosity, why are you looking at PIC18's? I wrote motion control test assembly code to the PIC18 and I couldn't get comfortable with the W register. It seemed like it's shortcomings stood in the way of writing easy flowing code.
I switched over to the PIC24FJ and it was like I died and went to heaven. Compared to the PIC18 and most other processors I've written code for, this is the sweetest MCU I've ever encountered.
Mariss
You will get no argument from me. I can see perhaps only 2 reasons to use an '18F: pre-existing code base and 5 volts, neither of which is really that compelling. Perhaps in the hobby world, time is cheap.
For my own curiosity, why did you stop at PIC24F's and not continue to PIC32MX's, especially considering they (can) have the same pinout?
Most use Pic18's because they started using them before the DSP16's came out. I could convert my Viper to run dspics, (they run 18F2431) but on the 28pin dspic you loose 2 i/o lines on the 28pin version.
I'm amazed Micro chip keeps adding to the 8 bit and 12 bit PIC16F line when the cost just a few pennys less that their 16 bit chips.
People seem to stay with when they know.
I don't think you can create a evenly spaced pulse stream ,timing off the longest line. On a slope like 9/10 you would have to drop 1 pulse in every 10.
To space evenly 9 pulses over 10, you would need 2 timers or 2 interupt routines. (please correct me if i'm wrong)
Larken- James is correct Bresenham algorithm will do that job fine.
Vegipete- nice code!It's similar to one of my early multiaxis systems using a DDS like accumulator to work directly in "speed" which has the benefit to give linear accel and decel ramps quite easily. I later moved away from that system for a couple of reasons; it's a little clumsy and chews up instruction cycles integrating Bresenham on top of the DDS system, and it gets very clunky if you want to add sophisticated features like S shaped accel ramps, tuned accel to get through resonance regions etc which are best done with a lookup table.
Once you add a lookup table it's better to simply work in periods again, not "speed" (like in our earlier discussions in this thread) which then simplifies all the Bresenham code as there is no need to do the separate DDS "speed" acceleration system.
As for the PIC 16/18/24/32 argument, I think of it a bit like hammers. I have tiny hammers, carpenters hammers, right up to a 14 pound sledgehammer. I don't just reach for the 14 pound sledge on every job when a small hammer might be a nice fit...
A fairly easy way to make brezenhams have a smoother pulse placement is to 'over clock' it. 4x or more
Lets say you need to move 1000, 900,25. Multiply each by 4 (4000,3600,100)
Run at a 4x faster velocity and only step on ever 4th pulse.
I used this in my old Lcam (dos) program and it greatly smoothed out the movement. Linear and circular.
The other way in a PIC is to use the 3 (16 bit) Timers and load the timer value with the velocity. This creates a perfect pulse placement, but can't run fast enough in a PIC.
Thats why i think Maris runs timers in a FPGA ? Mach3 runs free running timers and corrects them with a parallel loop.
Vegipete
Good question. I have to fit an MCU, an FPGA, a FLASHROM and an RS-485 transceiver in a motor drive. My power supply budget is 25mA @ 3.3V, my real-estate budget is 0.7 square inches (450 square mm) and my parts cost budget is $10 total. The PIC24FJ was the best fit given those constraints.
The PIC24FJ is also 'fast enough' given what it is required to do. As you probably know, I have opted to use an FPGA for step pulse generation and motor drive logic because it off-loads a tremendous burden from the MCU. Besides pulse-train generation, the FPGA easily handles the Clarke-Park transforms and their inverses necessary to implement Field Oriented Control of the motor.
I have chosen to develop an 'on-the-fly' motion control algorithm meaning acceleration, velocity and terminal destination can be changed while a motor is in motion. The PIC24FJ math capability (hardware multiply and divide) is sufficient to solve the quadratic equations needed for executing this algorithm 1,000 times a second. This what I mean by 'fast enough'.
Mariss
Actually I don't use timers because timers produce a frequency that is the inverse of the timer period. The 1/x function is very non-linear and the resulting pulse train has terrible resolution at the high frequency end of the scale.
I generate pulse trains using accumulators. The frequency then is a linear function of a command input value and all possible frequencies are evenly spaced. An accumulator uses an adder (A + B = SUM and CARRY) the adder SUM goes to a D-flop register and the register Q outputs go back to the adder's input port B. CARRY is the output pulse train frequency. The register is clocked at 8MHz so its output frequency is 8MHz ( x / 2^n). If a 16-bit accumulator is used, you get 65,535 evenly spaced frequencies ranging from 0Hz to 8MHz. The CARRY frequency is divided down to get a reasonable 0 to 100kHz output while keeping a 1 / 8MHz clock (+/-62nS) phase jitter. An FPGA is an ideal device to implement this circuitry.
I'm just saying there are different ways to skin a cat.:-)
Mariss
Well said. Although occasionally it's therapeutic to 'fix' a watch with a sledgehammer. Sort of like driving an SUV.As for the PIC 16/18/24/32 argument, I think of it a bit like hammers. I have tiny hammers, carpenters hammers, right up to a 14 pound sledgehammer. I don't just reach for the 14 pound sledge on every job when a small hammer might be a nice fit...
Fundamentally I agree with you. Bresenham's algorithm gets the job done but it's meant more for discrete pixels in a plane, not for generating evenly spaced pulses in the time continuum. Fortunately mechanical systems will help filter out step irregularities.
My code could be expanded to add fractional steps to multiple axes to generate more evenly spaced, non-synchronous steps, but adding that many multi-byte values would quickly overwhelm the poor little PIC18F. As I wrap my brain around Mariss's posts, I get the impression that that is approximately what he has implemented in the FPGA.
This reminds me of a paper I found a few years ago, describing a different line generating algorithm. This one steps along the long axis and adds the fractional slope to the other, stepping whenever the fractional part overflows and generates a carry.
That's a standard DDS or DDA system (to use the modern fashionable buzzwords) which is also what Vegipete used in his PIC code.
On a smaller slower PIC a timer based system can have advantages as it doesn't need to have "dead" cycles like DDS, and can work directly with the Bresenham on each timer period.
Larken- Sorry I misunderstood earlier what you meant by "evenly spaced pulses"! It's really not possible to get evenly spaced pulses without infinite resolution, and speed constraints, size of variables etc always leave a certain phase error. You are right you can use a higher resolution Bresenham to reduce the jitter however the stepper motor or servo encoder can only ever be accurate to the nearest step and so using a higher resolution has little to no significant benefit when moving (which Vegipete said too, more or less).
That's just another variation on Bresenham with the carry handled in a slightly different way. Even the DDS/DDA systems are still Bresenham in nature but use a binary factor as one of the two factors (for speed) where Bresenham can use a binary factor as one of the two factors but is not limited to that, it can use any two factors. I had a recent discussion with one of the brainiacs from the time nuts forum, on whether Bresenham should have got a lot more credit for the entire concept of handling fraction generation using nothing more than additions subtractions and overflows.
No, it makes a big difference when cutting vector circles and angles close to 45 degree's (40-60 degrees make the most resonance with breshenhams).
A stepper with no dampening ( coupled directly to a lead screw) stalls far more easily with pulses that are poorly spaced. (that why Mack3 can run so fast and smooth. It uses independant timers for each axis (software).
Cutting a line 100,97 at speed means it looses 3 pulses over the 100. That sets up a resonance you can hear.
With a 4x overclocking this is very much reduced. Try it !
I understand your point.
But I'm not sure if you are talking about microstepping? Most machines will run microstepping, for instance 5mm lead leadscrews and 1600/2000/3200 microsteps per rev are the common values for stepper drivers. That gives a per-microstep distance of 0.003mm to 0.0015mm which is much finer than any mechanical tolerance (slop/flex) of the machine.
Also, regardless of the internal granularity the Bresenham can only generate output pulses at the same microstep granularity so for your example of x100y97 it will still generate the same 3 microstep difference over the x length of 100 microsteps. It cannot get granularity finer than the microstep granularity to the output.
Actually re my first staement I think I might be completely missing your point?
No, i'm wrong ... i just found a doc on mach written by Art explaining mach3.
He uses a clocked 'Pulse Shooter' driver that continously checks a circular buffer for pulses to output. The spacing of the pulses in the buffer determines speed and acceleration. But when the filling App (planner) puts the pulses in the buffer it spaces them out evenly. Ingenious, but complex and very cpu intensive. But it works well.
Roman, i will put that overclocking routine on here when i get some time (too much work right now) to show you the improved pulse spacing.
That is indeed a very interesting document. Fighting the OS to get real time (ish) control is not easy.
===============
I've been mucking with my step ramp code and made some improvements. In the process, I squished some bugs that related to short or slow moves. (Single step moves went haywire and turned into (maybe) 4294967295 step moves, as did moves that reached max speed before the first step pulse was generated.)
I've added serial routines to the code, with hardware handshaking. Simple serial commands allow setting the maximum step rate, the acceleration and the requested number of steps to move, forward or backward. A 128 byte circular receive buffer holds incoming characters and the host pc is told when to stop sending. Seems to work nicely with an FTDI USB-Serial cable. This functions without disturbing the pulse timing.
I'll post code on my site in a few days...
Nice! I'll be looking forward to seeing that code. Let me know if I can help support your efforts.
PIC chip with builting hardware for stepping?
Well, there are certainly some interesting new PIC microcontrollers. Consider for example the PIC16F1507. There are new peripherals, including one called a "Numerically Controlled Oscillator" which looks like it could be used to implement the core of my stepping algorithm in hardware. Plus the chips are really low cost. Sigh, more and more to learn...
Wow... and it has that same lovely pinout... Still, it only has one NCO, yeah? so that only works for one axis... Although... since the cost is so low... maybe one per axis on a PCB specially designed to support it? Filed away for future reference.
I haven't publicly announced any of my code improvements in a while so here is an update.
I've moved the code to a PIC18F14K22 to be able to run it even faster. The internal oscillator can run at 64MHz, for 16MIPS throughput. This has let me get the max step rate up to 100 kHz.
I implemented a serial port system with a receive queue maintained by the ISR and hardware flow control. Using special commands, a connected motor could be commanded to move. However, the oddball commands were too awkward for general use so I implemented a rudimentary G-Code interpreter based on step units.
I have also implemented Bresenham 2 axis coordinated linear moves. The overhead to add this was remarkable minimal, adding fewer than 25 asm statements inside ISR. Much of this was due to working with 32 bit values.
I am currently overhauling the G-Code interpreter, or perhaps said more accurately, writing an entirely new one, that includes, among other things, an understanding of real world units and not just steps.
Sounds very cool Pete, can't wait to try it!
James hosts the single best wiki page about motors for CNC hobbyists on the net:
http://techref.massmind.org/techref/io/motors.htm Disagree? Tell him what's missing! ,o)
I've posted source code on my forum for a more recent version of my software ramp generator. The implementation has a rudimentary 2 axis G Code interpreter. It operates in units of steps and nicely handles two axis linear moves. Enjoy!
Posting Permissions
Reply with Quote
