250ipm = 4.16r"/sec
For mach3, that means 0.416" / macropump, script or brain loop..... there is a chance that it may fly right past a switch. (10hz loop frequency)
Mach4 has an adjustable (you can change it) loop frequency which is set within the screenset by editing the screenset, and its 50hz (note this does require a motion controller to pass information back to mach4 at the desired speed, default data transfer loop on the Ethernet Smooth Stepper is 40Hz (adjustable) for processing / action. I don't know what the parallel port speed is in Mach4 at passing info back and forth, and the other motion controllers would require some exploration from their respective manufacturers that are supporting Mach4 (PMDX, Vital Systems & CSLabs and PoLabs are the only others I know of, but may not be up to speed)
hence your z could travel 0.083r"/loop before being detected by the loop (which is good) as I'd suggest you really want some sort of debounce to confirm that the switch has changed state to prevent potential noise or false triggering), ie you need the loop to pass twice to confirm that the switch has changed state (or internal filtering in the motion controller)
Not sure about the use of the glass encoder and how you would set limits, they would be better than a switch as it may be possible via algorithm (code or equation) to write a predictive script that would not only say where the z axis is at this time, but where its likely to be on the next loop, hence prepare to stop the z axis at just the right moment (you also need to allow for some amount of deceleration). The equation that would work best would be a Kalman controls equation, although its rather complex (to me) and its used in many avenues such as radar and other interesting things (quadcopters / gyroscopes is another on occasion), it allows the equation to use the last position to calculate for the next expected position and a degree of noise it is self correcting (hence think about a plane or missile) and providing the velocity remains the same (whether constant, accelerating or decelerating) it allows for state. It would be interesting to try to implement in cnc, but is probably not required as all that tends to happen in cnc is the limit switch is tripped, the device is stopped, either allowing for some deceleration and the position is estimated, or its backed up off the switch and then the position is also estimated with a smaller error.
If someone is interested there is info on the Kalman equation here which is well written.
http://bilgin.esme.org/BitsAndBytes/KalmanFilterforDummieshttp://www.bzarg.com/p/how-a-kalman-filter-works-in-pictures/There appears to also be some lua script that may be able to be Mach4 adapted maybe...
https://www.google.co.uk/search?q=kalman+lua&ie=utf-8&oe=utf-8&gws_rd=cr&ei=X4oqV9f3EYzNgAaguI7YDAAn alternative which is sometimes used is complementary filter which is a little easier to understand.
Note this is looking at the use of glass encoders, given they can provide you with the current position, velocity and change in velocity all of which is way more useful information (that is not utilised in cnc other than position) than just a limit switch which would probably work just fine for whatever accuracy you are looking for.
Mach4 is motion controller dependant, hence you need a clear understanding of what you require and what functions the manufacturers support. A suggestion would be, maybe gather a list of the mach4 gcodes and mcodes together in an excel spreadsheet, with a tick box next to each, along with some background questions such as how frequently does the motion controller send information back and forth to Mach4 (as if its preset and non adjustable at 10hz.... its no benefit over Mach3), number of inputs and outputs, any analogue inputs (or outputs).... not that they are common place / used much, and confirmation of the use of M62 & M63 (not in the M4 manual last I checked) as they may be useful to trigger things later without hesitation, along with homing and probing functions (as they are internal to the motion controller and are not done in the PC / Mach4)
Personal experience.... product manufacturers are not very good at stating what a product cannot do (negative aspects are not perceived as product merits), hence saying it works with M4 is very common.... but asking what doesn't work is sometimes met with silence.... hence a direct question "does this function work or not?" will then require them to explicitly lie which is harder to do than a cover all statement "its M4 compatible" / "works with M4".
Buying an M4 motion controller to later find that it does not do what you want it to (or some specific function) can be disappointing if the product is not being supported by timely updates to correct deficiencies or follow the improving development cycle of new M4 updates being released (where occasional updates have reported working functions in motion controllers to now stop working for whatever reason).
Guest
Show Posts