Forum Replies Created
-
AuthorPosts
-
alden
MemberMatt,
Here are some things you might want to look at before you do a lot of coding. Please see the github wiki (not the old Mediawiki, which we are going to retire) – which should be pretty up-to-date.
– JSON Operations. Much more powerful
– Status reports – particularly (1) filtered mode, (2) setting them, and (3) using mpo and ofs as a stable model representation for drawing
– {“qf”:1} command can be used for flushing the planner queue. In combination with ! feedhold you have the tools for some pretty sophisticated jogging
– qv, qvl, qvh as a way to synchronize your gcode sending directly with the planner queue instead of with the serial queue. This wil become much more important later as feed overrides and other “multi-character-in-cycle” commands are implemented
Alden
MemberI should add – be very very careful about noise if you are using limit switches. Noise creeping into the switch lines from a noisy spindle or a washing machine on the same circuit (for example) can cause spurious resets. This is something almost all projects wrestle with – tinyg or no.
MemberIt was a bug. Try reflashing with build 370.04 from either master or edge
Alden
MemberYou may have discovered a bug in the validation code. Let me look at that.
Alden
MemberMatt,
Good news. I’ve been running braid at 1800mm/min and even slightly higher. Let us know how things go.
Alden
MemberIf you are a github user you should be able to edit the page. If you can’t and want to write something up just post it here and I’ll port it over.
Thanks for offering to help
Alden
MemberNow that’s totally strange. I like that it’s fixed, but I don’t like things that fix themselves. The few reset problems we have seen have been HW related, and part of the setup, so it’s not unusual that tightening down the motor connections helped. It’s possible that if a motor lead got disconnected momentarily the back-emf may have had an effect on the board – I don;t have enough to go on to know.
What we have seen – and this is for EVERY controller, not Just TinyG – Is that noisy spindles wreak havoc on the electronics. SPecifically, they flip limit switches due to induced voltages.
I think it makes sense to write both os these up on the (new) wiki.
We have just pushed version 0.95 to Master, and are using the github wiki as documentation.
Alden
MemberWhat version and firmware build are you both running, and do you have limit switches enabled? Was the spindle on when the reset occurred?
MemberLooks like backlash in your mechanical setup. What kind of machine are you running?
Alden
MemberThe way status reports work in 0.95 (now in Master) is that they are requested on (1) any gcode command, (2) at the end of movement and (3) during movement. The minimum interval (si) sets the maximum rate automatic SRs can be generated for any of these triggers – in order to preserve serial bandwidth and UI processing.
There’s more. Rather than explain it all here I refer you to this page that explains status reports for version 0.95. Most of this is also applicable to 0.94 as well:
https://github.com/synthetos/TinyG/wiki/Status-Reports
MemberI’d like to find a better way to handle this edge case, but for now it is what it is. It’s tough to figure out what the exact correct thing to do is when the machine hits the lower limit of it’s resolution and/or the upper limit of its speed. Thanks for pointing this out and looking into it. Please let me know how you project goes.
Alden
MemberSorry for the delay – I jst got time to test your case.
You have discovered an edge case. The behaviours you see is notmal, and is the result of the requested move being too small to fit into the available time to move. This is why at f100 you get a step for x0.01mm, and at f10000 you do not. AT f10000 the move is “saved up” so that when sufficient movement is presented all the movement is performed at once. THis is how TinyG handles the “too short to draw”: case
Alden
MemberTinyG does have status reports for exactly this issue. These are described on the github wiki
MemberThe xvm sets the speed on G0 movement. So it should be something that actually works. Set your xvm so you get no stalls. I assume you are running a belt-driven machine given tr=40 and xvm=50000. Perhaps you can post your $1 and $x settings and I can take a closer look. There really is no reason that small moves should not move. THe smallest move that is normally not moved is about 1/100th of a mm, or < 1/1000th of an inch. I have never seen a machine react this way for larger numbers. I still suspect there is something wrong in the settings.
Memberxvm at 2,000,000 is way to fast. What I recommend you do is run $defa=1
This will reset your machine to default values. You should not be experiencing these behaviors. I suspect the settings are out of order.
-
AuthorPosts
