Topics

1

General Mach Discussion / Mach control computer & integrated video

« on: December 29, 2008, 01:19:34 PM »

What's the smallest computer form factor reasonable for use as a Mach controller?

I've got a couple of ongoing Mach projects (don't we all?). For each I'd like to piece together an inexpensive embedded PC. The selection is a balance of cost, size and performance. The affect of integrated video has been the hardest for me to gather info on so far.  I've read rumors of success and tales of caution with few details.

Evidently, there are issues with Mach if the motherboard uses shared system memory for integrated video.

The MicroATX based computers are most appealing to me. I've pieced together a BOM for a more-than-decent system for ~ $200. Playing it safe and assuming a separate video card increased expense and size. Expense increased by about ~$50 for the video card (and 90° riser card). Size and hassle of dealing with a whole additional card is a big deal for an embedded system.   

There are some very attractive deals for “bare bones” DIY microATX systems that could be a great resource to all of us -- if only there were a way to definitively know the compatibility of a motherboards integrated video.

Some questions and issues that came up during my component selection:
- Is a less-expensive PCI video card sufficient or should these be avoided in favor of AGP?
- Is it possible to identify the video memory sharing strategy employed by a motherboard?
  (does knowing the motherboard’s chipset help?)
 
 I'll compile and summarize any results if the response and interest is sufficient.

- Ted

PS.   ... trying to figure out how to cleanly attach my current working BOM

2

General Mach Discussion / G43 BREAKING TOOLS

« on: January 20, 2008, 08:35:35 PM »

I found this topic investigating some unexpected G43 behavior after "upgrading" from a previous version of Mach3.
I decided to start a new thread....

It appears that "T# M6 G43 T#" does not change the DRO offset as I expect it to.
(I expect it to change the DRO to reflect the height offset value without moving the machine)

G43 SOMETIMES moves the machine Z axis. (I've broken several tools and ruined parts because of this.)
In this "sometimes" mode repeatedly issuing G43 (tested with the MDI) repeatedly moves the machine Z axis.
Sometimes appears to be:
   if current tool <> tool specified in "T# M6 G43 H#"
       Then machine does not move (offset changed in DRO)
   if Current tool = tool specified in "T# M6 G43 H#"
       Then Machine moves Z axis by offset of H

?!?!?

My post always issues the tool change like this:
T# M6 (apparently does nothing except change the Tool # display)
G43 H# (Tool height offset is applied to DRO (or the Machine Z axis is moved) at this command)

But why wasn't this ever a problem before in Mach2 or the previous version of Mach3 (Current 3.00)
The Z axis never moved when a tool offset was issued. See below from UsingMach3Mill

3

General Mach Discussion / Mach3: Use number keys to enter numbers???

« on: September 20, 2007, 05:18:34 AM »

Np Ted,
   

Is it possible to enter numbers in Mach 3 using the keyboard's number keys?

Do you mean in a dro? Hmmmmmmmmmm not sure if you don't have a mouse. I just click in the DRO, type the number and hit enter. I can't remember trying it any other way. 

Brett

No, I mean, I'd like to use my number keys on the keyboard to enter numbers as opposed to the pop-up mouse number pad. Mice don't work well next to milling machines for so many reasons.

-Ted

4

General Mach Discussion / Mach 2 reinstall issues

« on: September 19, 2007, 05:20:07 AM »

I'm having some problems after re-installing the latest Mach2r6.11n software.

Currently, Jog only moves at 27ipm no matter of override (shift held down) or any slow jog percentage value.
This corresponds to a motor max speed of 1.5in/sec (as set in motor tuning).
Jog speed does goes up/down as max motor speed tune parameter increases/decreases.

Any clues?

This is after installing and then un-installing Mach3
I just want to return to my last good working state.

5

General Mach Discussion / Accurate homing

« on: August 20, 2007, 12:35:00 AM »

Ok I've started a new topic as I bogged the last one down in tangents.

I'd like to brainstorm methods to enable Mach to accurately maintain home position. I believe this is a noble cause. Doing so would lower the bar for accurate custom-built-machines even more. Also, I like Mach and would like to keep using it. Currently my lack in confidence at maintaining an accurate home is bringing me very close to abandoning Mach. This is because e-stop and Limit events are very common, and after which Mach requires re-homing.

Requirement: The only time a CAM system (without absolute positioning) should require homing is at power up, after a motor drive failure, or when the operator decides it's necessary (after a crash). 

I think there are three VIABLE philosophies one could adopt when building a system:
 1) Continuous absolute feedback. (Many (most all?) modern professional systems do this)
      Homing mechanism: n/a
 2) Continuous incremental feedback.
      Homing mechanism: Accurate as the system builder wants it to be (mechanical switch, encoder index pulse...)
 3) Open loop system. (risk of error decreases as the system is driven at a smaller % of max operating conditions)
      Homing mechanism: same as #2 

Mach doesn't currently support any of these options. I'm not putting Mach in catagory #3 because because #3 systems have been around for at least 10+ years (pretty sure 30+ years). AHHA systems, for example, don't loose home with e-stop or limit events. Now that I think about it, from my experience, Mach is the ONLY system I've seen with the capability to control professional systems that DOES require homing after an e-stop or limit event.

Re-homing is risky and takes time.
In opinion, e-stop and limit events are so common that they should not be allowed to compromise work quality or productivity.


Now to the actual brainstorming...


So there are really two homing issue that I've dealt with while building my own machine: Mach's action during error states (discussed above), and accurate homing mechanisms. The more accurate the homing mechanism is, the less risky Mach's behavior becomes.

So I can only try to make an accurate homing mechanism while I wait and hope that Mach changes the way it handles e-stops and limits differently.

If the system has encoder feedback then Mach has the capacity to be close to #2 (above), correct?
 - Wire the encoders into Mach for DRO feeback
 - If servo driven, then the servo driver signals Mach in the case of a drive error.
 - If using steppers + encoders then use a board like the one sold by rogersmachine.net to signal drive error.
 - Home machine.
 - Any time after homing, one could then copy the encoder DRO values to the machine DRO fields.
(Are e-stops and limit events interrupts? --Are encoder DRO values guaranteed consistent across these events?)

Accurate homing. There are few mechanical switches that I'd trust. Even if an optical switch is fully enclosed, a discontinuous mechanical interface still has the capacity to get crud caught in it.

The best way to home IMHO is to use and encoders index pulse. The board from http://www.cncbuildingblocks.com/homeindex.html looks like a great solution for interfacing index pulses with Mach. It hides the home signal from Mach until it found the index pulse by generating it's own pulses. (Not sure I'd use this system with glass scales as I'm not certain how it would handle backlash).

I'm still not clear why Mach can't "see" an index pulse (it shouldn't be any harder than an encoder pulse).

Comments? Any more ideas?

-Ted

6

General Mach Discussion / Frustration! Accurate homing? Encoder index pulse?

« on: August 11, 2007, 05:34:57 AM »

Hey there, this is, in part, a "Hi" post after a long hiatus. I've been using Mach2 for ~2.5 years now on my converted Bridgeport.
(1979 CNC model with ball screws and pumpkin steppers)

I've had an on-going issue with homing my machine. I'd like to home with +/-0.001" or better accuracy.
My conclusion is that mechanical switches just don't cut it.

This is an issue because re-homing the machine in the middle of a setup is a fact of life for various reasons:
 - Many of setups span several days and the machine gets power-cycled
 - E-stop doesn't do a controlled stop.
 - Things happen.

I'm considering adding glass scale encoders to the table but I'm wondering what Mach2 actually does with the encoder inputs.
- Are the inputs purely for operator DRO feedback?
- I know Mach doesn't do motor loop feedback but I'd think that an "expected" vs "actual" count error check would have surfaced by now.
- Are there homing routines out there written to locate an encoder's index pulse?
- Are Mach's encoder DRO counters interrupted by E-stop too?

I have to admit that I'm getting a little frustrated. I've scrapped a lot of work due to homing issues. All professional CNC machines that I've used simply never loose home (even after running into limits or hitting the E-stop button). I recognize this is an inherent drawback of open-loop control but on a sub-system level, all machines (open or closed loop) have to deal with this issue in some way.

I plan to eventually swap the steppers for servos. At least then the servo drives can provide an error feedback. But accurate homing is still required.

Suggestions?

Thanks, Ted

Ps, Would anyone be interested in a separate thread about my super-simple hall sensor spindle index?