Re: [Emc-developers] Initial tests of circular arc blending
On 26 Dec 2013, at 07:16, Michael Haberler mai...@mah.priv.at wrote: however: why not have more than one motion component? Motmod is already an INI entry. How difficult would it be to separately compile a separate motmod2_experimental ? -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] -msse on recent kernel + gcc combos
On Tue, Dec 24, 2013 at 03:08:18AM -0600, John Morris wrote: This'll affect pre-UBC trees when 3.8.13 RTAI kernels are available. https://mail.rtai.org/pipermail/rtai/2013-December/026199.html Someone who has a good handle on this should contribute to rtai a patch so that `rtai-config --module-cflags` gives the appropriate values for kernel math. It would be great if we could just use the value from rtai-config instead of trying to add/remove flags like -msse, -msse2, -mfast-math in the kernel CFLAGS as we've done so frequently in the past. Jeff -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Breaking Free of the Box
I've started moving my linear delta printer using LinuxCNC, and despite using the joints-axis code, I'm still having non-trivial issues with non-trivial kinematics. Basically, the problem boils down to the boxy perspective of LinuxCNC, where most limits (position, velocity, and acceleration) are attributes of a Cartesian coordinate system and are not interrelated. For the linear delta platform, this requires me to either give up a very significant portion of the machine performance or use limits that allow the generation of illegal conditions, which sort of defeats the purpose of having limits in the first place. DETAILS: Position: The odd-shaped movement envelope of a linear-delta machine is most easily approximated with a cylinder. Using a box of (MIN|MAX)_LIMIT for X, Y, and Z to describe the allowable motion range either wastes a *LOT* of usable machine volume, or allows illegal moves into the corners. Velocity Acceleration: Similar issues exist with velocity and acceleration. If I tune the maximum velocity and acceleration limits so that a move along any axis is within the limits of the machine, then diagonal moves across multiple axis will exceed the machine limits. If I dial the limits down for the worst-case diagonal move, I'm wasting a significant chunk of machine performance almost all of the time. By way of gcode examples: This works all day long: g0 x0 gy y0 g0 x100 g0 y100 repeat This fails with a joint following error: g0 x0 y0 g0 x100 y100 repeat Relative Joint Positions: Given the construction of a linear delta machine, there are some limits on the joint positions beyond the simple (MIN|MAX)_LIMIT provided for in the joints-axis branch. Basically, all joints need to be within a certain distance of each other or bad things happen. If one of the diagonal rods goes horizontal, the parallelograms keeping the effector platform level degenerate and the effector can pivot in space. Also, if the joints get too far from each other, something will break (the allowable motion range for the joints is longer than the distance covered by two sets of diagonal rods and the effector, so putting one joint at the MIN_LIMIT and one at the MAX_LIMIT will be trying to rip off the arms or tear the effector in half...although on my machine it just makes a lot of noise and skips steps). Homing: I'm also concerned about homing, where it would be very convenient (and on some mechanisms probably required) to do coordinated moves and not a simple move the joint until the switch closes. IMHO there needs to be a way to write programmable homing routines that can perform coordinated motion in joint and/or world space, But one thing at a time... PROPOSAL: It seems to me that the limit check functions should be plug-able, like the kinematics module. The limits could then be as simple or complex as required by any particular machine. QUESTIONS: Has anyone done anything like this yet? I'd much rather just use something someone else has written than code it myself. :) If I do go about trying to code this up, is there any interest in having this type of feature for official LinuxCNC? If so, I would appreciate a few pointers from the active developers, mostly in which version to start modifying. I _think_ I might be able to make these changes to master and merge them forward into the UBC+JA4 branch I'm using, but I haven't examined the code enough to know for sure. -- Charles Steinkuehler char...@steinkuehler.net signature.asc Description: OpenPGP digital signature -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Emc-developers Digest, Vol 92, Issue 49
On Thu, Dec 26, 2013 at 10:17 AM, emc-developers-requ...@lists.sourceforge.net wrote: Breaking Free of the Box (Charles Steinkuehler) Hey Charles, This is what caused me alot of grief when using my delta printer with LCNC. I kept getting following errors all over the place no matter how much I tried adjusting parameters. I would love it if someone already did something like you suggest but I haven't found anything yet. I still use LCNC alot but for some things I print out I have to switch back to Repetier and RAMPS setup just to get it printed. I am debating on building another printer but make it Mendel style instead of Delta so I can use LCNC for that exclusively. Bob -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
On Thu, Dec 26, 2013 at 09:17:18AM -0600, Charles Steinkuehler wrote: simple move the joint until the switch closes. IMHO there needs to be a way to write programmable homing routines that can perform coordinated motion in joint and/or world space, But one thing at a time... I don't see how you can possibly move in world space before homing. I do see how you could move all joints simultaneously, for instance, which might be what you mean? This is a form of coordinated motion but it is not how we usually use the term coordinated, which means in world mode and in lines and arcs, etc. PROPOSAL: It seems to me that the limit check functions should be plug-able, like the kinematics module. The limits could then be as simple or complex as required by any particular machine. Have you tried just having your inverse kins return a failure in the situations you've identified as bad? in JA4 this is dealt with nicely I think. Endpoints are checked before a move is started. Not sure about how world mode jogs handle it. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
I like this idea, as it would make it much easier to make changes without messing up other people's work. It would take a bit of reorganization, since the motion module code is spread out over a few folders. I'm thinking it would help to rearrange these files into motion_common, trajectory_planners, kinematics, and then motion and motion2_experimental for module-specific code. Otherwise, we'll have a ton of code duplication. Another issue I can see is that whitespace is a crapshoot in most of the motion files. I'd really like to reindent all of them with spaces and 4-column indents, but this should probably be done across all of the major branches at once to prevent merge headaches. An alternative idea in a similar vein: would it be possible to specify a trajectory planner module in HAL, separate from the motion module? We'd have to agree on an API, but I can see that being less duplication and reorganization than two entirely separate motion modules. -Rob On Thu, Dec 26, 2013 at 5:34 AM, Andy Pugh bodge...@gmail.com wrote: On 26 Dec 2013, at 07:16, Michael Haberler mai...@mah.priv.at wrote: however: why not have more than one motion component? Motmod is already an INI entry. How difficult would it be to separately compile a separate motmod2_experimental ? -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
The way I understand it - the kins are 'on top' of motion at the moment. (I don't know if ja4 solves this - but I think it is the start).. So motion calculates the xyzabcuvw limits - then they get run through the kins module which could depending on the machine layout - multiply or divide these calculations for each 'joint'. sam On 12/26/2013 11:03 AM, Charles Steinkuehler wrote: On 12/26/2013 10:17 AM, Chris Radek wrote: On Thu, Dec 26, 2013 at 09:17:18AM -0600, Charles Steinkuehler wrote: simple move the joint until the switch closes. IMHO there needs to be a way to write programmable homing routines that can perform coordinated motion in joint and/or world space, But one thing at a time... I don't see how you can possibly move in world space before homing. I do see how you could move all joints simultaneously, for instance, which might be what you mean? This is a form of coordinated motion but it is not how we usually use the term coordinated, which means in world mode and in lines and arcs, etc. PROPOSAL: It seems to me that the limit check functions should be plug-able, like the kinematics module. The limits could then be as simple or complex as required by any particular machine. Have you tried just having your inverse kins return a failure in the situations you've identified as bad? in JA4 this is dealt with nicely I think. Endpoints are checked before a move is started. Not sure about how world mode jogs handle it. I've had kinematics return invalid results for position, and I suppose it behaves similar to hitting a limit (the machine shuts off and an error is presented on-screen). So position might not be too bad as-is (although it's nice to be told if gcode exceeds the machine limits on program load instead of 90% of the way through!). I'm more concerned about being able to set coordinated acceleration and velocity limits, so I can avoid having to perform X and Y moves at 57 % of my available max velocity and acceleration just so the occasional XYZ move doesn't exceed 100% of machine limits. Details: Given a maximum X, Y, and Z velocity of 1.0, the maximum speed of an XY move is 1.414 (or SQRT(2)), and the maximum speed of an XYZ move is 1.73 (or SQRT(3)), so I have to set my limits to 1/1.73 (0.577) of the actual limits or the machine will exceed them in the corner case. (pun intended) ...or is there already a way to limit the directional speed and acceleration of the head and not just the maximums in each Cartesian coordinate? -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
On Dec 26 2013 10:03 AM, Charles Steinkuehler wrote: On 12/26/2013 10:17 AM, Chris Radek wrote: On Thu, Dec 26, 2013 at 09:17:18AM -0600, Charles Steinkuehler wrote: simple move the joint until the switch closes. IMHO there needs to be a way to write programmable homing routines that can perform coordinated motion in joint and/or world space, But one thing at a time... I don't see how you can possibly move in world space before homing. I do see how you could move all joints simultaneously, for instance, which might be what you mean? This is a form of coordinated motion but it is not how we usually use the term coordinated, which means in world mode and in lines and arcs, etc. PROPOSAL: It seems to me that the limit check functions should be plug-able, like the kinematics module. The limits could then be as simple or complex as required by any particular machine. Have you tried just having your inverse kins return a failure in the situations you've identified as bad? in JA4 this is dealt with nicely I think. Endpoints are checked before a move is started. Not sure about how world mode jogs handle it. I've had kinematics return invalid results for position, and I suppose it behaves similar to hitting a limit (the machine shuts off and an error is presented on-screen). So position might not be too bad as-is (although it's nice to be told if gcode exceeds the machine limits on program load instead of 90% of the way through!). I'm more concerned about being able to set coordinated acceleration and velocity limits, so I can avoid having to perform X and Y moves at 57 % of my available max velocity and acceleration just so the occasional XYZ move doesn't exceed 100% of machine limits. Details: Given a maximum X, Y, and Z velocity of 1.0, the maximum speed of an XY move is 1.414 (or SQRT(2)), and the maximum speed of an XYZ move is 1.73 (or SQRT(3)), so I have to set my limits to 1/1.73 (0.577) of the actual limits or the machine will exceed them in the corner case. (pun intended) ...or is there already a way to limit the directional speed and acceleration of the head and not just the maximums in each Cartesian coordinate? I can see your math working on a single step, but the kinematics should account for diagonal moves as is. My question is what is the given move that it is complaining about. Can you isolate it? I mean the given line? EBo -- -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Naive CAM behavior
Hi All, I noticed an odd quirk with the Naive CAM detector when debugging an issue with circular arc blending. In particular, I was trying to find the source of this error: (Starting from X56.09083 Z0.49686 ) N1 G1 X20.16452 N2 X19.2665 Z0.86884 N3 X18.89452 Z1.76686 https://www.dropbox.com/s/bpg2xvxa30yrpzl/following%20error.png It looks like the short segment (N2) is being eliminated entirely. It looks like the Naive CAM detector is using a linear distance as a tolerance based on this post in the forums: http://linuxcnc.org/hardy/dapper/index.php/french/forum/20-g-code/19371-g64-p-q-naive-cam-tolerance-setting I'm not sure what the original intent of Naive CAM detection was, but eliminating a segment that is clearly not tangent by its angle with the previous line seems counter-intuitive to me. However, this behavior does make sense if its job is to coarsen a given path by a certain linear tolerance. A more subtle issue here is that the Naive CAM detector uses the P word of G64 if Q is not specified. So, if I specify G64 P0.5 (like in the image above), then it also assumes Q0.5 by default. To me, this is bad because the blend tolerance (P0.5) is effectively applied twice. In the example above, line N2 is eliminated entirely, which means the path is already up to 0.5mm from ideal when it is passed to the trajectory planner. Now, TP applies a blend with tolerance, leading to another 0.5mm deviation, for a total of 1mm possible deviation. If the default behavior was always to make Q0, then a user would have to explicitly ask for a Naive CAM tolerance. To explicitly get the same situation as above, a user would call: G64 P0.5 Q0.5 By explicitly calling the Q term, it's much more apparent that we're applying two separate tolerances to the path. Does this sound like a reasonable change? If so, it looks like just deleting lines 1508-1509 in interp_convert.cc would do it. -Rob -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
Did you get a chance to see if the ini settings are working for you? I have not tested it since tuesday. could it be something I am doing wrong? thanks sam On 12/26/2013 10:54 AM, Robert Ellenberg wrote: I like this idea, as it would make it much easier to make changes without messing up other people's work. It would take a bit of reorganization, since the motion module code is spread out over a few folders. I'm thinking it would help to rearrange these files into motion_common, trajectory_planners, kinematics, and then motion and motion2_experimental for module-specific code. Otherwise, we'll have a ton of code duplication. Another issue I can see is that whitespace is a crapshoot in most of the motion files. I'd really like to reindent all of them with spaces and 4-column indents, but this should probably be done across all of the major branches at once to prevent merge headaches. An alternative idea in a similar vein: would it be possible to specify a trajectory planner module in HAL, separate from the motion module? We'd have to agree on an API, but I can see that being less duplication and reorganization than two entirely separate motion modules. -Rob On Thu, Dec 26, 2013 at 5:34 AM, Andy Pugh bodge...@gmail.com wrote: On 26 Dec 2013, at 07:16, Michael Haberler mai...@mah.priv.at wrote: however: why not have more than one motion component? Motmod is already an INI entry. How difficult would it be to separately compile a separate motmod2_experimental ? -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
2013/12/26 Charles Steinkuehler char...@steinkuehler.net I'm more concerned about being able to set coordinated acceleration and velocity limits, so I can avoid having to perform X and Y moves at 57 % of my available max velocity and acceleration just so the occasional XYZ move doesn't exceed 100% of machine limits. Details: Given a maximum X, Y, and Z velocity of 1.0, the maximum speed of an XY move is 1.414 (or SQRT(2)), and the maximum speed of an XYZ move is 1.73 (or SQRT(3)), so I have to set my limits to 1/1.73 (0.577) of the actual limits or the machine will exceed them in the corner case. (pun intended) There's another problem: dJ1/dX can significantly exceed 1, the same for dJ1/dY and dJ1/dZ (say J1 is the first joint). And during XYZ move dJ1 = dJ1/dX + dJ1/dY + dJ1/dZ can be very large in the worst case. I have exactly the same with my parallel robot, even worse for 6axis. The solution I can think of: calculating each joint velocity and acceleration before each move (at several points at least for a long moves) and then decreasing XYZ velocities to fit joint velocities to their limits. Andrew -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
On Thu, Dec 26, 2013 at 6:03 PM, Charles Steinkuehler char...@steinkuehler.net wrote: On 12/26/2013 10:17 AM, Chris Radek wrote: On Thu, Dec 26, 2013 at 09:17:18AM -0600, Charles Steinkuehler wrote: simple move the joint until the switch closes. IMHO there needs to be a way to write programmable homing routines that can perform coordinated motion in joint and/or world space, But one thing at a time... I don't see how you can possibly move in world space before homing. I do see how you could move all joints simultaneously, for instance, which might be what you mean? This is a form of coordinated motion but it is not how we usually use the term coordinated, which means in world mode and in lines and arcs, etc. PROPOSAL: It seems to me that the limit check functions should be plug-able, like the kinematics module. The limits could then be as simple or complex as required by any particular machine. Nice idea!!! Have you tried just having your inverse kins return a failure in the situations you've identified as bad? in JA4 this is dealt with nicely I think. Endpoints are checked before a move is started. Not sure about how world mode jogs handle it. I've had kinematics return invalid results for position, and I suppose it behaves similar to hitting a limit (the machine shuts off and an error is presented on-screen). So position might not be too bad as-is (although it's nice to be told if gcode exceeds the machine limits on program load instead of 90% of the way through!). Is this functionality (checking gcode on program load) currently implemented??? --- I like the proposal of having such a plugable limit-check functions or whaterver you whant check function. To make it general I think that conceptually this function should give an error condition in any situation that is not considered OK, werther it is related to position velocity acceleration jerk of whatever kinematic abstration you can define (think about avoiding a position dependent resonant frequency, for example). I think user defined variable amount of parameters to characterize the function behavior could be defined at the init level, without even having to match a concise kinematic concept. I wonder if user defined error reporting can be implemented easily, so that the kinematics module programer can decide how to report the error. Defaults can be given for this function, so that it provides the current standard for limit checking. I'm speaking about kinematics, but the same abstraction could equaly rise error conditions on dynamics (or ...) based diagnostic, without changing the abstraction. Javier -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
On Thu, Dec 26, 2013 at 11:54:34AM -0500, Robert Ellenberg wrote: I like this idea, as it would make it much easier to make changes without messing up other people's work. It would take a bit of reorganization, since the motion module code is spread out over a few folders. I'm thinking it would help to rearrange these files into motion_common, trajectory_planners, kinematics, and then motion and motion2_experimental for module-specific code. Otherwise, we'll have a ton of code duplication. While the trajectory planner does not have as clean or simple an API as kinematics, I don't see why it can't be loadable in exactly the same way kinematics are. But I do not understand why you are saying that what directory files are in would increase or decrease code duplication. I think making the TP loadable would not require any code duplication at all. Another issue I can see is that whitespace is a crapshoot in most of the motion files. I'd really like to reindent all of them with spaces and 4-column indents, but this should probably be done across all of the major branches at once to prevent merge headaches. Unless the files are totally incomprehensible or are overtly broken (like with dos line endings) the reindenting cure is always worse than the disease. It can make it harder to maintain/merge/work with different branches as you identified, but also is hostile to everyone else who has a clone with work they're maintaining separately (like you...). With centralized VCS you could at least cap the damage, but with git and distributed development, it's very damaging and is totally not worth it for simple aesthetic reasons. An alternative idea in a similar vein: would it be possible to specify a trajectory planner module in HAL, separate from the motion module? We'd have to agree on an API, but I can see that being less duplication and reorganization than two entirely separate motion modules. Now I see we're thinking along the same lines. Making kins loadable looks like it was utterly simple (in retrospect of course, ha) - see rev dad30801b53 Looks like emcmotStatus and emcmotDebug pointers will have to be passed in through the tpCreate() call but I don't see any other stumbling blocks. If someone else doesn't attack it before I can get to it, I'll try. Chris -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
On Thu, Dec 26, 2013 at 10:00:28PM +0200, Andrew wrote: The solution I can think of: calculating each joint velocity and acceleration before each move (at several points at least for a long moves) and then decreasing XYZ velocities to fit joint velocities to their limits. This is exactly the solution Seb, Jeff, and I have talked about several times. I like the simplicity of the idea where you just look along the move until you find where you're exceeding joint constraints the worst, then if you are, scale back accordingly for the whole move, and plan it in world space like usual. It would be hard to know how much searching along the path you'd need to do, but on a well-behaved machine where the singularities aren't too close to the working volume, a bit of binary search would give you a very good idea. Perhaps you could know to stop searching when you get down to a few encoder counts/steps, or you could stop early if you are running out of time (we've never done anything like that, but why not? We know the thread period.) Chris -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
On 12/26/2013 2:00 PM, Andrew wrote: Details: Given a maximum X, Y, and Z velocity of 1.0, the maximum speed of an XY move is 1.414 (or SQRT(2)), and the maximum speed of an XYZ move is 1.73 (or SQRT(3)), so I have to set my limits to 1/1.73 (0.577) of the actual limits or the machine will exceed them in the corner case. (pun intended) There's another problem: dJ1/dX can significantly exceed 1, the same for dJ1/dY and dJ1/dZ (say J1 is the first joint). And during XYZ move dJ1 = dJ1/dX + dJ1/dY + dJ1/dZ can be very large in the worst case. I have exactly the same with my parallel robot, even worse for 6axis. The solution I can think of: calculating each joint velocity and acceleration before each move (at several points at least for a long moves) and then decreasing XYZ velocities to fit joint velocities to their limits. Yes, the problem can get arbitrarily hard, depending on exactly what you want to check and if you're doing things like mapping the move into joint space in order to run the check. That's a big reason I think the limit check(s) should be plug-able. For now, I'd be happy with something that simply limited the combined XYZ velocity and acceleration limits to a particular value. But if the CPU cycles are available, there's no reason code couldn't be written that worked with the real joint limits and worked backwards through the kinematics. But before anything fancy can happen, there needs to be a way to implement a more sophisticated check for the various limits. -- Charles Steinkuehler char...@steinkuehler.net signature.asc Description: OpenPGP digital signature -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
2013/12/26 Chris Radek ch...@timeguy.com On Thu, Dec 26, 2013 at 10:00:28PM +0200, Andrew wrote: The solution I can think of: calculating each joint velocity and acceleration before each move (at several points at least for a long moves) and then decreasing XYZ velocities to fit joint velocities to their limits. This is exactly the solution Seb, Jeff, and I have talked about several times. I like the simplicity of the idea where you just look along the move until you find where you're exceeding joint constraints the worst, then if you are, scale back accordingly for the whole move, and plan it in world space like usual. Yes, that is very reasonable. Just calculate the scale and use usual planning. The task can also be reversed: increase world velocity to the maximum allowed by joint constraints. This can be useful for G0 moves. It would be hard to know how much searching along the path you'd need to do, but on a well-behaved machine where the singularities aren't too close to the working volume, a bit of binary search would give you a very good idea. Perhaps you could know to stop searching when you get down to a few encoder counts/steps, or you could stop early if you are running out of time (we've never done anything like that, but why not? We know the thread period.) The number of probing points and/or max distance between the points along the path can be INI parameters. My guess is 8-10 points would be enough in most cases for linear moves, the circles can be more complicated. For short moves the only end point is enough (assuming the start is already checked as the end of the previous move). Andrew -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
2013/12/26 Charles Steinkuehler char...@steinkuehler.net Yes, the problem can get arbitrarily hard, depending on exactly what you want to check and if you're doing things like mapping the move into joint space in order to run the check. That's a big reason I think the limit check(s) should be plug-able. For now, I'd be happy with something that simply limited the combined XYZ velocity and acceleration limits to a particular value. But if the CPU cycles are available, there's no reason code couldn't be written that worked with the real joint limits and worked backwards through the kinematics. But before anything fancy can happen, there needs to be a way to implement a more sophisticated check for the various limits. The limits should definitely be pluggable to account at least for angular limits of ball joints etc. BTW some standard cone workspace for AB axes would be OK for many parallel robots. But usual kinematics module seems enough for velocities and accelerations check if the planner could perform it. Andrew -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
2013/12/26 Andrew pkm...@gmail.com Yes, that is very reasonable. Just calculate the scale and use usual planning. The task can also be reversed: increase world velocity to the maximum allowed by joint constraints. This can be useful for G0 moves. Umm, sorry for offtopic, am I the only one to be missing out something obvious and think that this whole problem would apply _only_ to rapid (G0) moves? All the other moves are feedrate limited - they are executed at the requested feedrate and intentional deviation from that does not seem right, so I am missing, how the whole concept of checking for worst-case velocity violations and scaling down appropriately will not break the purpose of requesting particular feedrate in code. Viesturs -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
On Dec 26 2013 2:47 PM, Viesturs Lācis wrote: 2013/12/26 Andrew pkm...@gmail.com Yes, that is very reasonable. Just calculate the scale and use usual planning. The task can also be reversed: increase world velocity to the maximum allowed by joint constraints. This can be useful for G0 moves. Umm, sorry for offtopic, am I the only one to be missing out something obvious and think that this whole problem would apply _only_ to rapid (G0) moves? All the other moves are feedrate limited - they are executed at the requested feedrate and intentional deviation from that does not seem right, so I am missing, how the whole concept of checking for worst-case velocity violations and scaling down appropriately will not break the purpose of requesting particular feedrate in code. I was going to ask the same thing... If the issue is with the rapid traverse that is set limited with the max velocity. Are you sure that the max velocity is set correctly? EBo -- -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
The limits should definitely be pluggable to account at least for angular limits of ball joints etc. BTW some standard cone workspace for AB axes would be OK for many parallel robots. But usual kinematics module seems enough for velocities and accelerations check if the planner could perform it. My 2 cents: I like the idea of a reachability check, but I'm not sure the limit check is the right place for it. A common way to measure reachability for a robot like a 6DOF arm is with a pre-computed reachability space. First, you sample a bunch of robot poses, rejecting any poses that are in collision. The ones that are left (and the corresponding workspace positions) are your reachable space. When you run the reachability check, if your pose is near enough to one of these points, then it's a reachable pose. There are simplifications you can make for cases like the linear delta robot, but fundamentally this is a search problem, which means many (possibly slow) steps. In my opinion, the limit check is really just there to keep the axes from going past their physical limits. Even on a trivial case like a CNC mill, there are dead spots that you can't easily check for (such as a big vise in the middle of the table!). Your part program is designed to avoid the fixture, but ultimately it's an act of faith to hit play. -Rob -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
It seems to be working on my end, in that I can enable and disable various setting from the INI file, and see the correct behavior in simulation. Can you try running my test config to see if it works on your build? tests/trajectory-planner/circular-arcs/circular_arcs.ini If that works then I'd suspect a typo. On Dec 26, 2013 2:37 PM, sam sokolik sa...@empirescreen.com wrote: Did you get a chance to see if the ini settings are working for you? I have not tested it since tuesday. could it be something I am doing wrong? I've run it on my laptop and desktop without issue, and I've tested that enabling/disabling each setting has the intended effect. Try running the config in tests/trajectory thanks sam -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
will do! thanks sam On 12/26/2013 04:07 PM, Robert Ellenberg wrote: It seems to be working on my end, in that I can enable and disable various setting from the INI file, and see the correct behavior in simulation. Can you try running my test config to see if it works on your build? tests/trajectory-planner/circular-arcs/circular_arcs.ini If that works then I'd suspect a typo. On Dec 26, 2013 2:37 PM, sam sokolik sa...@empirescreen.com wrote: Did you get a chance to see if the ini settings are working for you? I have not tested it since tuesday. could it be something I am doing wrong? I've run it on my laptop and desktop without issue, and I've tested that enabling/disabling each setting has the intended effect. Try running the config in tests/trajectory thanks sam -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
2013/12/26 Robert Ellenberg rwe...@gmail.com The limits should definitely be pluggable to account at least for angular limits of ball joints etc. BTW some standard cone workspace for AB axes would be OK for many parallel robots. But usual kinematics module seems enough for velocities and accelerations check if the planner could perform it. My 2 cents: I like the idea of a reachability check, but I'm not sure the limit check is the right place for it. A common way to measure reachability for a robot like a 6DOF arm is with a pre-computed reachability space. First, you sample a bunch of robot poses, rejecting any poses that are in collision. The ones that are left (and the corresponding workspace positions) are your reachable space. When you run the reachability check, if your pose is near enough to one of these points, then it's a reachable pose. There are simplifications you can make for cases like the linear delta robot, but fundamentally this is a search problem, which means many (possibly slow) steps. In my opinion, the limit check is really just there to keep the axes from going past their physical limits. Even on a trivial case like a CNC mill, there are dead spots that you can't easily check for (such as a big vise in the middle of the table!). Your part program is designed to avoid the fixture, but ultimately it's an act of faith to hit play. For many parallel robots some combinations of cones and cylinders can describe their actual workspace pretty well. For a serial robot arm it's can be more complicated but those cones and cylinders (along with joints limits) are much better than a trivial XYZ box. For CNC mill from your example it could be useful to exclude some smaller boxes or cylinders out of the rectangular workspace. Of course, a prepared and checked G-code is (more or less) safe but using actual machine workspace limits makes it double safe. Andrew -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
2013/12/26 EBo e...@sandien.com On Dec 26 2013 2:47 PM, Viesturs Lācis wrote: 2013/12/26 Andrew pkm...@gmail.com Yes, that is very reasonable. Just calculate the scale and use usual planning. The task can also be reversed: increase world velocity to the maximum allowed by joint constraints. This can be useful for G0 moves. Umm, sorry for offtopic, am I the only one to be missing out something obvious and think that this whole problem would apply _only_ to rapid (G0) moves? All the other moves are feedrate limited - they are executed at the requested feedrate and intentional deviation from that does not seem right, so I am missing, how the whole concept of checking for worst-case velocity violations and scaling down appropriately will not break the purpose of requesting particular feedrate in code. I was going to ask the same thing... If the issue is with the rapid traverse that is set limited with the max velocity. Are you sure that the max velocity is set correctly? I do agree with Charles that stating one value fits all the possible cases max velocity in world coordinates considerably reduces the potential max velocity in other, not-so-bad areas. I am designing linear delta robot for my bachelor thesis and, based on my model, I calculated that in the middle of the work envelope 1 mm joint movement would move the tool by 1,7 mm while at the edge of the work envelope 1 mm move of the most stretched out joint would move the tool by 0,35 mm (both values refer to tool's motion in XY plane, while joints are parallel to Z). The difference is very high. Currently I would set world max vel approximately 3 times lower than actual joint max velocity. But as I see it now, currently discussed solution would only affect rapid moves anyway. Viesturs -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
2013/12/27 Andrew pkm...@gmail.com 2013/12/26 Robert Ellenberg rwe...@gmail.com For many parallel robots some combinations of cones and cylinders can describe their actual workspace pretty well. For a serial robot arm it's can be more complicated but those cones and cylinders (along with joints limits) are much better than a trivial XYZ box. For CNC mill from your example it could be useful to exclude some smaller boxes or cylinders out of the rectangular workspace. Of course, a prepared and checked G-code is (more or less) safe but using actual machine workspace limits makes it double safe. I do not see a problem to describe the work envelope with an equation with 3 (or whatever the number of axes involved) variables (there would be 2 variables for cylinder, 3 for sphere, some might get fancy and include angular axes as well), just like there are equations in kinematics modules. I just have no idea, what does it take to implement that, so that at the moment of loading the g-code file it would be checked against those equations. Viesturs -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
On 12/26/2013 3:52 PM, EBo wrote: On Dec 26 2013 2:47 PM, Viesturs Lācis wrote: 2013/12/26 Andrew pkm...@gmail.com Yes, that is very reasonable. Just calculate the scale and use usual planning. The task can also be reversed: increase world velocity to the maximum allowed by joint constraints. This can be useful for G0 moves. Umm, sorry for offtopic, am I the only one to be missing out something obvious and think that this whole problem would apply _only_ to rapid (G0) moves? All the other moves are feedrate limited - they are executed at the requested feedrate and intentional deviation from that does not seem right, so I am missing, how the whole concept of checking for worst-case velocity violations and scaling down appropriately will not break the purpose of requesting particular feedrate in code. I was going to ask the same thing... If the issue is with the rapid traverse that is set limited with the max velocity. Are you sure that the max velocity is set correctly? Hmm...I've been doing g0 moves (as mentioned elsewhere in this thread), but I suppose a g1 with a feed-rate would be one way to side-step the issue. Look! LinuxCNC works GREAT with arbitrary kinematics! Just don't do any g0 moves! :-O ...but I digress... Yes, I'm pretty sure the maximum velocity is set correctly. I can do g0 moves inside the safe box on any one axis without problem. If I go a g0 move across two or three axis, I get following errors which I believe is due to LinuxCNC thinking it can go at the maximum velocity in all three X/Y/Z axis AT THE SAME TIME. So is there a maximum feedrate setting for g0 moves? That would fix a *BIG* chunk of my problem without additional code. If so, how do I set it? If this isn't possible, why not? I would think this could have application even to standard Cartesian machines, where you don't want the head traveling more than a certain speed, regardless of the heading vector. -- Charles Steinkuehler char...@steinkuehler.net signature.asc Description: OpenPGP digital signature -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
2013/12/26 EBo e...@sandien.com I was going to ask the same thing... If the issue is with the rapid traverse that is set limited with the max velocity. Are you sure that the max velocity is set correctly? OK for a trivial kins this can be a solution. Max velocity can be limited to joint velocity and joints velocities check can be skipped. Though in this case the XYZ move velocity will be 1.0 instead of 1.73 (see above discussion). But for a parallel or serial manipulator a joint velocity can easily exceed world velocity twice or more. That is limiting max world velocity to the worst case scenario would seriuosly under-utilize the joints in most other cases (just like using half joints acceleration to ensure the worst case of reverse blending in the current planner). Andrew -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
2013/12/27 Charles Steinkuehler char...@steinkuehler.net So is there a maximum feedrate setting for g0 moves? IMHO that is what max velocity in [TRAJ] section meant for. Viesturs -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
re: work envelopes heres a simplified overview of several work envelopes http://thnet.co.uk/thnet/robots/25.htm regards TomP tjtr33 -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
Ok - I must have had some odd characters on those lines - I deleted the last few characters and re-typed them and it seems to be working as expected. One odd issue. If I set the ARC_BLEND_ENABLE to 0 the spiral runs as expected.. (around 100ipm) but the arcspiral still seems to use the read ahead as it runs at top speed (420ipm) and I can make it run as the original tp by setting the ARC_BLEND_OPTIMIZATION_DEPTH to 1 (runs about 80ish-ipm). BTW setting it to 0 causes what looks like exact stop mode - pretty neat :) I don't know if that is bad or not.. but it surely doesn't act like the original trajectory planner. sam On 12/26/2013 04:07 PM, Robert Ellenberg wrote: It seems to be working on my end, in that I can enable and disable various setting from the INI file, and see the correct behavior in simulation. Can you try running my test config to see if it works on your build? tests/trajectory-planner/circular-arcs/circular_arcs.ini If that works then I'd suspect a typo. On Dec 26, 2013 2:37 PM, sam sokolik sa...@empirescreen.com wrote: Did you get a chance to see if the ini settings are working for you? I have not tested it since tuesday. could it be something I am doing wrong? I've run it on my laptop and desktop without issue, and I've tested that enabling/disabling each setting has the intended effect. Try running the config in tests/trajectory thanks sam -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
One odd issue. If I set the ARC_BLEND_ENABLE to 0 the spiral runs as expected.. (around 100ipm) but the arcspiral still seems to use the read ahead as it runs at top speed (420ipm) and I can make it run as the original tp by setting the ARC_BLEND_OPTIMIZATION_DEPTH to 1 (runs about 80ish-ipm). BTW setting it to 0 causes what looks like exact stop mode - pretty neat :) I don't know if that is bad or not.. but it surely doesn't act like the original trajectory planner. Excellent! I think this quirk is because it's always looking for tangent segments, since I didn't explicitly include a flag to disable tangent detection. It will still try to run the optimizer over segments that are already tangent, unless the optimization depth is 1. I'm working on a fix that will revert to stock behavior if the depth is less than 2. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
