[aubrey]

take a look at www.dynomotion.com
.... is based on the EMC (www.linuxcnc.org) interpreter ....
.... which runs on realtime linux (=predictable timing)....

Hey Andy

There are many commercially available systems out there which are pretty decent (and a number which are not). I think the idea should be to make a "FREE" alternative that will solve the problems.

Does anyone know what language (perl or whatever) the EMC app is written in?

To solve the timing problem, even EMC has to run on a special tweaked version of Linux.

Can anyone imagine Bill Gates giving us access to the M$ source so that we can tweak it? Not in my lifetime!

[andy55]

nice work,

I presume you mean MHz.

what kind of trajectory profiles does it generate ? acceleration, jerk, or doublejerk-limited ?
for how many axes ?

what about blending/lookahead i.e. if two segments are in the same direction there is no need to slow down in-between.

is yor controller open-loop or closed loop ? (I presume open loop, so not for servo systems).

[CLaNZeR]

Yes Andy MHz! or megacycle per second in ancient nomenclature.

As far as ramping rate you choose because it is easy enough to do a inceremental pause between steps.

At the end of the day, it is not complicated to clock a Step line on any controller..
Take a pin high on the pic chip that is linked to the Step input of any Axis, chuck a pause in and then take it low.
Depending on what the pause is, determines the speed at which the motors will turn.
Take the Direction pin high or low will determine which way the motor spins.

So for ramping simply start off with a longer pause for a set travel and decrease the pause until the correct speed is obtained and when the set length of travel is reached.

How you now control those steps and pauses is down to the Pic code and how it interprets the Gcode it is being fed.

Hopefully your program that has already generated the Gcode will of taken most of the important stuff into account and produced optimised code.

Like I said I have played around with the simple G00 and G01 codes in my firmware and all you are doing is very simple stepping.

Example to control 3 axis.

Set your variables for the X,Y and Z Axis position.

Grab your first line of Gcode that says G01 X100.00 Y050.00 Z010.00

Load your feedrate pause based on 3-Axis moving at same time.

Start your loop
Check X position if it equal to 100.000 position in Gcode command then divide down pause.
If not then Clock your step on the X-Axis and pause.

Check Y position if it equal 050.000 to position in Gcode command then divide down pause.
If not then Clock your step on the X-Axis and pause.

Check Z position if it equal to 010.000 position in Gcode command then divide down pause.
If not then Clock your step on the X-Axis pause.

Do loop again until all Axis equal same as Gcode command.

Of course also between each step you have to check for limit switches and emergency stop, but this can be done with interupts.

This will then move all 3 Axis as smooth as anything and all in sync with out loosing a step.

As you can see in the example above you can easly add ramping by dividing down the pause based upon the correct calculations at a higher pause for the feed rate.

My controller is based around steppers and is cheaper than $900 dollars for a DSP controller, even though the DSP has nice motor controllers built in on it!

Regards

Sean.

[slp_prlzys]

Here's something I found last year,
can't remember where, I think it's
from a University archive somewhere.
Perhaps knowledgeable Zoner's may
find it interesting. Only XY tho.
It's a pdf file but I had to zip it
to reduce file size even a bit,
I'm on dial-up so there's a slight chance
that it get corrupted during upload.

[CLaNZeR]

Excellent slp_prlzys

Especially like the Circular Interpolation bit, just what I been looking for.

Many thanks

Regards

Sean.

Here's something I found last year,
can't remember where, I think it's
from a University archive somewhere.
Perhaps knowledgeable Zoner's may
find it interesting. Only XY tho.
It's a pdf file but I had to zip it
to reduce file size even a bit,
I'm on dial-up so there's a slight chance
that it get corrupted during upload.

[ger21]

Why don't you just write a front end for Gecko's G100 (G-Rex). It has all the motion routines built in. 6 axis, 4 million steps/sec, lots of inputs and outputs. I think Mariss is trying to make it very easy for someone to create such a front end. There's a lot of info on the Geckodrive Yahoo group.

[aubrey]

Why don't you just write a front end for Gecko's G100 (G-Rex). It has all the motion routines built in. 6 axis, 4 million steps/sec, lots of inputs and outputs. I think Mariss is trying to make it very easy for someone to create such a front end. There's a lot of info on the Geckodrive Yahoo group.

Hi Gerry,
Begs the question "Why hasnt someone done it yet?"
Also, still relies on the timing being triggered by the M$ PC from what I can see.
Best
Aubrey

[ger21]

Hi Gerry,
Begs the question "Why hasnt someone done it yet?"
Also, still relies on the timing being triggered by the M$ PC from what I can see.
Best
Aubrey

The G100 won't be available for another week or two, although you can purchase it in 2 piece form right now (see the website).
There are alpha versions of Mach4 available that can run it right now. Not sure about the timing, but I think it's controlled by the G100.

[aubrey]

Sorry Guys - Duplicated Submission

[mdreitzusa]

aubey,
did you look at the development boards or the control boards.they are module based for fast prototyping.they have memory and realtime clock onboard.could the onboard clock be used to overcome the windows delay problem.

[aubrey]

Time to lay it out so that everyone can see what I am getting at.

Givens:
1) Both Micro$oft and to a lesser extent, Linux, operating systems to a lesser or greater degree do not always set the port pins at the exact moment that the application wants them to.
2) EMC has to be loaded on an optimised OS installation but with Micro$oft there are no other options.
3) Eratic timing can cause skipped steps, tool gouging and a host of other problems which can mean wasted money when looking at our time, effort, doctors bills for high blood pressure and material cost of the workpiece.

It is also accepted that :
1) There are a number of solutions out there that overcome (to a greater or lesser degree) the problem. Unfortunately, most of them cost money.
2) There are a number of ways to overcome this problem but as a hobbiest, I would like to be able to say that I was a member of the GROUP that came up with this particular solution AND THE DARN THING WORKS WELL!

For the purpose of getting clarity on where I am comming from and what I think our goal should be, the attached document should help.

The thinking is as follows:
1) As everyone has thier own preference as to CAD Packages, this wheel does not have to be re-invented. We will use the GCode output from the CAD Package as the source.
2) The GCode generated by the CAD Package will be retrieved by our StepMaker software and computed to a string of 2 letter words which will be stored to a pre-processed file on the disk drive. This step is necessary especially for those who have slower computers in thier workshop. Some of the G02 and G03 commands may take the PC longer to step calculate which could mean that the mill will have finished the previous steps before the PC has calculated where the next step/s are to take it. This "Buffer Underrun" scenario could also be the reason for erratic or problematic behavior on some mills.

As the pre-processed file contains no itterations or loops, it may be massive.
Imagine if you were to store each step command that is sent to your mill when you run your favorite GCode file. This is EXACTLY what the pre-processed file contains!

3) Now we take the pre-processed step instruction file and run it through the breakout board feeder application. The Feeder App sequentially reads the file from start to finish and sends it to the breakout board. There will of course have to be protocols set up so that the breakout board can pause the stream so that an overrun situation is prevented.

Now, What happens in the Breakout Board?

First lets look at our 2 byte "word".
If we put them one behind the other, we effectively have a bitstring 16 bits long.
Using the first 2 bits, we have 4 options available. ie. 00, 01, 10, 11

Assume that process branching happens as follows:

00 = output the last 10 bits to the motor driver pins (assuming 5 motors with step and direction)

01 = output the last 4 bits to the auxiliary relay pins (assuming 4 relays with on/off capabilities)

10 = "Canned Procedures". Here we can zero any axis, change timing rate for steps to be sent to the motors or anything else that we may decide to incorporate into the software design.

11 = "Send to LCD Display" ie. "1100000000000000" should clear the LCD Display, "110000000100000" should put the character "A" on the LCD.

Now, what does the board do?
PIC1 is busy listening for traffic on the connection to the PC.
The first thing it gets is a command which it interprets as "Is it OK to Start?"
PIC1 resets the board and starts receiving the data and storing it to the memory chips (4 in my drawing)
When the last memory is full (or the end of transmission flag received from the PC), PIC2 is told to start.
PIC2 queries PIC3 for the address of the next (in this case, first, command)
When PIC3 receives a memory location request from PIC2, the location is returned to PIC2 and the next memory location pointer is incremented in PIC3.
If the next memory location is on the next memory chip, PIC3 signals PIC1 to re-fill the memory chip that has just been finished.
In the meantime, PIC2 has retrieved the word from the memory location and processes it.
PIC2 then waits for the timing pulse and executes the command.
When the command has been executed, PIC2 queries PIC3 for the location of the next command and the whole process starts again.

You will notice a number of PICs in the drawing apart from PIC1,2 and 3. my thoughts are that a small (<$2.00) PIC is an easier way to impliment PWM and all the other good stuff than complicated boards. Want to change the way it reacts, change the program - infinite possibilities!

Comments Please

Best

Aubrey

[aubrey]

Lets try the attachment again - Sorry ;>{

[HuFlungDung]

Aubrey,
A lot of what you are talking about is over my head.

I do wonder if you are over-simplifying the requirements of a real machine in operation. Acceleration and deceleration are not performed in gcode. Feedrate override is going to wreak havoc with what you have already fed into the buffer. Feedhold, Estop, same problem. You will want to be able to pause the program at any instant, then recover and continue. Because these events all happen on the fly, they cannot be anticipated within a fully processed program path.

How about execution of one line of gcode per input? This involves Windows quite a bit.

Just add these to your list of things to do. But, carry on

[aubrey]

Aubrey,
A lot of what you are talking about is over my head.

....Acceleration and deceleration are not performed in gcode....

Point taken - how are they handled currently?
I assume that they are handled within a specific GCode Command.
Also, does the Accelleration/Deceleration apply to ALL GCodes or only to the rapid movement commands?

Feedrate override is going to wreak havoc with what you have already fed into the buffer. Feedhold, Estop, same problem. You will want to be able to pause the program at any instant, then recover and continue. Because these events all happen on the fly, they cannot be anticipated within a fully processed program path.....

If you look on the document, you'll probably notice an alarming abscence of a keypad! One will be needed!
If a wait for user intervention is required, all we need is a "Canned Command" that will pause PIC2 untill the operator has changed the tool or done whatever is needed.

How about execution of one line of gcode per input? This involves Windows quite a bit......

If the PIC has to do all the calculations, in my opinion the situation will arise that the next step needs to be sent to the driver boards but the PIC has not yet worked out what the next step is. This will probably be just as bad as missing a step.

Just add these to your list of things to do. But, carry on

Thanks (I think!) Please remember that this is not "My" project. If it was, it would be a non-starter because I definitely do not have anywhere near the expertise in all the required areas to pull it off. It will have to be a group effort if it had any chance to see the light of day.

But if it does....... It will be a great little achievement.

[ESjaavik]

Aubrey wrote: We are dealing with the Micro$oft Window$ operating system.
Then 2 sentences later:
2. Come up with a solution to ensure that we, the humans, are not to be screwed around by the shortcomings of the operating system

I'm sorry to chant "Linux", but really cannot see any other choice without shelling out lots of money for a realtime system with expensive compilers and tools.

Some of you want to be part of a group with a better solution. There is such a group, you just have to join it: The Enhanced Machine Controller, or EMC.

The low level parts of EMC is written in C. That is: hardware I/O, stepping/servoloop, trajectory planning, kinematics, interpretation of G-code and low level execution of operator I/O, lots more. The user interface is written in other languages as far as I know.

It relies on RTAI for realtime service. RTAI is extensively used also in commercial controllers and PLC's and is well debugged and of course source is available for it. Do not underestimate the complexity of writing a realtime kernel or scheduler from scratch. It will be needed also for a microcontroller or things will get even more complicated. Realtime means actions will be executed to well defined time limits, it does not necessarily mean these time limits will be very small. So there is a limit for how many steps/sec a certain hardware can deal with regardless of software design.

If you need more speed than the PC hardware can provide, EMC have solutions to this: Use a hardware step generator made up from a programmable gate array, EMC has open and well defined software interfaces to make this simple. (I went to this solution to gain the speed I wanted). Or you can choose a hardware that controls servo motors equally easy. The drivers for these have already been written, so you just pick one that suits you. Should your requirements not be fulfilled by an existing hardware/driver, you can write your own. It will be a fraction of the work writing everything yourself, and you will all along benefit from the work other people do at other levels of the software.

I think you should only reinvent the wheel if there are only square or too expensive wheels existing. So I suggest you look closely at EMC to see if it will not be quite close to what you need.

OK, so I'm biased since I run EMC and have a good performer for a really low price. The PC running it would otherwise have been in the dumpster long ago, and the mentioned hardware cost me just over $100, and can do 300 000 steps/sec if I ever find drives that can swallow them that fast.

Einar

[slp_prlzys]

CLaNZeR:
You might also be interested in this too.
http://www.khwarzimic.org/takveen/helix.pdf
I was going to post the pdf itself but better from
the source.

[aubrey]

CLaNZeR:
You might also be interested in this too.
http://www.khwarzimic.org/takveen/helix.pdf
I was going to post the pdf itself but better from
the source.

NICE!
We will definitely refer back to this later in the project.
Aubrey

[aubrey]

Hi Einar,
I was waiting for one of the Linux converts to pick up on this discussion!

I'm sorry to chant "Linux", but really cannot see any other choice without shelling out lots of money for a realtime system with expensive compilers and tools.

Don't get me wrong, what you are saying is true IF you are comfortable with the Linux platform.
Personally, I am not.
I have tried to install Linux from way back, Early Red Hat, Suise 6, Fedora - the EMC "BrainDead" install and on and on.... NEVER got it right :tired:

As to the cost issue, Yes it will be more costly to get it going on a Micro$oft platform, no arguements there!!!

But if the enthusiast is NOT an IT fundi and does not have an intimate personal relationship with the Linux OS, there are also other "costs" to be considered:
1) Frustration in trying to get your Linux based PC working properly in the first place. This has always been my own biggest headache with any Linux OS install that I have tried.
2) This "frustration" then takes the enthusiast down the M$ Window$ route simply because they probably already have a Window$ based PC at home or if they are prepared to continually reboot, the MS-DOS route for the CAM functionality.
3) The choice of CAD software is very much a personal one and the majority of choice lies in the Window$ platform range. Some very good - some very bad, some expensive and some free. The choice is up to the individual.

I would not like to know how many folk have simply chucked the CNC hobby because of the cost in time and money to get them to where the REALLY want to be - watching thier (probably home built) CNC Mill machine some component that they have spent hours designing.

Have a look thru the threads on this site and count the number of folk looking for solutions to broken tools, gouged workpieces and bad finishes. I have seen a number of them.

The low level parts of EMC is written in C. That is: hardware I/O, stepping/servoloop, trajectory planning, kinematics, interpretation of G-code and low level execution of operator I/O, lots more. The user interface is written in other languages as far as I know.

OK - as it is open source, we have somewhere to go to see how others do it and either "borrow" some of the routines as is or make the necessary adjustments to suite our purpose. As long as the results are also free to the public, where is the harm?
And if our group effort makes a solution that WORKS, even if it costs a couple of hundred Dollars, and we save one person from walking away from the hobby, I personally thing it would have been worth it!

As an aside: a large majority of the members of this forum earn thier income in US$. There are some of us that don't. When we see a price tag of US$100.00 we go into shock as it equates to a LOT of money in our local currency.

I think you should only reinvent the wheel if there are only square or too expensive wheels existing.

Don't you just love the human race? They are always trying to invent a "BETTER MOUSETRAP".

So I suggest you look closely at EMC to see if it will not be quite close to what you need.
OK, so I'm biased since I run EMC and have a good performer for a really low price. The PC running it would otherwise have been in the dumpster long ago, and the mentioned hardware cost me just over $100, and can do 300 000 steps/sec if I ever find drives that can swallow them that fast.

One of the original definition parmaters that I put forward was that this project would be Micro$oft Window$ based. Why? Most of us are more comfortable with Window$ than with Linux.

I am not saying that the EMC/Linux solution is inferior or bad. On the contrary, it is probably the best solution available at this moment. But not for many of us out there!

What we need is a way to take the output from our favorite (Window$ based) CAD application and make our (proudly home built) mill cut our parts from blocks of raw material without the problems that are inherently encountered when using Window$.

Best
Aubrey

[ESjaavik]

I have tried to install Linux from way back, Early Red Hat, Suise 6, Fedora - the EMC "BrainDead" install and on and on.... NEVER got it right :tired:

OK. I know how you feel as I also installed Linux and had many fights before giving up. That was also "way back". But installing BDI RC46 was so easy I could not believe it. Boot CD, click on install to hard disk, answer a few questions, then leave it until done. More recently I installed Linux on another machine, this time a video surveillance (ZoneMinder) and the same again, a few questions first, then it did the rest by itself. No need to babysit waiting for new questions, reboots, install umpteen "security patches" and licenses. And no, I'm not a Linux freak, I install it where it is required for the job at hand.

But OK, I just thought you wanted to see the chips flying as soon as possible. Did not mean to start a religious war.
But the EMC source will surely be a good resource if building on another system. The source can be loaded and viewed in Windows.

[aubrey]

Did not mean to start a religious war.

Don't worry, no offence taken!
I use windows all day every day and roundly curse it (flame2) at least every hour.
Funny thing about democracy... Its the only "system" that by definition, allows other "systems" to also be acceptable.
Best