| | |
Ok, so I'm wanting some small uC code to translate 3d lines into step and direction signals for a 3 axis CNC machine and there just doesn't seem to be any... so I'm writing it. Feel free to follow along, post comments, tell me about the syntax error I haven't noticed yet or generally why it won't work and could be done better. It's in a google doc so I can work on it from anywhere; you should be able to view it by clicking on this link:
docs.google.com/document/d/1HapqposfsgFGLqbPkxlH6VZ2aw7lSAqmXmIXz959Sy4/edit?hl=en
let me know if you can't see it...
The code is pretty close to working for the case of lines where the X movement is largest. There is a problem with stopping distance calculation. X velocity and Max acceleration should return to there original values at the end of the line and they are overshooting. Any advice appreciated.
A simple idea is to store the distance taken while accelerating. Once the distance left to go is equal to or less than this value, it's time to decelerate. Force velocity to zero when distance to go is zero. This works so long as the accel and decel slopes are symmetrical.
A more complex method (allows for accel, velocity and destination to be changed on-the-fly) requires a continuous calculation of a 'predictor' velocity at which deceleration must begin for a given rate of accel. This involves continuously solving a quadratic equation though. :-)
Mariss
Yeah, if you look at the code, that first method is what I'm doing. I sum up the change in velocity to a variable called sd and when I have fewer than that many steps to travel, I start undoing the changes I made. But for some reason, I'm undoing more than I do...
See if this flowchart helps. The diagram has 4 states, accel, run at constant vel, decel and stopped. It's what I came up with when I designed the G100 so I know it works.
Mariss
Hi Guys,
I have been contemplating a similar project for some time now, and because I am a very accomplished procrastinator, I haven't really got anything to show for my efforts.
What I have been thinking is along the lines of the early NcPod, the Gcode is compiled on the PC to achieve 1mSec "blocks" of "go to this coordinate" commands, all the ramping etc is handled by the pc's gcode compiler. To take further load off the micro (I was thinking of the Propeller chip by Parallax) I was thinking to modify the gcode compiler further to output pure steps to move in the 1mSec period. I was thinking there are a few advantages to this method - there are a few sources of good gcode compilers based upon the EMC code (look at code.google.com) so a lot of gcodes are implemented. The complete compiled gcode file could be stored on a sd card on the micro's board or could very easily be buffered to the micro in a few different ways from the hoast pc, personally I prefer the sd card as the system could then run without a pc.
Just my thoughts.
Andrew
Hi babinda01,
That is exactly what I want to accomplish with my code; with the exception that I don't really understand the "1mSec block" part of your comment. The link I posted above is to code that does now run some lines from point a to point b in 3 dimensions with step and direction signals from a microcontroller.
Left to do is debugging, and some means of communicating those points to the uC from the PC. I was thinking of using the minimal G1 command (is it G1? It just specifies the next waypoint) as the protocol. That would make it easy for people to understand.
You would want to add an SD card interface, but that could be done... code for the purpose is available. See the "See also:" links on this page:
techref.massmind.org/techref/mem/flash/sd.htm
Hi James,
What I am thinking, is that you don't even have to worry about ramping on your micro, all the ramps have been taken into acount in the gcode compiler, and you are just telling the micro to issue x amount of steps in this mSec, and all these blocks of steps per mSec are pre compiled to the sd card.
Andrew
Ahhh... I see... an interesting idea... I'll add a define to my code so that the part that tries to do ramping can be conditionally removed and the code would then depend on the source waypoint commands to manage ramping.
If anyone has time or desire to work on this, I'll be happy to grant editing access to the code via the (very cool) google documents sharing settings which do an excellent job of supporting multiple authors working on the same document... at the same time, even!
In that diagram, on the 4th decision point down (taking the N side each time) what is the "D" in "D<=A"? Is that DN? It doesn't seem like that would make sense... if the current rate of acceleration is more than the distance to go then we are done? But that "D" isn't mentioned anywhere else... unless it's a deformed "0"... but that wouldn't make sense either... we aren't done when acceleration is greater than 0!Originally Posted by Mariss Freimanis
You are correct, it's a typo and should have been 'DN' instead on 'D'. The test is to see if DN is less than or equal to A; if it is, make the output velocity equal to DN and set DN to zero indicating the move is done.
Mariss
Ahhh... it's actually D = Distance to go rather than DN and all those Out = 0 are actually Out = D. Errr... no because there are both D's and DN's in the chart... so just to make sure i'm understanding this: D and DN are one and the same?
Which then raises the question: What exactly does Out = # do? Does that tell the stepper to move # steps? Positive # for CW and negative # for CCW?
Posting Permissions
| | |
LinkBack URL
About LinkBacks
