Sprinter Firmware on OpenPnP

[Jason von Nieda]

Hi folks, I thought I would start a new thread about Sprinter as to
not clutter up the suggestions thread, which is still going strong.

So, I have been working to get Sprinter up and running for a few hours
now and so far I am very impressed. It seems to work very well. For
reference, I don't think it works on 328Ps any more, though. Even with
SD and Arcs turned off, and the buffer set to 1 it would lock up after
the first planner command. I went and bought a Arduino Mega 2560 and
so far it's working great.

I have a few questions so far:

1. Is there any command to explicitly enable the steppers on all axes?
I can use M84 to turn them off, but it seems that Sprinter wants to
only enable them when it gets a command to move one. Problem with that
is that when using ball screws, steppers and micro-stepping, disabling
the drivers can cause the machine to physically lose micro-steps.
OpenPnP is designed to only consider itself to be referenced to home
when the steppers have all been enabled and not disabled since being
enabled.

2. Is the G4 (dwell) command intended to dwell at the instant the
command is received, or when the command is executed from the buffer?
From reading the code it appears that it would sleep immediately upon
being parsed which means that there is no way to know during which
command it would end up dwelling in. Grbl used st_synchronize() to
make sure this didn't happen, but it's not clear to me that something
simular is happening in Sprinter.

3. Does Acceleration override Maximum Acceleration? I noticed that
with the default Acceleration of S1000 T1000 and Maximum Acceleration
at X25 Y25 the machine still accelerated at 1000 but if I change
Acceleration to S25 T25 it accelerates slowly. I would have thought
that Acceleration would be the target acceleration but that no axis
would accelerate faster than it's Maximum Acceleration.

Kliment, if you or anyone else with experience on Sprinter could
answer these I would greatly appreciate it.

Thanks,
Jason

[Richard Spelling]

1 - I thought that was the default. there is a setting in configuration.h
to turn it off. i.e, if no move commend, remove power from the motor. I
use this on Z axis which is screw driven and doesn't need power to hold
the belt in place.

2 - I don't know how it is written, but "dwell" implies "when you get to
this command, wait". you would want it to finish what is in the queue
first. maybe you are thinking "emergency stop"?

3 - I tend to agree with you. when I was tweaking the printer I set it on
a per axis basis, so I don't know what "maximum acceleration" does.

> --
> You received this message because you are subscribed to the Google Groups
> "OpenPnP" group.
> To post to this group, send email to ope...@googlegroups.com.
> To unsubscribe from this group, send email to
> openpnp+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>


--
Visit my online store for solar electronics: http://www.spellingbusiness.com
------------------------------------------------------------------------------
"If at first the idea is not absurd, then there is no hope for it.”-
Albert Einstein

[Kliment Yanev]

On 07/22/2012 11:19 PM, Jason von Nieda wrote:
> Hi folks, I thought I would start a new thread about Sprinter as to
> not clutter up the suggestions thread, which is still going strong.
>
> So, I have been working to get Sprinter up and running for a few hours
> now and so far I am very impressed. It seems to work very well. For
> reference, I don't think it works on 328Ps any more, though. Even with
> SD and Arcs turned off, and the buffer set to 1 it would lock up after
> the first planner command. I went and bought a Arduino Mega 2560 and
> so far it's working great.

Pretty sure someone had it working on a 328. I'll look into it. I don't
have a 328-based arduino easily available, but I can hack one together
as I have the chip.
This catches me at a rather bad time as I'm in another country and won't
be back near my machines for a couple more weeks. I'll get to it at
first opportunity. I'll also see if the local hackerspace has a 328 I
can borrow.

> I have a few questions so far:
>
> 1. Is there any command to explicitly enable the steppers on all axes?
> I can use M84 to turn them off, but it seems that Sprinter wants to
> only enable them when it gets a command to move one. Problem with that
> is that when using ball screws, steppers and micro-stepping, disabling
> the drivers can cause the machine to physically lose micro-steps.
> OpenPnP is designed to only consider itself to be referenced to home
> when the steppers have all been enabled and not disabled since being
> enabled.

There isn't, but I can make one. We've never had that use case before.
As a workaround, move each axis back and forth 0.1mm at the start.
Should I put in an enable command?

> 2. Is the G4 (dwell) command intended to dwell at the instant the
> command is received, or when the command is executed from the buffer?
> From reading the code it appears that it would sleep immediately upon
> being parsed which means that there is no way to know during which
> command it would end up dwelling in. Grbl used st_synchronize() to
> make sure this didn't happen, but it's not clear to me that something
> simular is happening in Sprinter.

That's a bug. It should be fixed in the experimental branch by now, I
believe a pull request from blddk fixed it. I'll check.

> 3. Does Acceleration override Maximum Acceleration? I noticed that
> with the default Acceleration of S1000 T1000 and Maximum Acceleration
> at X25 Y25 the machine still accelerated at 1000 but if I change
> Acceleration to S25 T25 it accelerates slowly. I would have thought
> that Acceleration would be the target acceleration but that no axis
> would accelerate faster than it's Maximum Acceleration.

Acceleration should not override maximum acceleration, but I'm not sure
if there's a bug in the runtime setting code there.

[Kliment Yanev]

On 07/22/2012 11:34 PM, Richard Spelling wrote:
> 1 - I thought that was the default. there is a setting in configuration.h
> to turn it off. i.e, if no move commend, remove power from the motor. I
> use this on Z axis which is screw driven and doesn't need power to hold
> the belt in place.

That's different. Even on axes with no auto-disable, the stepper is not
powered on until the first time it's used. Typically, homing enables all
of them so we haven't needed to do it explicitly.

[Jason von Nieda]

Thank you for the fast response!

> This catches me at a rather bad time as I'm in another country and won't be
> back near my machines for a couple more weeks. I'll get to it at first
> opportunity. I'll also see if the local hackerspace has a 328 I can borrow.

Don't hurry on my account. I have a Mega now and am happy to work with
that. It makes things much easier.

> There isn't, but I can make one. We've never had that use case before. As a
> workaround, move each axis back and forth 0.1mm at the start. Should I put
> in an enable command?

As you mention below, homing will probably solve this problem. I
hadn't gotten to the point of running homing yet, so I didn't run into
that. I think it will do the trick, so probably no need for a special
command.

> That's a bug. It should be fixed in the experimental branch by now, I
> believe a pull request from blddk fixed it. I'll check.

Great, thanks! I'll see if I can merge that in.

[Richard Spelling]

On Sun, July 22, 2012 5:36 pm, Kliment Yanev wrote:
> That's different. Even on axes with no auto-disable, the stepper is not
> powered on until the first time it's used. Typically, homing enables all
> of them so we haven't needed to do it explicitly.
>>

Ah. That makes sense. Maybe Jason should be homing as the first step?
(which you have to do in a production environment anyway)

[Kliment Yanev]

On 07/22/2012 11:41 PM, Jason von Nieda wrote:
> Thank you for the fast response!
>
>> This catches me at a rather bad time as I'm in another country and won't be
>> back near my machines for a couple more weeks. I'll get to it at first
>> opportunity. I'll also see if the local hackerspace has a 328 I can borrow.
> Don't hurry on my account. I have a Mega now and am happy to work with
> that. It makes things much easier.

It really does. The extra pins do come in handy. (I had it running 13
hobby servos in parallel on Splotbot)

>> There isn't, but I can make one. We've never had that use case before. As a
>> workaround, move each axis back and forth 0.1mm at the start. Should I put
>> in an enable command?
> As you mention below, homing will probably solve this problem. I
> hadn't gotten to the point of running homing yet, so I didn't run into
> that. I think it will do the trick, so probably no need for a special
> command.

Added "M84 T" to experimental branch. It enables all steppers.

>> That's a bug. It should be fixed in the experimental branch by now, I
>> believe a pull request from blddk fixed it. I'll check.
> Great, thanks! I'll see if I can merge that in.
>

Yes, definitely fixed in experimental branch. You might want to work
from that branch anyhow.

[Jason von Nieda]

Thanks Kliment, I switched to experimental and it's all working great!

Jason