Forum Replies Created
-
AuthorPosts
-
alden
MemberThe latch move is supposed to stop as soon as the switch clears. The latch backoff value is just there to insure that there is an adequate movement to clear the switch.
I notice zero backoff is zero. I’d recommend it giving it a couple of millimeters. Otherwise your zero is right on the switch and it may fire during normal operation – and you have the switches set for limit as well.
MemberYou might also say none of you other steppers have problems with TinyG 🙂 I can’t really comment on the motor. It might be sensitive to power levels and/or microsteps. Have you played with them? Also, is the step angle set up properly?
MemberYou can run 2 steppers from 1 driver, but it will be at reduced power. The steppers you ere driving are already at the edge of grblShield’s drivers (rated for 2.5 amps). You could experiment with series and parallel configs and see if that works for you. You should be careful of chip heating and may need to fan cool the board.
MemberOK. Let me try to reproduce this when I get back to my shop.
MemberI’m not sure what’s going on. First, levers are less accurate than buttons as there is a lot of variation in the throw. Is the Z latch backoff long enough to always back off the lever? How much travel does it take to always back off the lever? Can you post your Z settings?
MemberThere are a number of ways to do this. Perhaps the best way is by setting up a status report and requesting for it when you want it. It will be returned immediately if it’s a request {“sr”:null}, and all fields in the status report will always be returned (i.e. requests are not filtered). You can either leave auto-generated status reports on, or turn them off {“sv”:0″}
You can set status to report in external units and in the work coordinate system by using the posX variables. This is useful for a DRO style display. Example:
{“sr”:{“line”:true,”posx”:true,”posy”:true,”posz”:true,”vel”:true,”stat”:true}}Alternately, if you are going to be using the status reports for drawing on a screen you might want internal machine format – always in MM and always relative to the homed position. The offsets and units are useful if you want both a drawing and a DRO, as you can use the current offsets and the units to compute the values that show in the DRO. ‘t’ is a shorthand for true. Example:
{“sr”:{“line”:t,”mpox”:t,”mpoy”:t,”mpoz”:t,”ofsx”:t,”ofsy”:t,”ofsz”:t,”vel”:t, “unit”:t,”stat”:t}}See the status reports page for details:
https://github.com/synthetos/TinyG/wiki/Status-ReportsYou can also just ask for the values you want:
{“posx”:null}
{“posy”:null}
{“posz”:null}Or ask for the pos (or mpo) group. You will get all 6 axes:
{“pos”:null}MemberThanks for doing these tests. I’m glad the issue is closed for you.
It’s a known property (of Gcode) that radius arcs suffer from accuracy errors; which is the reason center arcs are always recommended. Usually this is only obvious on arcs with larger angular travel – and error blows up completely for 360 degree arcs (cannot be drawn).
Separately, center arcs are supposed to be specified with the center falling on the normal line bisecting the chord spanning the arc endpoints. As mentioned before, there is some tolerance in the arc algorithm if this is not exactly true. If the center is too far off the line the arc will err out with a specification error. So it’s possible that the differences between R and IJ arcs is due to the fact that the R will (or should) compute the exact centerline and the IJ center may be off. I don’t know if this is happening here.
What angles are you testing? Can you copy and paste some Gcode? I’d like to know if the R arcs are within tolerance or if I still have work to do on R arc generation.
Thanks
October 22, 2013 at 12:58 pm in reply to: Could Jerk be causing my extended ShapeOko to miss steps? #4849MemberEither should do. It’s easier to use the hex but being able to compile your own definitely has its advantages. Please heed caveats on the use of the dev branch. It’s EXPERIMENTAL. I hope to push these changes to edge in the next week or so.
MemberThe hex file you loaded (build 396.03) is the current file in the dev branch. Dev is used for development and testing. Once things are relatively stable in dev they are moved to edge, where they are tested some more, then finally to master for general release.
The hex you got was not a “debug” hex, per se – in that it did not have any extra debugging code – that’s just where the complier puts things.
Build 396.03 should actually be pretty stable as I’ve been incrementally moving things along in dev. You should stick with that until there’s an edge push – probably some time in the next few weeks. Please let me know if you have any problems with it.
MemberI ran your test on build 380.02, and 380.08, which is the current master branch. Both fail the way you have experienced. The test I ran that worked was on the development branch – build 396.03. So you ave discovered a bug in the earlier revisions. We can walk you through a firmware upgrade or swap out your board.
October 21, 2013 at 6:53 pm in reply to: Could Jerk be causing my extended ShapeOko to miss steps? #4841MemberTry dev branch build 396.03 and see if that doesn’t work better for you. I’ve tested it and it seems OK.
MemberTry returning to g0 x0 y0 before attempting the negative arc. Entering the second arc command was trying to draw a 360 degree arc in radius mode – same start and end points. Radius mode is not supposed to be used for arcs more than about 180 degrees, or they lose too much accuracy. The system tries to compensate the best it can, but at some point it gives up and throws an arc specification error.
MemberG3 should work with negative Rs. Can you post or make available the Gcode you are having problems with and some description of the problem?
@Makerboost : For a discussion of negative R see here:
http://www.cnccookbook.com/CCCNCGCodeArcsG02G03.htmOctober 17, 2013 at 3:00 pm in reply to: Could Jerk be causing my extended ShapeOko to miss steps? #4808MemberThanks for the heads up.
I’ve been traveling so it’s been hard to reproduce this, but I noticed some rough movement in the file(s) you gave me. I’ve been diagnosing the problem as I have time. I suspect it has to do with some of the very short arcs being output by Cambam. You might also try disabling arc output from CamBam, which I think it can do.
I’d like to find a way to run these files even if the Cambam arc output causes problems., It’s probably some corner case that hasn’t been dealt with. So I’m going to keep diagnosing this.
MemberYou probably have the right file. The confusion may be coming from what’s being counted.
– The memory flashed onto the chip is about 100K. AVRdude reports this number
– The Intel hex that contains that information is an ASCII and is about 2.5x
– The HTML is about 800K, and is not usableSo you probably have the right hex file. Just open it in a text editor and see if it looks like what I posted earlier
-
AuthorPosts
