On 11/11/2013 09:50 PM, alan wrote: > I did originally write both parts as per your changes. But kept getting > a compilation error. I cannot remember what the message was and it was > probably because of something else. So made those changes and it all > seemed to work . I probably inadvertantly fixed the real problem but not > having written C in such a long time I am not sure what was wrong.
Yes, the error was probably hitting the mm/deg conversion bug. That should be fixed in version 1.2.0, which I released earlier today. I am happy to fix any bugs you encounter as long as I get an example that triggers it. Anyone who is not versed in C may prefer not to delve into the code and I am just as happy to receive examples, comments and suggestions. My background is EE/CS, so my strengths are more in the computer stuff than the mechanics. >> The sin(), cos() and tan() functions will internally convert from >> degrees to radians before calling the underlying system sin/cos/tan >> function. > Didnt know about that thanks for the information Yeah, the automatic conversion of units was one of my original design parameters of the language. I have had so many problems and stupid errors when doing it manually that I considered it to be a requirement. > Finally a comment about angles. I found when generating gcode in my own > windows based program that I had to be careful with angles greater than > 360. (This was before wrapped axes havent tried wrapped axes so dont > know what will happen) . If I generated a path with multiple turns > around the origin (easy to do with the wheels patterns), so that for > example the polar coordinates (radius, angle,depth) of successive points > was say (10,360,-1) then (12,10,-1) then (15,40,-1) in the same > direction which for my setup is anticlockwise. Linuxcnc would get to 360 > then do a clockwise move back to 10 ploughing a nice big path through > the work and spoiling the pattern. So I have to generate positions > (10,360,-1) (12,370,-1),(15,400,-1) to keep rotating in the same > direction. So I keep a note of how many times the cutter crosses the x > axis in an anticlockwise direction (the winding number) and use this to > calculate the angle. If the cutter has a retrograde move and crosses the > x in a clockwise direction I reduce this winding number. I do not use any modulo or other alteration in the coordinates, polar or Cartesian (expect for unit conversion and relative output option). You are absolutely right that 361 degrees and -1 degree are not the same in terms of machining as it encodes directional information. Also, as you correctly comment, 0, 360 and 720 degrees are distinct separate positions, considering the winding of the axis. I actually do not know how LinuxCNC handles this because I never /used/ a mill with a rotational axis, but my guess is that it does not do some modulo or other stupid stuff... I had some consideration about the angular axes, but decided quite early on that the user-program had to decide the actual magnitude and not some mathematical idea of modulo calculus. > I mention this because generating polar coordinates is not quite so > straightforward as cartesians. So even using your example below > vec = [x, -, z, -, -, c]; I agree. Polar coordinate systems are much harder to use than Cartesian. Especially because there is no general agreement on where which rotational axis is mounted. Some may be on the mill's spindle (robotic finger-joints), while others are part of the X or Y axis. I have been pondering some generalizations, but have not come to any result that could be used. However, the example is still reasonably easy to handle. The trick lies in the use of "undef" values in the vectors. The rules for undef are such that simple operations have predictable result. With the addition of shifts (<< and >>) in the new 1.2.0 it should even be easier to handle coordinate subsets. But still, you need to keep track while writing the program. > There has to be some pre-processing. Can this be accomodated by your > meta compiler? Just thinking about your explicit angle conversions > mentioned above. I have no plans of doing pre-processing at this moment. I do have some considerations of defining values on the command-line, which then can be used in the program. But I have not yet decided how to handle that. You can always use the C-pre-processor as a front-end, which is a text-substitution processor. Anyway, if you have some ideas for pre-processing, let me know and we'll debate the issue. > Anyway keep up the good work, How far do you intend to take this > structs? classes? I'll take gcmc as far as is necessary for replacing manual gcode programming. The sky is the limit :-) Classes... no plans at all. It is not an Object Oriented mill I try to control. There would be some few cases where it /might/ be useful, but my intuition tells me that the complexity of OO is a bad fit for a mill or a lathe. Structs, that is another case. I have been pondering to have arcs in lists. A reason to do this is to be able to do tool- or offset-compensation calculations on closed paths. Currently, you can do so on any polygon (like erode() from the star example). But if you want outer-paths, then you want arcs in the movement. It will probably be a feature of version 2.x of the language as it would require quite a bit of re-engineering of the interpreter as far as I can see. However, suggestions are welcome. -- Greetings Bertho (disclaimers are disclaimed) ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
