I am writing my own machine controller from scratch, which I am doing for two reasons:
1. To fill the gap between GRBL/Smoothie/other microcontroller based machine controllers and LinuxCNC. I have a working prototype and I intend to opensource everything when it's fully matured. You can see the controller and firmware in action here: http://youtu.be/qasLhuJFZNU 2. To better understand how machine controllers work in its entirety and become a contributor to the LinuxCNC project. Writing a machine controller from scratch would give me the depth of knowledge to make positive contributions. I am also currently doing a deep read reading through the developer manuals. The machines I work with primarily employ non-trivial kinematics, so homing is absolutely essential to get right. Right now my machine can't home to (0,0,0) because if it did, there's a potential for crashing into the build plate. It homes at the top instead (0,0,585) and does not immediately traverse to (0,0,0). I have a parser which connects to the interpreter. The interpreter issues canonical commands to a motion controller. The motion controller sends trajectories to a planner (around machine accel/velocity limits) which then issues poly coeffs to the joint interpolators. It's all tied together with floating point numbers and pointers, but the way I implemented it deliberately prevents the possibility of two drivers writing to the same output signal. I first became more interested in LinuxCNC when i noticed the striking resemblance to how i'm approaching things and of course its early origins at NIST. I gave the motion controller keys to everything so to speak. To maintain a consistent machine state it's all encapsulated into the motion module, including the current machine position. I'm not sure if LinuxCNC does it his way, but this encapsulation requires that my interpreter keep its own tabs on machine position. Without it, it can't form the parameters for the canonical calls when the user only specifies axis words that changed from the previous command. The problem is that if the motion module executes a change in coordinate systems, offsets, homes or jogs, the interpreter's machine position is no longer synced. I am hoping I can learn how LinuxCNC approaches things to aid in my own efforts and to better understand LinuxCNC itself. I suspect one would need a callback function that the motion module could use to update the interpreter when sync between the two machine positions are lost. Or a global machine position variable. Are the axis words 'sticky', or does it only seem that way until a home or jog is done-making it apparent that it just seems sticky and only the current machine position is used? Say we have the following situation with a linear delta machine. 1. Machine powered on. 2. Machine homed. New machine position is (0,0,585) in millimeters. 3. "G0 Z 20" command issued. 4. Machine rehomed. 5. "G0 Z 40" At step 5, does the machine move from (0,0,585) to (0,0,40), or does it move from (0,0,20) to (0,0,40)? My intuition tells me that to be consistent, it would have to always use the current machine position, instead of the last specified axis words. It still seems like interpreter would need to know the current machine position, since it is not necessary to specify an axis word if that coordinate hasn't change. But I could be wrong. Say we issue "G0 X 10 Y 20 Z 30" and then later "G0 Z 0". How would it go from just receiving a "change Z coordinate to 0" to issuing a canonical command like STRAIGHT_FEED(10,20,0,0,0,0) Is there a document section that clearly details the intercommunication between the different modules? I know I could take a look at the source, but I am actively trying to avoid looking at it (similar to the Chinese wall method) so that I won't risk violating LinuxCNC's GPL with my side project. I do have some ideas for the harder problems in LinuxCNC and will be using this experience as a testbed to vet my ideas. Thanks in advance! Sent from my iPhone ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
