Forum Replies Created
-
I equipped the Shapeoko with a ghetto DRO:
I am not able to reproduce the issue. Z starts at zero, goes to 2.00 on the first lift, then drops over he Y move. Goes up and down a little during the plunge, then returns to 2.00 at the end. (In reality the signs are reversed due to the caliper setup, and the DRO is not accurate to 0.01 mm, but it’s code and it’s repeatable).
I am beginning to suspect a flash or eeprom problem. Particularly as you can change a value that has nothing to do with the Gcode being received ($ct) and it changes the behavior. A couple of things to try:
– Can you re-flash the board with the latest edge build – build 412.02 and try again?
– Also, if you can post the entire Gcode file somewhere I’ll run it maybe I’ll see the issue in some other part of the file.
When you say Z moves to a different offset is it actually observable as an offset – any of G92, G54 – G59, or is it an “apparent” offset (nonsense word. I just made it up). If I have this correct the observed behavior is that Z just raises up 2.5mm. Can you tell me where in the file this is? I have added line numbers to the 2 files and provided dropbox links here:
https://www.dropbox.com/s/bxyqrah3lqc872m/sparkcrafter_Z_test_1_NUMBERED.gcode
https://www.dropbox.com/s/uoct9sh7dhkwfhk/sparkcrafter_Z_test_2_NUMBERED.gcodeYou can ignore the semicolons in the first file – these are commented out lines. Semi is widely used in the 3DP community for comment lines, so TinyG supports it.
Also, by looking at your settings should I assume the following:
– You have modded the Z axis from the stock 1.25mm threaded rod?
– Your X/Y wheels are different than mine (I use 36.54 travel per rev for X and Y)Lastly, your X jerk is extremely low. Can you try running the snippet with X set higher, perhaps 100 or 500 and see if you get the same results? I have a theory.
Sorry for the late response.
I think Kinen can get you there, but you may need some sort of coordinator for the other items. One main aspect to consider is what is the biggest coordinated domain you need? Is 5 axes enough? Do you need more that that in tight coordination? The other aspect is how many independent motion domains do you need? – i.e. motors or motor groups that do not need to be in lock-step. For example, can manage uncertainty / latency of 10’s of milliseconds.
(This was the problem with our early experiments with PocketNC – we put 2 TinyG’s together to make 6 controlled axes, but the lag between the XYZ controller and the ABC controller was too great, and the tool head ultimately did not track well. But if XYZ motion were independent of ABC motion it would have worked OK).
Right now the v9 in development can handle 5 axes – 6 with extension of coordinated motion. The other “onesy-twosy” axes can be handled with independent motion sub-systems. Then you are left with the issue of integrating these.
Kinen is based on the JSON work we have done, and we are working towards control of multiple motion / sensor domains by routing JSON objects based on inspection of the parent tag (if this makes any sense). See here:
https://github.com/Kinen/Kinen/wiki/Kinen-RESTful-Hardware-Conventions#wiki-advanced-conventionsThis way you can integrate larger systems consisting of independent sub-systems. It makes Kinen scalable to a reasonably large system consisting of loosely coupled motion / sensor domains.
If you are interested in moving this forward we should talk further. Otherwise, just watch this space. (No promises on timing!)
