Перечитал немного тему и вдруг обнаружил две вещи. Во первых, оказалось это
Sailenser ненароком подсадил меня на канал Бербраера, за что огромное спасибо! Во вторых, я так и не отчитался о драйверах TB6600, может кому то эта информация будет полезна.
В общем то TB6560 оказались не так уж и плохи, при условии прокладки проводов шпинделя вне гусеницы с остальными проводами,
с тех пор самовольное перемещение не повторялось, оси после работы возвращались в ту же точку. Для моих задач параметров драйверов хватало, правда без запаса, холостые перемещения на тот момент были 1.5 м/мин, МДФ вроде тогда грыз на скорости 800 мм/мин, 1 мм за проход двухзаходной фрезой. Все время напрягал только шум движков на удержании, который проводился винтами и звучал как шипение открытого крана в период отключения воды, уже через пол часа жутко болела голова. В принципе можно было смириться, но TB6600 уже прошли таможню, правда им было суждено пролежать в шкафу еще пол года. Дело в том что с TB6600 оси перестали возвращаться в исходное положение, при чем недоезд зависел напрямую от количества «челночных» перемещений, довольно быстро
был нагуглен подобный вопрос. Тема на тот момент была не такая большая и вопрос разрешился только у одного человека, по его пути я и последовал, суть была в том, что на линии Dir стояла дешевая оптопара которая не успевала переключаться перед следующим шагом и шаг происходил в неверном направлении, при чем изменение логического уровня запаздывало только на одном из фронтов, и ошибка набегала только в одном направлении. И опять засада, радиаторы драйверов перекрывают доступ паяльника к оптопарам и приклеены на мертво, фен, морозилка, растворители, скальпель, отвертка с молотком, оставили только покрошившиеся углы корпуса микросхемы, в итоге радиаторы были кастрированны с помощью отрезной машинки, в несколько заходов, что бы не перегреть микросхемы. Дерьмовые оптопары были заменены на 6N137 навесным монтажом, в один драйвер поставил 6N136 для эксперимента, то же работает, так и оставил.
Но конец был еще далек, ошибка перестала зависеть от направления и количества перемещений, дело в том что одновременно с этими событиями у меня сменился комп на который WinXP уже не вставала. Голая Win7(32bit) же стала проявлять неприятные особенности, во первых она подвисала на долю секунды в самый ответственный момент в связи с чем происходила потеря шагов и порча заготовки, происходило это редко - в среднем раз в 10 дней. Во вторых, что для меня оказалось совсем странным, Win7 оказалась неспособной выдерживать логический уровень на COM порте, который находился на плате расширения, хотя со встроенным COM портом старого компа этой проблемы не было. Вскрылось это после долгой возни с осциллографом, совершенно случайно, я обратил внимание на то, что с нажатой кнопкой E-stop через несколько секунд начинало щелкать реле шпинделя около раза в секунду, хотя на прошлом компе такого не было. Так как про вину семерки я еще не знал, то меня постигло полное смятение, но чтобы окончательно закрыть вопрос я решил на удачу поставить LinuxCNC, каково же было мое удивление когда все эти проблемы исчезли, в процессе этой возни к тому же выяснилось что китаец в инструкции перепутал уровни сигналов, с семеркой в обоих случаях были недоезды, а с LinuxCNC при изменении уровней на соответствующие логике работы контроллера все стало работать без ошибок.
З.Ы. Извиняюсь за многабуков, но думаю это хорошо иллюстрирует то количество геморроя которого можно было избежать если бы я сразу поставил LinuxCNС, особенно учитывая что с интерфейсом Gmoccapy он довольно не плох, вся функциональность которой я раньше пользовался с ним доступна, я потерял разве что в удобстве, для некоторых простых действий приходится переключаться в другие режимы, что поначалу вводит в ступор.