Chris Radek пишет:
>
>> - if(metric) { x /= 25.4; y /= 25.4; z /= 25.4; u /= 25.4; v /= 25.4; w
>> /= 25.4; }
>> +
>> + double p[9] = {x,y,z,a,b,c,u,v,w};
>> + if (metric)
>> + for (int i = 0; i < 9; ++i)
>> + p[i] /= 25.4;
>>
>
> This change causes incorrect scaling of rotary axes.
>
>
Right, will fix.
>
>> - if(metric) { x /= 25.4; y /= 25.4; z /= 25.4; u /= 25.4; v /= 25.4; w
>> /= 25.4; }
>> +
>> + double p[9] = {x,y,z,a,b,c,u,v,w};
>> + if (metric)
>> + for (int i = 0; i < 9; ++i)
>> + p[i] /= 25.4;
>>
>
> Also here
>
>
Yes
>
>> - if(metric) { x /= 25.4; y /= 25.4; z /= 25.4; u /= 25.4; v /= 25.4; w
>> /= 25.4; }
>> + if (metric) {
>> + x /= 25.4; y /= 25.4; z /= 25.4; u /= 25.4; v /= 25.4; w /= 25.4;
>> + }
>>
>
>
>> + offset[0] = x; offset[1] = y; offset[2] = z; offset[3] = a, offset[4] =
>> b, offset[5] = c, offset[6] = u, offset[7] = v, offset[8] = w;
>> maybe_new_line();
>> - if(interp_error) return;
>> + if (interp_error) return;
>> PyObject *result =
>> - PyObject_CallMethod(callback, "set_origin_offsets", "fffffffff",
>> - x, y, z, a, b, c, u, v, w);
>> + PyObject_CallMethod(callback, "set_origin_offsets", "fffffffff",
>> + x, y, z, a, b, c, u, v, w);
>> if(result == NULL) interp_error ++;
>> Py_XDECREF(result);
>> }
>>
>
> Please don't reformat code needlessly in the same commit that has
> changes of substance. This makes it much harder to identify the
> changes of substance in the diff.
>
>
This was not intended as final patch, so formatting is very off.
>> void SET_XY_ROTATION(double t) {
>> + rotation_xy = t * M_PI / 180;
>> + rotation_sin = sin(rotation_xy);
>> + rotation_cos = cos(rotation_xy);
>> maybe_new_line();
>> - if(interp_error) return;
>> - PyObject *result =
>> - PyObject_CallMethod(callback, "set_xy_rotation", "f", t);
>> + PyObject *result = PyObject_CallMethod(callback, "set_xy_rotation",
>> "f", t);
>> if(result == NULL) interp_error ++;
>> Py_XDECREF(result);
>> + if(interp_error) return;
>> };
>>
>> void USE_LENGTH_UNITS(CANON_UNITS u) { metric = u == CANON_UNITS_MM; }
>>
>> void SELECT_PLANE(CANON_PLANE pl) {
>> - maybe_new_line();
>> + plane = pl;
>> + maybe_new_line();
>> if(interp_error) return;
>> +
>> PyObject *result =
>> PyObject_CallMethod(callback, "set_plane", "i", pl);
>> if(result == NULL) interp_error ++;
>>
>
>
> At first glance I don't understand these changes to error checking -
> are they necessary for moving the arc code or are they fixing a
> separate problem?
>
>
No, this is just a copy-paste error. Thanks for noticing, will fix.
>> @@ -488,11 +494,14 @@ void RIGID_TAP(int line_number,
>> if(metric) { x /= 25.4; y /= 25.4; z /= 25.4; }
>> maybe_new_line(line_number);
>> if(interp_error) return;
>> + double p[9] = {x, y, z, 0, 0, 0, 0, 0, 0};
>> + rotate_and_translate(p);
>> PyObject *result =
>> PyObject_CallMethod(callback, "rigid_tap", "fff",
>> - x, y, z);
>> + p[0], p[1], p[2]);
>> if(result == NULL) interp_error ++;
>> Py_XDECREF(result);
>> + for (int i = 0; i < 3; ++i) lo[i] = p[i];
>> }
>>
>
> Is this a different bug? Was the tap preview wrong?
>
>
No, rotate_and_translate is moved into C as well, thus all method with
XY movement must change.
> I think moving the arc generation code is terrific. What kind of
> speedup do you see?
>
>
Noticable :)
Don't have any numbers yet...
Thanks,
Alex.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
