[dleroi]

Robin,

Very nice work.

I've been playing with a similar idea, but took the approach of grabbing the position after it has been processed by the DRO. Your way is MUCH better. Also, buffering the signal back at the source is brilliant. It solves one of the biggest problems people have with their DROs, noise.

For faster positioning (I'm sure you've already considered this), you could do a hybrid control operation, where you use the stepper w/o feedback to get close, pause while the scale catches up, then finish with the scale providing the feedback.

May I be your US distributor?

- Don

[Robin Hewitt]

May I be your US distributor?

Of course you can, but maybe I should finish it first

I'm now writing a quick g-code interpreter and 24 bit x,y,z positioning system in machine code. I've already done it in Borland C, it's not hard. Accelerations will be much easier without having to compete with Bill Gates for the cpu timer interrupt

My brother is a computer wizard and has given me a zippy algorythm for 'next point on an arc' without square roots. Can't wait to try it out

[Mr.Chips]

This is a groundbreaking project, and rightly so it is currently focused at the electronically gifted.
Possibly after it is completed I hope it can be simplified for us among the electronically challenged.

Keep the photos and details comming.

[multiplex]

great thread!

at first i thought you mean scales as in weight, which could also be great for setting z depth? if you picked a scale that also had rs-232

Here is something that i put together along the same lines (using existing computer interfaces that is)

ibm trackpoint mouse used as an edge locater

[ame="http://www.youtube.com/watch?v=3q58oVZCmB0"]YouTube - Find Center Of Slot - Edge Probe Mach 3[/ame]

[Robin Hewitt]

Keep the photos and details comming.

Here's the pendant, haven't cased it yet...

The main board has 3 spare sockets for extra goodies like pendants and tool height detects. They all identify themselves so it doesn't matter which socket they plug in to.

Everything is RJ45 sockets and patch cords.

I thought 3 goody sockets would be enough

There's also an RJ45 plug with a serial connection in case I want to do a DRO type display and add some extra buttons.

[Noodles87]

I sure don't understand it, but sounds cool!!

Sub'd

[SPEEDRE]

This pendant, is it like hand, held type. I don't see a big dial for speed. Does this mean it can jog axis at a fixed speed? I am all but brain dead when it comes to electrics and stuff. I'm looking for a very low dollar joging pendant that will help in positioning to a zero zero home and set the Z at zero zero also. How much did this cost, can it be reproduced by a novice like me??? PM me I'm interested in learning more.

[Robin Hewitt]

I don't see a big dial for speed. Does this mean it can jog axis at a fixed speed?

I currently jog with a pop up on the screen (see pic) but it's a PITA trying to see behind the tool tip while straining to hold the mouse over a north south button.

I have an on screen speed button that toggles fast/slow, (have to be careful that the fast is not so fast that I can't stop it abruptly without losing steps because if I allowed for accelerations it would overshoot). For this pendant I thought I might pop up a window on the screen, use the green button to toggle it fast slow and the red to accept the position. Haven't got to that bit yet...

Unfortunately you neeed a pendant that will interface with your setup, this thing will only work plugged in to my box of tricks, not a lot of use to you.

Still writing Gcode interpreters. I just came up with a snappy 'find the integer hypotenuse' function for the arc radius when I get i and j. One that has minimal multiplies and doesn't involve finding 48 bit roots or any divides. Can anyone improve it?

Given the x and y offset, add one quarter of the short offset to the long offset and call it best guess at the hypot, gets it within about 4%. Calculate x squared plus y squared, square my guess and subtract it. That shows which way I'm out and leaves me the error. The difference between n squared and n+1 squared is 2n-1, a magic number that changes precisely 2 as you increment/decrement the root. I subtract that from the unsigned error until it carries and I have the hypotenuse

[CROSSHATCH]

That is really bad ass! I like your solenoid controlled probe Really cool stuff man, love the pics of the circuitry!


-Speed

[ataxy]

well now that you have one user interested in distributing your stuff in the US id be happy to do the same in Canada this is a wonderfull idea

[Robin Hewitt]

this is a wonderfull idea

The idea's okay but my brain is starting to fade. I just wasted 8 hours coding a hypot function I don't need. Got to the circle/arc drawing part and it needs the radius squared :tired:

I can use the 4% algorythm to adjust the feedrate for slopes, close enough for that

That's the USA and Canada sorted, perhaps best not to take advance orders though

What exactly does G28 do

[ataxy]

g28 as in gcode its a return to home call wich tells your machine to return to its home position

[Robin Hewitt]

g28 as in gcode its a return to home call wich tells your machine to return to its home position

Yes, but if I find...

G28 Y0

Does that mean set the home position to Y0.00, current X and Z, or, set it and go to it, or, what?

If the next line was...

X0

presumably I revert to the previous G00, G01, G02, G03 or drill position whichever came last, because G28 is in a different modal group, probably

The definitions I can find are so vague I forsee problems with this. Best keep the gcode interpreter very open ended and easy to tweak. Fortunately I have distributors who can find the bugs

[ataxy]

yes then it is g28 return to home as y0 and then x0 some program will often only do g28 z0 as to tell the machine to rise its head for the tool change

[Robin Hewitt]

Wow, now I come to write it, this is one weird stepper driver

I do my best programming when I'm out walking the dogs at lunchtime, have to be away from the keyboard so I can get my ideas straight. Here's a progress update

There is a worry because the tool position must be allowed to get ahead of the scales. The scales only report 50 times a second and I need to step faster than that. If it gets ahead it has to make quick decisions. If the scales disagree with the screws, the assumed tool location suddenly changes under my feet.

What to do if the tool grabs and the updated position from the scale overshoots beyond where we are prepared to go? I think the answer is that I only become anal about the scale position for the final light pass, I am more forgiving while roughing out and I don't care about a G0 until it gets to the end of it.

Tight Gibbs should help. Backlash correction is, of course, totally automatic. I may insist that the X and Y axes have approximately the same step resolution. (No need to tell me the step resolution, I can measure it).

With the scales resolving .005mm (.0002") I still get one count of jitter. Don't want to slam a fast moving stepper in to reverse just because it sees a slight jitter. Very happy to tweak a minor axis though.

I have a cunning plan that allows the processor to unpack the gcode and run about 30,000 steps ahead of reality without losing track of where it actually is. If the mill has an oops requiring operator assistance, I want to be able to back track real easy.

I reckon full speed on all 3 steppers is around 6000 steps per second and I should allow for twice that to get a good safety margin. There's simply no time for complex maths when it's deciding which way to leap or whether to stay put.

I'm stepping in sequence so no two drivers switch at precisely the same moment and I allow one step delay for the direction line to settle before moving. Probably unnecessary but comfortably reassuring

[Robin Hewitt]

PS: Just thinking about the G0. I can wind the speed up until the motor starts to lose steps then back off a bit so it goes as quickly as possible. That sounds like real fun, I'll enjoy doing that bit

[Robin Hewitt]

Been a while so thought I'd do a quick update

I was writing a g-code reader and it was becoming unwieldy so I've junked it and started over doing it with look up tables and structures.

You now feed it raw g-code, byte at a time. The input character goes straight to a 128 word lookup table, covering the entire ASCII character set, and it instantly knows exactly what to do.

Doing it this way makes it totally expandable without risk of turning it in to a garbled, hard to understand, bug-ridden mess.

What comes out the other end of my new g-code engine is a concise list of instructions for everything it can do and error messages for everything it can't.

If you haven't guessed, I'm rather pleased with it

[Oldmanandhistoy]

I wish I had something useful to say but I don't other than nice one, keep up the excellent work and keep us posted please.

John

[eightball]

Robin, I'd love to hear some more updates/progress on the system you're working on

[mikehg1]

Is that some type of universal proto board ? Seems like a LOT of connectors on there!
I did about the same for my mill just for the readout. I used an 8pin AVR chip for each one that did away with the need for any extra circuitry for reading the signal. The AVR has a built in analog comp with a 1.1V ref available, works like a charm!

I just soldered the wire connections directly on mine, but have been meaning to make some real plug-in connectors since I now have PCB making capabilities.