Hi Chris, I had the time to get a closer look to your work.
I was very astonished on executing the testcase for the failure. Looking at your work, it seems to me, as if the newly introduced fcode- variable is unrelated to the rest of motion stuff and I doubt, whether this is the right way. Don't know, how linuxcnc could work all the years with that fcode-bug - which I consider fundamental break of concept. As I understand cnc-machining, the f-word specifies the max. velocity of tools motion. So whatever taskplanner does, it has to respect the max. velocity. >From other cnc-controllers I know, that for that reason max. velocity is bound to each motion segment and with this concept, motion executor knows at each time the max. allowed velocity. linuxcnc seems to have broken that concept. Why? - and when? From the beginning? or introduced at later time (misoptimization)? The testcase (3Dchips.ngc with different f-words) shows, that f-word is not bound to the motion segments. So I wonder, how the max. velocity of segments is calculated? Did you fix that calculation too? I don't know, who in linuxcnc is responsible for speed calculations. From my thinking taskmanager should be the one. But could be different. So your changes seem to work, but what about the motion execution? Do they now respect max. velocity? And beside max. velocity from f-word the feed overwrite value should be taken into account too. Function EMC_TRAY_SET_CODE_STATUS::update looks dangerous to me. You added a call to cms->update(fcode), but where is fcode? Looks like a global variable. This access might break threading rules. cms is function parameter. Same should be true for your fcode variable. Once back in time my senior chief developer said: don't use global vars. If I ever see a global var in your code, I'll cut you a finger for each global =:O cheers Reinhard _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
