2012/4/23 andy pugh <bodge...@gmail.com>: > On 23 April 2012 17:52, Viesturs Lācis <viesturs.la...@gmail.com> wrote: > >> Is kinematics module the only place, that limits max number of joints? >> The thing is that I suspect that there are other places as well that >> have hardcoded max number of joints to be less or equal to 9. > > There almost certainly are, but changing that is probably one task for JA3. > >> LinuxCNC still has only 9 axis words (I have been wishing for more - I >> have a client, who might be interested in LinuxCNC, if it was capable >> of handling production lines with up to 40 independently moved joints > > The problem is not in LinuxCNC but in G-code. All commands are a > single letter, and there are none left to be extra axis commands. > > With a different interpreter it might be possible to find a way to > command more axes.
Just like You mentioned - interpreter needs work on that. Since no other users have expressed interest in this and I definitely am not able to handle that, I guess that this is going to remain as is. And some kind of "g-code v.2" needs to be invented for such a number of axis words. Does anyone know, how are this handled in controls that are capable of such machines, like Orchestra Control? I know that they have ability to create separate channels, which AIUI would be equivalent for running several LinuxCNC instances in parallel and syncing them. But I do not get, how do they distinct, which axis word is for which channel. Most probably they have their own proprietary language for that. > If you only want to control more joints, then you could, in theory, > control them with M67/M68 commands. num_aio defaults to 4 with a max > of 16, but that can be changed in the source. > I think that an M68 will hit the setpoint at the end of the next > motion command (ie, synched to motion) but would need to test it to be > sure. Combined with Limit3 and lots of stepgens/PIDs that would allow > control of a large number of actuators. Yes, I have learned that limit3 can be very useful for moving joint with a certain acceleration and max velocity, if commanded position is fed in its input pin. The thing for my case with those big machines is those 40 joints do not require to be interpolated. Many of them would not need any interpolation at all and most of them, that need it, should be interpolated "in pairs", respectively, tool should moved along 2 "axes" in plane, perpendicular to movement of material. Few of the tools would need interpolation also with the material movement. It would be something like on common Z axis for whole machine, which is the conveyor that moves the piece of material and many tools with their X and Y axes, and it would work in a way that Z moves to certain position, stops, certain tool performs its operation, material moves to next stop at a certain point, stops, next tool does its operation. The requirements are: 1) define different Z position for each tool to perform its operation, for example, some pocket mill is used at Z=100 for one part and Z=250 for another part and probably at several points for the same part; 2) define X and Y paths for each tool separately for each part, for example, the same pocket mill should be able do different depths and widths of the pocket; Optional features are: 1) ability to receive the code from 3rd party software "almost on the fly" - while machining one part, receive code for the next one - I guess that this would be tough. LinuxCNC could use NML buffer to store the code for next part, but that would need to be integrated in both LinuxCNC and that another app (they are using some application to view a model of log house and that app recognizes all the features, needed in each separate log, and it creates a code for their existing controls to produce that particular piece of wood, so theoretically it could be taught to generate a code also for LinuxCNC); 2) running the next file automatically after the previous is finished would be excellent; Viesturs ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
