alden

Yes, the steppers do get hot, that’s normal. But it does have to be manageed, and it sounds like yours might be too hot.

The maximum torque for a stepper is at standstill; and hence the maximum power draw. And heat. In addition to the motors heating up, the stepper chips also heat up. They will go into thermal shutdown if they are too hot, but they don’t know anything about motor heating, so there is no shutoff if the motors overheat.

There are 2 things here: One, you might have your motor current set too high from the potentiometers. Try lowering it. You wat to find the balance point where the motion is powerful enough to maintain motion without skipping, but not over-powered to overheat the motors at standstill and low speeds.

The second thing is not quite out yet, but watch for it. In the edge branch we have made some changes to the power management so that motor power can be shut off after a user-defined time if idle. This doesn’t change the heating when you are doing an hour-long run, but it makes sure the machine doesn;t stay powered up when idle.

• This reply was modified 11 years, 3 months ago by alden.

It is correct. The calculated velocity for G0 is the vector sum of all the velocities in the move. FOr G1 (and G2, G3) the velocity is limited to the feedrate specified in the F word. Try G1 F250 x100 y100 and the velocity will not go above 250.

Thanks for the explanation. I have a few further questions:
– Is the reason for this operation to “read” the initial head position somehow?
– Is the positioning done using the motors or manually somehow?
– Is the machine already zeroed when you position the head, or is the zero not known? Can it be known?

I guess it’s possible to report the machine position immediately prior to the zero reset — in fact, I think a status report will do this for you. What I don;t know is if this is the position AT the zero point, or immediately before it reaches the zero point. I’d have to look at the code to validate this. If this is nto the behavior I’d look into ho to make sure that status reports are always sent with the final axis value. If you are using status reports I recommend using JSON mode and filtered status reports.

Also, are you aware of G28 / G30 behaviors? These might be of help. Of course, the reference point for G28 / G30 resets when you home, so it might not be useful to you.

Homeing always sets zero. But depending on what you are trying to accomplish perhaps there’s another way. You might be able to use the work coordinate systems to set a “non-zero” location. What are you trying to do?

We are actually working on ways of just importing JSON files to select defaults. Please “watch this space” for developments.

What are you using to drive the board?

I have been able to run the file successfully about 10 times. Can you please try disabling your switches? Just set them all to zero. You might also try dry running the file w/o the solenoid power enabled. Let’s just verify the execution of the Gcode file itself.

BTW, -0.000 is OK. What you are seeing is a very small negative floating point number rounded to 3 positions.

Great news. Let us know how we can support you in this.

As for synchronization, this is a topic that a lot of people have struggled with, not just with TinyG, but with other systems as well. Things are not too hard if you are moving slowly, but as the move speeds and data rates increase it gets more challenging.

The short answer to your question is – Use the queue reports. We are enhancing them, and I welcome you to join the TinyG dev group and join the discussion. Please see the following topic, and in particular the post I did on 7/9.

https://groups.google.com/forum/?hl=en#!topic/devtinyg/uB3BOSdtEuc

We will be working rather quickly, so please stay tuned. When we get things where we want them we’ll document everything on the wiki.

Alden