Forum Replies Created
-
AuthorPosts
-
JuKu
Member370.08
MemberSet the status report time longer than your command would take. You’ll get a report right away when TinyG is done with the current command.
Member> be very very careful about noise if you are using limit switches.
That problem is almost totally eliminated by normally closed switch configuration. In other words, the control line is short circuited to ground in normal situation; when the switch activates it opens and the line gets pulled up.
MemberTo me, looks like flex in the tip of your Sharpie.
MemberYour power connector screws are getting loose?
MemberMore a philosophical than practical issue, but a noob would think that the correct thing to do would be scretch time; in other words, use fastest speed that allows the movement, even if slower than specified. Better to be late than in a wrong place?
I’ll keep you updated.
MemberThank you, nothing to worry about it then (not an indication of a more serious issue). As said, this is not a problem at all, I just need to use setting values that work. (Like I could get away with settings that don’t… 🙂 )
MemberSounds like your terminal program only sends CR when you press enter. There probably is a setting that controls if the terminal sends CR, LF or both. IF not, find a terminal program that can do this, most can. (I’m using PuTTY, it has this setting – I think, the wording is kind of obscure.)
MemberCool. I missed the fact that if I set the status interval longer than the movement would really take, I get a message immediately when the machine stops (and there is not a cunfusing message at the end of the interval). Thank you for pointing this out. The more I use the TinyG, the more I like it!
MemberIndeed this is a belt driven machine. I don’t get any stalls on any xvm value; as I noted, the heavy gantry means that the machine is torque limited, so it stalls on large xjm values. Here are the settings:
tinyg[mm] ok> $1
[1ma] m1_map_to_axis 0 [0=X, 1=Y…]
[1sa] m1_step_angle 0.900 deg
[1tr] m1_travel_per_revolution 40.000 mm
[1mi] m1_microsteps 8 [1,2,4,8]
[1po] m1_polarity 0 [0,1]
[1pm] m1_power_management 1 [0,1]
tinyg[mm] ok>
tinyg[mm] ok> $x
[xam] x_axis_mode 1 [standard]
[xvm] x_velocity_maximum 50000.000 mm/min
[xfr] x_feedrate_maximum 10000.000 mm/min
[xtm] x_travel_maximum 300.000 mm
[xjm] x_jerk_maximum 1500000000 mm/min^3
[xjd] x_junction_deviation 0.0500 mm (larger is faster)
[xsm] x_switch_mode 1 [0,1,2,3,4]
[xsv] x_search_velocity -500.000 mm/min
[xlv] x_latch_velocity 100.000 mm/min
[xlb] x_latch_backoff 2.000 mm
[xzb] x_zero_backoff 1.000 mmBy the way, I see the issue on large feedrates with tiny movements, too (// = my comments):
tinyg[mm] ok> f 10000 // too fast for tiny adjustments
tinyg[mm] ok> ?Line number: 0
X position: 0.000 mm // <== At zero
Y position: 0.000 mm
Z position: 0.000 mm
A position: 0.000 deg
Feed rate: 0.000 mm/min
Velocity: 0.000 mm/min
Units: G21 – millimeter mode
Coordinate system: G54 – coordinate system 1
Distance mode: G90 – absolute distance mode
Feed rate mode: G94 – units-per-minute mode (i.e. feedrate mode)
Motion mode: G1 – linear feed
Machine state: Stop
tinyg[mm] ok> x 0.01 // A tiny adjustment
tinyg[mm] ok> ?Line number: 0
X position: 0.000 mm // <== but nothing happens
Y position: 0.000 mm
Z position: 0.000 mm
A position: 0.000 deg
Feed rate: 0.000 mm/min
Velocity: 0.000 mm/min
Units: G21 – millimeter mode
Coordinate system: G54 – coordinate system 1
Distance mode: G90 – absolute distance mode
Feed rate mode: G94 – units-per-minute mode (i.e. feedrate mode)
Motion mode: G1 – linear feed
Machine state: Stop
tinyg[mm] ok> f 1000 // Slower feed. There is a tick on the machine.
tinyg[mm] ok> ?Line number: 0
X position: 0.010 mm // <== And it moved.
Y position: 0.000 mm
Z position: 0.000 mm
A position: 0.000 deg
Feed rate: 0.000 mm/min
Velocity: 0.000 mm/min
Units: G21 – millimeter mode
Coordinate system: G54 – coordinate system 1
Distance mode: G90 – absolute distance mode
Feed rate mode: G94 – units-per-minute mode (i.e. feedrate mode)
Motion mode: G1 – linear feed
Machine state: Stop
tinyg[mm] ok>MemberOk, thank you. I went back to the workshop and I now have internet there, too. 🙂 So, I have now the real numbers. But first, two things: First, this behaviour is not at all a problem to me. I’m driving the machine with my own program, and it is trivial to overcome any known bugs and use g1 for all small movements. But since this might be an indication of a real bug, let’s continue. Second, I’m building a pick and place machine, not a CNC, so movement speed is important.
I re-did the settings from scratch: I first put in the relevant motor parameters (sa=0.9, tr=40, mi=8). The gantry is heavy (heavier than I would like, but the machine design is another story), so the machine is acceleration (torque) limited (Even though the machine does not work yet, I already ordered some motors with more torque to see how fast I can make it. :-/ ). So, next I set jerk so that I don’t get ill effects on acceleration and the machine moves as it should. xjm turned out to be 1,500,000,000. Then, I increased xvm unless I didn’t perceive any faster motions. In other words, my 400mm travel is spent in acceleration and deceleration; xvm is now 50,000. This might still be bigger than it needs to be, this stage was a bit of a guess and I put in a number that I was sure about. Any problem in this method?
With these settings, the effect is smaller, but it is there. Starting from 0 in G0 mode, x 0.4 does not do anything, and ? reports zero position. g1 then causes movement to 0.4.
MemberI did some more experimenting. It seems that there are combination of settings that cause the command to be ignored. I don’t have Internet on my workshop yet, so I might remeber some values wrong, but if I recall correctly, xvm= 2,000,000; xjm= 1,500,000,000; f=1000. Operating from terminal, so “/” means enter.
f 1000 for slow feed.
g0 / x300 / x0 does work, and relatively fast, too. 🙂
x10 does not move, no lights come up. “?” says that machine is still at 0, so it didn’t even try.
g1 (without further commands) moves it to 10, and “?” says it is at 10, too. So, it did remeber where it is supposed to be, but somehow, it thought it couldn’t do it in G0 mode.
f 10000 / x0 does not move either. “?” and no lights indicate, that thisd was suspended, too.
f1000 moves to 0, so again, the machine knew where it should be, and only waited a suitable settings to be able to go there.
Conclusion: There are some limitations on small and fast movements, that are buffered for later, or something like that. Now the question is what these limits are?
December 18, 2012 at 6:42 am in reply to: Hacking the code: Wait for previous command to finish? #3664MemberThanks! I will keep you informed about my progress.
December 18, 2012 at 2:34 am in reply to: Hacking the code: Wait for previous command to finish? #3662MemberNo different than spindle control, other than the need to know that movements are complete. I’m really more concerned about calibration and component height recognition, both which need a probing type function.
-
AuthorPosts
