[Noisebridge-discuss] getting that goddamned mill to work

[Michael Wright]

I think Jon pretty much summed it up.

We've got it to work as well as can be done using the UI on EMC2.  It  
looks like the EMC2 HAL (hardware abstraction layer) allows for making  
pretty significant changes to the motor signaling (Seph basically  
changed everything of how EMC2 talks to make it use 4 pins per motor  
to control the MaxNC10OL), we have the MaxNC10CL (closed loop) so we'd  
have to do slightly less work to make it do quadrature on 2 pins per  
motor.  This would be a pure software hacking adventure, probably most  
of the work could be done using EMC2 on a VM on a laptop, with final  
testing requiring a real machine and the mill.

I've downloaded and played with Mach3 demo-ware in a VM.  It actually  
has a menu option for MaxNC CL mode.  This along with the other things  
I've read makes me think it will work.  If it's possible to believe,  
it actually looks more esoteric and harder to use than EMC2 (at least  
for someone who doesn't know CAM yet).  That said if it makes the mill  
work, someone can make an instructable on how to do CAM.  The demo of  
Mach3 allows 500 lines of Gcode, the licensed version allows 10,000  
and costs $175.  My plan is to arrive with a windows 2k hard drive and  
put it in one of the three boxes (2 compaqs from Dr. J plus one from  
Jonathan L).  If that works, then it works and other hacking can be  
done for fun rather than "necessity".

In terms of other hacking for fun, I'm thinking it would be pretty  
easy to make an Arduino/Sanguino based 4 knob control box that  
converts the perfectly good CNC mill into a functional power-feed only  
manual mill.  For the kinds of one-off things I tend to do, having  
direct control is nice (plus the learning curve is lower).

The important things we learned in EMC2:

If you have the enable pins set correctly the mill humms at about 10  
khz (actually all 3 stepper motors)
If you have the enable pins set correctly any one of the steppers will  
resist externally applied torque
If the steppers don't behave closed loop (hum and resist torque),  
something's not enable and no other testing has any chance of success
Spindle is pin 1, inverted, it pwm's fine (if not set inverted it runs  
by default, which I don't recommend)
The spindle may not be affected by the enable pins (needs more testing)

Here's the pin config that made the most sense (and made controllable  
noise)

outputs:
1 Spindle PWM  Invert Checked
2 A Step
3 A Dir
4 Y Step
5 Y Dir
6 X Step
7 X Dir
8 Z Step
9 Z Dir
14 ESTOP Out  Invert Checked
16 ESTOP Out
17 ESTOP Out  Invert Checked

Inputs
10 All Limits
11 Unused
12 Unused
13 Unused
15 Unused

On Oct 2, 2009, at 10:48 AM, Jonathan Foote wrote:

> I don't think jitter is an issue. On the worst machine last night it
> was less than 25 us. Mike's borrowed machine got it down to less than
> 5 (thanks for bringing that in, Mike!)
>
> Seeing as how the actual stepper pulses are generated by 4 Mhz PICs, I
> think we are, if anything running too fast.
>
> But we made some progress, we got the spindle motor PWM working, and
> found magic enable pins. We can enable the stepper feedback so they
> will fight you if you try turning them out of position, and I'm pretty
> sure we're giving them drive signals because we can hear them whine.
> But they still don't move.
>
> I think the final hurdle is generating true quadrature drive signals
> rather than step + direction. This is an easy hardware hack (two
> flip-flops and some logic should do it), or we could improve the
> open-source EMC2 code to generate the signals we need. The hardware
> solution strikes me as much easier than mucking about in the guts of
> that Linux port driver, but I could be convinced otherwise, especially
> if there's anyone else on the planet with a similar problem. (Is
> anyone on the EMC2 list/forum/IRC that could ask?)
>
> I think the next step is testing that hypothesis by feeding one axis
> some true quadrature signals from hardware. I have some AVR code to do
> just that.
>
>
> OK, enough hacking, back to the drama.
>
> -J
>
>
> On Fri, Oct 2, 2009 at 10:13 AM, Andy Isaacson <adi at hexapodia.org>  
> wrote:
>> On Thu, Oct 01, 2009 at 11:56:29PM -0700, Jesse Welz wrote:
>>> 2009/10/1 dpc <weasel at meer.net>:
>>>> Michael Wright <mike at smallip.com> writes:
>>>>
>>>>> After running the Jitter-Test program on the computer I have the
>>>>> sinking suspicion that the machine we're trying to use isn't good
>>>>> enough to send step and direction commands.
>>>>
>>>> hmmm.... i never got around to schleping down the machine for the
>>>> reversing stuff but just noticed it has a prallel port. how good is
>>>> good enough?
>>
>>
>> The problem is that some low-end computers from about 1998 to 2003  
>> (and
>> some up to the current day) use SMI mode (System Management  
>> Interrupt)
>> to do stuff on the CPU without letting the OS know about it.  This  
>> means
>> that at any moment your code may stop executing for up to a few  
>> hundred
>> microseconds -- plenty long enough to totally hose a PWM or stepper
>> motor pulse sequence.
>>
>> The motherboard I last saw being used for the mill was a Via Eden  
>> CPU,
>> which is known to potentially have such issues.
>>
>> Most "real" AMD or Intel CPUs' motherboards don't have these issues,
>> although it's not guaranteed (it depends on the BIOS and system  
>> vendor,
>> and laptops are also known for having such problems), so check for a
>> better mobo -- I know I saw a few in the E-Waste pile.
>>
>> -andy
>> _______________________________________________
>> Noisebridge-discuss mailing list
>> Noisebridge-discuss at lists.noisebridge.net
>> https://www.noisebridge.net/mailman/listinfo/noisebridge-discuss
>>
> _______________________________________________
> Noisebridge-discuss mailing list
> Noisebridge-discuss at lists.noisebridge.net
> https://www.noisebridge.net/mailman/listinfo/noisebridge-discuss