Update on firmware / Grbl

[Jason von Nieda]

Hi folks,

A quick update regarding firmware: After running into some problems with Sprinter and Marlin (see Note 1 below) I ended up going back to Grbl. I grabbed the latest branch of Grbl, integrated our C axis code, added better home switch support, fixed some bugs, added support for the Arduino MEGA2560, added support for enabling and disabling the stepper drivers and probably a few other things I am forgetting and it is now released at https://github.com/openpnp/grbl

I have been running this firmware, minus the most recent changes for a few days now and it seems very solid. This is the firmware I am going with for now. There is one known bug where C axis moves can be incredibly slow due to the big difference in steps per degree and steps per mm but I am working on a fix for this tonight.

Moving forward, I am looking at Smoothie and TinyG as possible "full package" solutions. TinyG seems further along than Smoothie, and as far as I can tell it meets all oury current needs but it is based on a 32 MHz chip. Smoothie still needs support for some of the features we require, but it's based on a very powerful platform and I think it will catch up quickly. I'll be getting one of each to do some testing, and will more than likely write OpenPnP drivers for both.

So, for now, our modified Grbl on MEGA2560 or ATmega328p (See Note 2) is the recommended motion platform. The GrblDriver has been updated to work with this new version of Grbl and I am successfully running jobs on my development machine with both.

Note 1: Regarding Sprinter and Marlin: I ran into some problems where I would get a very odd slowdown on random moves and I was not able to figure out why. Looking back, I think it's possible I was just trying to push too many steps per second, so it's possible this wasn't a problem with Sprinter at all. I'll be going back eventually to check this out.

Note 2: Grbl requires that step and direction for all axes be on the same port. For four axes this is a full 8 bit port. The Arduino with a 328p does not have a full 8 bit port available, so if you want to use this Grbl with 4 axes on an Arduino with a 328p you'll need to hack it. A 328p breakout board, on the other hand, would be fine because you could use all of PORTB.

Thanks,

Jason

[mcgyvr]

Excellent work Jason.. I'm looking forward to trying it this weekend.
Which branch do we download/use? master I assume..

[Jason von Nieda]

Yep, the master branch. Thanks for the reminder - I'll delete the other unused ones from our repo.

On Wed, Aug 8, 2012 at 4:19 AM, mcgyvr <mcgyv...@gmail.com> wrote:

Excellent work Jason.. I'm looking forward to trying it this weekend.
Which branch do we download/use? master I assume..

--
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.
To view this discussion on the web visit https://groups.google.com/d/msg/openpnp/-/9t3-NBEt1W4J.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Karl Backström]

Hi Jason,

while building a pick&place head for my Shapeoko CNC machine I updated
my electronics with a Arduino MEGA board running your grbl.
To get the machine to home correctly I had to add this part to limits.cpp

@@ -45,13 +45,16 @@ static void homing_cycle(bool x_axis, bool y_axis,
bool z_axis, bool c_axis, boo
if (z_axis) { out_bits |= (1<<Z_STEP_BIT); }
if (c_axis) { out_bits |= (1<<C_STEP_BIT); }

+ // Fix logic for homing. Only X,Y move in negative direction. Z
moves in positive direction
+ out_bits ^= (1<<Z_DIRECTION_BIT);
+
// Invert direction bits if this is a reverse homing_cycle
if (reverse_direction) {
out_bits ^= DIRECTION_MASK;

This was because Z was moving downward (negative direction on my machine).
Now I wondering, on your machine is negative Z down or up?

Cheers,
Karl

--
Blog: http://www.akafugu.jp/blog/
Twitter: akafuguJP
Facebook: http://www.facebook.com/akafugu

[Jason von Nieda]

Hi Karl,

My machine does not yet have a Z homing switch, so I have it disabled for now. That explains the bug :)

My machine moves negative down. Here is an overview of the expected machine coordinate systems: http://code.google.com/p/openpnp/wiki/UserManual#Coordinates

Thanks for the patch. I will include similar logic - I'll just make it so the user can configure which direction to move each axis for homing.

Jason

[Karl Backström]

Hi,

On Thu, Aug 16, 2012 at 3:20 PM, Jason von Nieda <ja...@vonnieda.org> wrote:
> Hi Karl,
>
> My machine does not yet have a Z homing switch, so I have it disabled for
> now. That explains the bug :)

Ah, yes I did see that homing Z was disabled, thanks for the
clarification. I had another bug that moved the wrong axis during
homing (Move X and Y when Z was homing), I patched it by commenting
out the following line (had to do the same with official grbl):
// Apply the global invert mask
- out_bits ^= settings.invert_mask_stepdir;
+ // out_bits ^= settings.invert_mask_stepdir;

> My machine moves negative down. Here is an overview of the expected machine
> coordinate systems:
> http://code.google.com/p/openpnp/wiki/UserManual#Coordinates

Hmm,
"the Y axis moves negative back to positive ahead", this is opposite
from most CNCs it seems, which moves negative towards you and positive
away from you, so homing X,Y is in the front-left corner.

> Thanks for the patch. I will include similar logic - I'll just make it so
> the user can configure which direction to move each axis for homing.

Thanks, you might also want to look at the description of these:
$8 = 17 (step port invert mask. binary = 00010001)
$9 = 0 (step port invert mask. binary = 00000000)

I thought first that $9 was for C-axis but turns out to be for limit
switches (neat though!).

/ Karl

[Jason von Nieda]

Ah, yes I did see that homing Z was disabled, thanks for the
clarification. I had another bug that moved the wrong axis during
homing (Move X and Y when Z was homing), I patched it by commenting
out the following line (had to do the same with official grbl):
   // Apply the global invert mask
-  out_bits ^= settings.invert_mask_stepdir;
+  // out_bits ^= settings.invert_mask_stepdir;

Thanks, I will take a look.

 

> My machine moves negative down. Here is an overview of the expected machine
> coordinate systems:
> http://code.google.com/p/openpnp/wiki/UserManual#Coordinates

Hmm,
"the Y axis moves negative back to positive ahead", this is opposite
from most CNCs it seems, which moves negative towards you and positive
away from you, so homing X,Y is in the front-left corner.

We're saying the same thing, I think - I just seem to be saying it poorly. I've attached a diagram to clarify, and will post it to the Wiki. Let me know if that matches your expectations.

OpenPnP is designed so that home can be anywhere, at any coordinate, but in general 0, 0, 0, 0 will be with the head as close to you as possible, to the left, as high as possible with the vector of the rotation axis pointing along your line of sight.

> Thanks for the patch. I will include similar logic - I'll just make it so
> the user can configure which direction to move each axis for homing.

Thanks, you might also want to look at the description of these:
$8 = 17 (step port invert mask. binary = 00010001)
$9 = 0 (step port invert mask. binary = 00000000)

I thought first that $9 was for C-axis but turns out to be for limit
switches (neat though!).

Yep, I'll include a new runtime configuration option. C axis is also included in each of the $8 and $9, depending on how you've set up your output bits.

[Karl Backström]

On Thu, Aug 16, 2012 at 4:17 PM, Jason von Nieda <ja...@vonnieda.org> wrote:
>> Ah, yes I did see that homing Z was disabled, thanks for the
>> clarification. I had another bug that moved the wrong axis during
>> homing (Move X and Y when Z was homing), I patched it by commenting
>> out the following line (had to do the same with official grbl):
>> // Apply the global invert mask
>> - out_bits ^= settings.invert_mask_stepdir;
>> + // out_bits ^= settings.invert_mask_stepdir;
>
>
> Thanks, I will take a look.
>
>>
>>
>> > My machine moves negative down. Here is an overview of the expected
>> > machine
>> > coordinate systems:
>> > http://code.google.com/p/openpnp/wiki/UserManual#Coordinates
>>
>> Hmm,
>> "the Y axis moves negative back to positive ahead", this is opposite
>> from most CNCs it seems, which moves negative towards you and positive
>> away from you, so homing X,Y is in the front-left corner.
>
>
> We're saying the same thing, I think - I just seem to be saying it poorly.
> I've attached a diagram to clarify, and will post it to the Wiki. Let me
> know if that matches your expectations.

Yes we are, I got confused by the "back" but now when I read it again
I can see that we are indeed saying the same thing. The picture really
helps :)

> OpenPnP is designed so that home can be anywhere, at any coordinate, but in
> general 0, 0, 0, 0 will be with the head as close to you as possible, to the
> left, as high as possible with the vector of the rotation axis pointing
> along your line of sight.

Cool!

>>
>> > Thanks for the patch. I will include similar logic - I'll just make it
>> > so
>> > the user can configure which direction to move each axis for homing.
>>
>> Thanks, you might also want to look at the description of these:
>> $8 = 17 (step port invert mask. binary = 00010001)
>> $9 = 0 (step port invert mask. binary = 00000000)
>>
>> I thought first that $9 was for C-axis but turns out to be for limit
>> switches (neat though!).
>
>
> Yep, I'll include a new runtime configuration option. C axis is also
> included in each of the $8 and $9, depending on how you've set up your
> output bits.

Ah, but of cause. I need to check my settings as I copied them from my
working general grbl. Thanks for the information.

/ Karl

[x.l...@gmail.com]

Hi,

 

I'm currently trying to use the Arduino Mega2560 for a DIY pick-and-place machine and was wondering if there is a good stepper motor shield that allows 4 or more stepper motors to be run at the same time. I am new to this and cannot find anything online. Any help would be appreciated.

 

Regards,

Lee

[Paul Jones]

Look at the driver boards for 3d printers – most of them are suitable. I’ve pulled the driver board off my Ultimaker (which uses an Arduino Mega2560)  and put it on my PnP machine while I wait for my smoothieboard to arrive.

 

 

Paul.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/openpnp/-/DpC1w9EszQMJ.

[Riley Porter]

Paul,

Disclaimer: my partner and I created and run this opensource controller.

While its not a shield our board does support rotational axis as well as slaving and linar axis.  We have some PWM code working now too.  Limit switches, homing switches and high speed performance.  Its much faster than the Arduino mega as well.

https://github.com/synthetos/TinyG/wiki

Oh and you can talk to it all via JSON if you want too.

g0x19 

yields this:

{"r":{"gc":"G0X19","f":[1,0,6,6964]}}

{"sr":{"posx":0.000,"vel":0.275,"momo":0,"stat":5}}

{"sr":{"posx":0.016,"vel":27.548}}

{"sr":{"posx":0.127,"vel":110.193}}

{"sr":{"posx":0.401,"vel":239.738}}

{"sr":{"posx":0.948,"vel":406.543}}

{"sr":{"posx":1.733,"vel":525.000}}

{"sr":{"posx":2.619,"vel":588.361}}

{"sr":{"posx":3.611,"vel":600.000}}

{"sr":{"posx":4.609}}

{"sr":{"posx":5.557}}

{"sr":{"posx":6.555}}

{"sr":{"posx":7.504}}

{"sr":{"posx":8.502}}

{"sr":{"posx":9.500}}

{"sr":{"posx":10.448}}

{"sr":{"posx":11.446}}

{"sr":{"posx":12.395}}

{"sr":{"posx":13.393}}

{"sr":{"posx":14.391}}

{"sr":{"posx":15.339}}

{"sr":{"posx":16.332,"vel":590.083}}

{"sr":{"posx":17.267,"vel":529.477}}

{"sr":{"posx":18.018,"vel":420.868}}

{"sr":{"posx":18.578,"vel":256.267}}

{"sr":{"posx":18.873,"vel":115.771}}

{"sr":{"posx":18.981,"vel":33.333}}

{"sr":{"posx":19.000,"vel":0.275}}

{"sr":{"posx":19.000,"vel":0.000,"stat":3}}

The sr's report the machines position in the move every 200ms.  There are a bunch of things you can put in the status reports but the only ones that will come back are the things that have changed.

I want to start on our own DIY pick in place.  Not sure where to start here.

Riley

[Paul Jones]

That’s a nice board you’ve made, I’ve heard good things about it. I was thinking about getting one myself but I wanted a Cortex M3/4 based MCU. After programming 8bit AVRs for years, and now having moved to 32bit ARM Cortex M based chips I don’t think I could ever go back!

 

Paul.

[Daniel Dumitru]

Hi,

I have made a board based on LPC1768 and a 4X TB6560.

Board with Cortex will run smothie.  As I have heard from Vincent (I think that he it's father of smoothie) max pulse speed it's somwhere at 70K pulses /sec.

In this aspect TinyG it's scoring very well !!

Daniel

[Lizerd]

the TB6560 datasheet says the max step clock is 15Khz so if the controller can provide 70K pulses/sec it wont be to any use. or is the value for all the axis combined ??
4x15KHz = 60KHz

Have i missed something ??

[Arthur Wolf]

Current smoothie edge can step up to about 120khz.

The new accel branch when done should go higher than that, with acceleration computed every step instead of at a fixed rate ( 5khz works fine in current edge ).
That's not a lot of use without high microstepping or special cases like that though.

2013/3/4 Daniel Dumitru <dand...@gmail.com>

--
Courage et bonne humeur.

[Daniel Dumitru]

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/openpnp/-/Af-3UIvBMbEJ.

[Daniel Dumitru]

@Lizerd - you are absolutely right. But that's what I had in house. In the future I will make a better driver and those will be aligned.

Arthur it's absolutely right. It's no point to go with microstepping lower than 1/10 - 1/16. Starting from this than it's no point also for very high step speed.

Daniel

[Ami]

A little bit of math won't hurt.

Let's say a gantry wtih 200 steps per turn motor, 16 microstepping, and 50mm per turn pulley/belt, 
that gives 0,015625 mm / step resolution.

At 15khz that gives 234 mm per seconds, like 10 inches per sec.
At 120khz, that gives 1875 mm per seconds!!! almost 2 yards per sec!
Turn off the micro stepping, you'd get 30m/s. You wanna shot the chip to the moon?

I think the limiting factor will be electro-mechanical, not the controller.

[Ami]

What would be interesting, is if we could control the microstepping from the software.
So for discrete components we can run without micro-stepping (faster), and on the fine-pitch part we turn on the microstepping.

I think that's what the chinese machine does.

[Daniel Dumitru]

Well , I need to tell you that all "polite" stepper motor drivers do that !

IT's often called step morphing. 

The reason it's not that one that you have mentioned. It's about squeezing from motor every Nm possible.

At micro-stepping movement on high speed pulse it seems that torque it's low . And driver automatically move on full step mode and divides accordingly step input signal.

Since it's implemented in many drivers probably it worth. But it cannot be implemented only on interpolation engine without feedback from driver.

BR
Daniel  

To view this discussion on the web visit https://groups.google.com/d/msg/openpnp/-/4GKC90SExnUJ.

[Ami]

Oh I beg your pardon!
My linuxcnc + TB6560 is not very "polite" then, or is it the TB6560 who does the morphing?

I was thinking about how to overcome the high clockrate that seems to be the problem with different controllers.
By lowering the microstepping, we can achieve higher speed with lower clockrate.
And if the resolution achieved is within the need, then why bother with microstepping?

For example, 
With 50mm pulley, 200 steps/rotation motor, we can get 0,25 mm resolution without micro-stepping.
That in theory is enough to place 0603 parts. (0,8mm width)
It would be difficult to find the right alignment though.

[Jason von Nieda]

Microstepping is often used, even when not needed for resolution, because it massively reduces vibration.

To view this discussion on the web visit https://groups.google.com/d/msg/openpnp/-/aKyfO0gltWwJ.

[Arthur Wolf]

2013/3/4 Ami <sukar...@gmail.com>

Oh I beg your pardon!
My linuxcnc + TB6560 is not very "polite" then, or is it the TB6560 who does the morphing?

I was thinking about how to overcome the high clockrate that seems to be the problem with different controllers.
By lowering the microstepping, we can achieve higher speed with lower clockrate.
And if the resolution achieved is within the need, then why bother with microstepping?

Microstepping is not for resolution. It's for more silent, smoother, less chunky movement, and to avoid resonnance issues.

If you've seen a half-step driver running, you know what I'm talking about

To view this discussion on the web visit https://groups.google.com/d/msg/openpnp/-/aKyfO0gltWwJ.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ami]

True true, you guys are all correct.

But some of us is not so lucky to end up with TB6550 + linux, so the limit is 15khz.
With 200 steps and microstepping, well, I did the math up there. It's slow.
To achieve better speed, I have no other choice but lowering the microstepping, and the result is not as bad;
it sounds horrible though, like dot matrix printer.

Eh, btw, smoothie looks very interesting, is it working well? Maybe it's time to upgrade my controllers.
PJ, can you let us know how it goes when your smoothie arrives?

[Wayne C. Gramlich]

All:

Here's are some useful URL's on mid band instability,
anti-resonance damping, microstepping, etc.:


http://www.microchip.com/stellent/groups/SiteComm_sg/documents/DeviceDoc/en543050.pdf


http://www.geckodrive.com/support/step-motor-basics/mid-band-instability.html

http://www.geckodrive.com/how-morphing-works

By the way, there is a great deal of good information on the
geckodrive web site. Mariss Freimanis (the gekcodrive owner,
designer, etc.) has forgotten more about drive systems than
I will ever know.

Regards,

-Wayne

> That�s a nice board you�ve made, I�ve heard

> good things about it. I was thinking about
> getting one myself but I wanted a Cortex
> M3/4 based MCU. After programming 8bit AVRs
> for years, and now having moved to 32bit ARM

> Cortex M based chips I don�t think I could
> ever go back!____
>
> __ __
>
> Paul.____
>
> __ __
>
> *From:*ope...@googlegroups.com
> [mailto:ope...@googlegroups.__co__m] *On
> Behalf Of *Riley Porter
> *Sent:* Monday, 4 March 2013 2:20 AM
>
>
> *To:* ope...@googlegroups.com
> *Subject:* Re: [OpenPnP] Re: Update on
> firmware / Grbl____
>
> __ __
>
> *Paul,*____
>
> __ __
>
> *Disclaimer: my partner and I created and
> run this opensource controller.*____
>
> __ __

>
> While its not a shield our board does
> support rotational axis as well as slaving
> and linar axis. We have some PWM code
> working now too. Limit switches, homing
> switches and high speed performance.

> <http://www.youtube.com/watch?v=Om0wTqFA-Dw>

> Its much faster than the Arduino mega as

> well.____
>
> https://github.com/synthetos/__T__inyG/wiki
> <https://github.com/synthetos/TinyG/wiki>____
>
> __ __

>
> Oh and you can talk to it all via JSON if

> you want too.____
>
> __ __
>
> g0x19 ____
>
> __ __
>
> yields this:____
>
> {"r":{"gc":"G0X19","f":[1,0,6,____6964]}}____
>
> {"sr":{"posx":0.000,"vel":0.__27__5,"momo":0,"stat":5}}____
>
> {"sr":{"posx":0.016,"vel":27.__5__48}}____
>
> {"sr":{"posx":0.127,"vel":110.____193}}____
>
> {"sr":{"posx":0.401,"vel":239.____738}}____
>
> {"sr":{"posx":0.948,"vel":406.____543}}____
>
> {"sr":{"posx":1.733,"vel":525.____000}}____
>
> {"sr":{"posx":2.619,"vel":588.____361}}____
>
> {"sr":{"posx":3.611,"vel":600.____000}}____
>
> {"sr":{"posx":4.609}}____
>
> {"sr":{"posx":5.557}}____
>
> {"sr":{"posx":6.555}}____
>
> {"sr":{"posx":7.504}}____
>
> {"sr":{"posx":8.502}}____
>
> {"sr":{"posx":9.500}}____
>
> {"sr":{"posx":10.448}}____
>
> {"sr":{"posx":11.446}}____
>
> {"sr":{"posx":12.395}}____
>
> {"sr":{"posx":13.393}}____
>
> {"sr":{"posx":14.391}}____
>
> {"sr":{"posx":15.339}}____
>
> {"sr":{"posx":16.332,"vel":__590__.083}}____
>
> {"sr":{"posx":17.267,"vel":__529__.477}}____
>
> {"sr":{"posx":18.018,"vel":__420__.868}}____
>
> {"sr":{"posx":18.578,"vel":__256__.267}}____
>
> {"sr":{"posx":18.873,"vel":__115__.771}}____
>
> {"sr":{"posx":18.981,"vel":33.____333}}____
>
> {"sr":{"posx":19.000,"vel":0.__2__75}}____
>
> {"sr":{"posx":19.000,"vel":0.__0__00,"stat":3}}____
>
> __ __

>
> The sr's report the machines position in the
> move every 200ms. There are a bunch of
> things you can put in the status reports but
> the only ones that will come back are the

> things that have changed.____
>
> __ __

>
> I want to start on our own DIY pick in

> place. Not sure where to start here.____
>
> __ __
>
> __ __
>
> Riley____
>
> __ __

>
> On Sun, Mar 3, 2013 at 4:45 AM, Paul Jones

> <pa...@pauljones.id.au> wrote:____

>
> Look at the driver boards for 3d

> printers � most of them are suitable.
> I�ve pulled the driver board off my

> Ultimaker (which uses an Arduino
> Mega2560) and put it on my PnP machine
> while I wait for my smoothieboard to

> arrive.____
>
> ____
>
> ____
>
> Paul.____
>
> ____
>
> *From:*ope...@googlegroups.com
> [mailto:ope...@googlegroups.__co__m] *On
> Behalf Of *x.l...@gmail.com
> *Sent:* Sunday, 3 March 2013 8:39 PM
> *To:* ope...@googlegroups.com
> *Subject:* Re: [OpenPnP] Re: Update on
> firmware / Grbl____
>
> ____
>
> Hi, ____
>
> ____

>
> I'm currently trying to use the Arduino
> Mega2560 for a DIY pick-and-place
> machine and was wondering if there is a
> good stepper motor shield that allows 4
> or more stepper motors to be run at the
> same time. I am new to this and cannot
> find anything online. Any help would be

> appreciated.____
>
> ____
>
> Regards,____
>
> Lee____

>
>
> On Thursday, August 16, 2012 12:44:26 AM

> UTC-7, Karl Backstr�m wrote:____

>
> On Thu, Aug 16, 2012 at 4:17 PM,
> Jason von Nieda <ja...@vonnieda.org>
> wrote:
> >> Ah, yes I did see that homing Z
> was disabled, thanks for the
> >> clarification. I had another bug
> that moved the wrong axis during
> >> homing (Move X and Y when Z was
> homing), I patched it by commenting
> >> out the following line (had to
> do the same with official grbl):
> >> // Apply the global invert mask
> >> - out_bits ^=
> settings.invert_mask_stepdir;
> >> + // out_bits ^=
> settings.invert_mask_stepdir;
> >
> >
> > Thanks, I will take a look.
> >
> >>
> >>
> >> > My machine moves negative
> down. Here is an overview of the
> expected
> >> > machine
> >> > coordinate systems:
> >> >

> http://code.google.com/p/__openp__np/wiki/UserManual#__Coordinates

> PM, Karl Backstr�m <back...@akafugu.jp>

> https://groups.google.com/d/__ms__g/openpnp/-/9t3-NBEt1W4J
> <https://groups.google.com/d/msg/openpnp/-/9t3-NBEt1W4J>.
>
> >> >> >> For more options, visit
> https://groups.google.com/__grou__ps/opt_out
> <https://groups.google.com/groups/opt_out>.

>
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> > --
> >> >> > 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/__grou__ps/opt_out
> <https://groups.google.com/groups/opt_out>.

>
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Blog:
> http://www.akafugu.jp/blog/
> >> >> Twitter: akafuguJP
> >> >> Facebook:

> http://www.facebook.com/__akafug__u

> <http://www.facebook.com/akafugu>
> >> >>
> >> >> --
> >> >> 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/__grou__ps/opt_out
> <https://groups.google.com/groups/opt_out>.

>
> >> >>
> >> >>
> >> >
> >> > --
> >> > 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/__grou__ps/opt_out
> <https://groups.google.com/groups/opt_out>.

>
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Blog: http://www.akafugu.jp/blog/
> >> Twitter: akafuguJP
> >> Facebook:

> http://www.facebook.com/__akafug__u

> <http://www.facebook.com/akafugu>
> >>
> >> --
> >> 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/__grou__ps/opt_out
> <https://groups.google.com/groups/opt_out>.

>
> >>
> >>
> >
> > --
> > 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/__grou__ps/opt_out
> <https://groups.google.com/groups/opt_out>.

>
> >
> >
>
>
>
> --
> Blog: http://www.akafugu.jp/blog/
> Twitter: akafuguJP
> Facebook:

> http://www.facebook.com/__akafug__u
> <http://www.facebook.com/akafugu> ____

>
> --
> You received this message because you
> are subscribed to the Google Groups
> "OpenPnP" group.
> To unsubscribe from this group and stop
> receiving emails from it, send an email
> to openpnp+u...@googlegroups.com.
> To post to this group, send email to
> ope...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/__ms__g/openpnp/-/DpC1w9EszQMJ
> <https://groups.google.com/d/msg/openpnp/-/DpC1w9EszQMJ>.
> For more options, visit
> https://groups.google.com/__grou__ps/opt_out
> <https://groups.google.com/groups/opt_out>.
>
> ____

>
> --
> You received this message because you
> are subscribed to the Google Groups
> "OpenPnP" group.
> To unsubscribe from this group and stop
> receiving emails from it, send an email
> to openpnp+u...@googlegroups.com.
> To post to this group, send email to
> ope...@googlegroups.com.
> For more options, visit

> https://groups.google.com/__grou__ps/opt_out
> <https://groups.google.com/groups/opt_out>.
>
> ____
>
> __ __

>
> --
> You received this message because you are
> subscribed to the Google Groups "OpenPnP" group.
> To unsubscribe from this group and stop
> receiving emails from it, send an email to
> openpnp+u...@googlegroups.com.
> To post to this group, send email to
> ope...@googlegroups.com.
> For more options, visit

> https://groups.google.com/__grou__ps/opt_out
> <https://groups.google.com/groups/opt_out>.
>
> ____

>
> --
> You received this message because you are
> subscribed to the Google Groups "OpenPnP" group.
> To unsubscribe from this group and stop
> receiving emails from it, send an email to
> openpnp+u...@googlegroups.com.
> To post to this group, send email to
> ope...@googlegroups.com.
> For more options, visit

> https://groups.google.com/__grou__ps/opt_out
> <https://groups.google.com/groups/opt_out>.

>
>
>
> --
> You received this message because you are
> subscribed to the Google Groups "OpenPnP" group.
> To unsubscribe from this group and stop
> receiving emails from it, send an email to
> openpnp+u...@googlegroups.com.
> To post to this group, send email to
> ope...@googlegroups.com.
> For more options, visit

> https://groups.google.com/__grou__ps/opt_out
> <https://groups.google.com/groups/opt_out>.

>
>
>
>
>
> --
> Courage et bonne humeur.
>
> --
> You received this message because you are subscribed to the
> Google Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails

> from it, send an email to openpnp+u...@__googlegroups.com.

> To post to this group, send email to ope...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/__msg/openpnp/-/4GKC90SExnUJ
> <https://groups.google.com/d/msg/openpnp/-/4GKC90SExnUJ>.
>
> For more options, visit
> https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.

>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to openpnp+u...@googlegroups.com

> <mailto:openpnp%2Bunsu...@googlegroups.com>.

> To post to this group, send email to ope...@googlegroups.com

> <mailto:ope...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/openpnp/-/aKyfO0gltWwJ.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

[Ami]

Thanks Wayne, by gholly, that's like back to school kinda thing.
Indeed that's more than what I would ever understand.

>     <mailto:openpnp%2B...@googlegroups.com>.

[Paul Jones]

Will do. The other thing I forgot to mention is that my mechanical section is a Delta robot which has non-linear axis, so the controller needs to do *many* sin/cos operations.

.
To view this discussion on the web visit https://groups.google.com/d/msg/openpnp/-/qWT7N3xzoF8J.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Karl Lew]

(raises hand)

Jason, I have bought a TinyG board for FirePick testing. It offers immediate capability and convenience. In other words, "yes, please and thank you for a TinyG driver". 8)

Note that the TinyG json protocol might be preferable for your TinyG driver given that the TinyG JSON may become the basis for a new open source motion protocol. GCode is a bit confining. Alden has more info if you are interested. Is Jason for JSON?

[Jason von Nieda]

Hi Karl,

I'll be using TinyG as well pretty soon. I need to get my X/Y platform finished, and that is just a few days out. I got the left half of my Y axis assembled last night and will probably get the rest finished tonight.

Anyway, the TinyG driver is next on my list to write as soon as I'm at a stopping point for my hardware. Probably a week or so out. I doubt I'll use JSON. It doesn't really offer any benefits for our requirements and it's non-standard. the TinyG driver will be a simple port of the Grbl driver.

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/openpnp/-/Pnwijoah4tMJ.

[Karl Lew]

D'oh. Yes it makes total sense to clone and mutate a grbl. I will be happy waiting for you port. I am waiting on the Hydra power supply from Kickstarter myself, so no rush. If I get bored I can always write the JSON driver myself. The hierarchical JSON structure would permit rich interactions with embedded hardware without compromising gcode command integrity. But yes, it is not a current standard.

Thanks,
Karl

[Jason von Nieda]

Karl,

When it comes down to it, the interface between the machine and the software is incredibly simple. It's basically "Go here" and "Do this". With the design of OpenPnP there just isn't rally a need for anything further. If OpenPnP was more "dumb" and the firmware more "smart" then there might be some benefit, but as it stands now there isn't.

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/openpnp/-/mdCYduTUEc0J.

[Karl Lew]

In my dreams (nightmares?) I foresee a need to coordinate 6-9 steppers or servos, so one aspect of TinyG I want to explore is G93 inverse time mode to coordinate those axes as synchronous movement. e.g., dwell for T1 and move for T2, where the sum of T1 and T2 is the same for all axes. That requirement sort of arises from the topology of FirePick with multiple flying doohickies, but I wont need to worry about that for a few months. Right now it is all about nuts and bolts.

[Ami]

What I found missing in Gcode is the ability to control acceleration.
When the head carry larger chip (DPAK and bigger) with small needle, it shouldn't stop too abruptly, otherwise the DPAK becomes angrybird.

[Riley Porter]

Ami,

TinyG firmware supports acceleration 110%.  In fact we support setting your "jerk" value.

Look. 

"Constant jerk acceleration planning (3rd order S curves) for smooth and fast motion transitions"

You can read all about TinyG here.  Also if you wanted to know the difference between GRBl and TinyG (we forked grbl 3 years ago, its quite unique code now) you should check this out.  

Riley

On Tue, Mar 19, 2013 at 7:23 PM, Karl Lew <ka...@firepick.org> wrote:

In my dreams (nightmares?) I foresee a need to coordinate 6-9 steppers or servos, so one aspect of TinyG I want to explore is G93 inverse time mode to coordinate those axes as synchronous movement. e.g., dwell for T1 and move for T2, where the sum of T1 and T2 is the same for all axes. That requirement sort of arises from the topology of FirePick with multiple flying doohickies, but I wont need to worry about that for a few months. Right now it is all about nuts and bolts.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/openpnp/-/aQAmxjmsIFUJ.

[Jason von Nieda]

Thanks for posting that link Riley. While I am pretty familiar with TinyG at this point, there were some goodies in there I didn't already know.

For the record, I think TinyG is awesome :)

Jason

[Riley Porter]

Yah NP!

I want everyone to know we sell TinyG.  Its NOT our day job (Alden and I)  and we put more time in than  money :)  That being said we are "proud" of our work, so when I post here its not to "sell units" its really to get the word out and to help solve problems.... "Hopefully" :)

If you want to see something really really cool check out our video of driving a belt machine with TinyG.

http://www.youtube.com/watch?v=Om0wTqFA-Dw

Riley

[Jason von Nieda]

That's pretty incredible. I didn't really "get" s-curve acceleration previously, but after doing some reading tonight it seems like it's a clear winner. I'm really surprised that machine can accelerate like that and stay still while not being bolted to the floor.

Jason

[Ami]

Hi Riley,

Thanks for the post. I'll look into TinyG. Updating the controller is in my todo list, I just need to find the right moment.


S curve is probably what I need to avoid angrybird effect.
Just a question: is there a way to set the slope on the run (like Mcode or something?)

Selling one's achievement is perfectly alright with me, in fact several times I was looking for a way to get openpnp takes off commercially;
that's an assurance that it will continue it's life beyond our "fun" time.
It's not easy economically when the machine has soo many parts.

[Riley Porter]

@Ami
Not sure I follow what slope means?  Also what machine are you using?  I would like to see it.  Alden and I are totally in support of this project for the selfish fact that we need a PNP!  We are really after a fix for the "sweet spot".  10x - 25x boards for prototypes cost us a lot in R&D money.  Also, I know / worked with a few companies that what they do is assemble kits for bulk sales.  If you want to email me we can talk off line.  These companies have operational efficiencies where as you/me counting out 112 bolts on your kitchen table, taking 3 hours to put 1 kit together does not cut it!  Ask Alden about his "Light Brick" led kit that he made for Make: Magazine.  Worked all weekend counting resistors :)


@Jason
Yah the acceleration management is pretty awesome! 

Riley

To view this discussion on the web visit https://groups.google.com/d/msg/openpnp/-/4BRpA41ipTUJ.

[Ami]

Hey, where did my posting go? It didn't appear in the web interface.

Riley, another grief I had with linuxcnc is that A axis is not independent.
So while I move the head, I can not rotate at the same time. Rotation axis is slower than the gantry (for resolution purpose, and should not / can not run faster).
For example if I have to rotate 180 degree, it can actually be slower than the movements of the gantry.
Linuxcnc calculates the whole trajectory and the slower axis wins.

The same thing happens for the next part to pick, the head must rotate back to zero before it can pick the next part.
What I want to do is to issue a command asynchronously, for example G09 A00. (say G09 is for asynchronous move)
And then I'll continue on with feeding process (the head dragging the tape).
So at the same time the A axis should rotate back to zero.
Then I'll issue another G00 A00, and since this is synchronous it should wait until it actually reach 00 degree.

Can we do that with tinyG?

[Karl Lew]

TinyG only runs at 32mHz, so my guess is that TinyG has fully independent axes but must complete one command before doing the next so that you as long as you specify xyza in one command that is what you can do simultaneously. I think that means you could spin and drag, but not asynchronously.

(munches on popcorn to see if guess is correct)

[Ami]

Does anybody know how to make A axis independent / decoupled from XYZ in linuxcnc?

[al...@tenmilesquare.com]

It's not really a question of the cycles - there are plenty at 32Mhz, its more the motion control model. TinyG implements a single coordinated motion model. To isolate an axis would require a separate "planner" or some other mechanism to control another motion domain - if even just a single axis. So it's a coding issue, not a cycle issue - I think. 

I mentioned to Ami that I think the Linux CNC codebase allows decoupling an axis from the coordinated motion. But I haven't looked into this enough to determine how they do it or what capabilities this provides.

I'm not sure of the limitation, however. Regarding TinyG - and any other multi-axis system - You can move in XYZ and rotate A simultaneously. It's just that all movement will start and end at the same time. Is this a problem? I'm not understanding the issue, I guess.

--Alden

[Jason von Nieda]

Alden,

This is something I thought I had asked you about but I just went back and read our discussion and it turns out I asked the wrong question.

The problem is that on a pick and place you have X and Y with a very high steps per inch and C with a very low steps per "inch", since it's normally direct coupled. So what ends up happening is you try to do a large move in XY with an accompanying small move in C and the maximum velocity of C ends up limiting the speed of XY. I ran into this same problem with Grbl after I added the C axis. When I asked you about this, I asked the wrong question. I asked if I could set velocity and acceleration independently in TinyG, which I can. What I should have asked is if I could decouple C from XY for coordinated motion and I am pretty sure the answer there is no.

Now, this is less of a problem on TinyG than it was for my modified Grbl. My solution with Grbl was to make OpenPnP do moves in C independently from XY. So it would move to XY and then move C. Then what happened is the single acceleration setting in Grbl limited the speed of C. Since TinyG has independent settings for this, it would be nice and fast. But we still have the problem that we'd need to do C moves separately from XY.

Eventually we will probably need a completely independent C if we are to do interesting flying vision and alignment stuff, but for the time being I think TinyG will work. 

Jason

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/openpnp/-/beF9aR4tqdsJ.

[HauntBots]

I'm not seeing the issue either.  With the axis motion coupled in Ami's example, the A axis will limit the overall speed the other Axis can move at, but since the machine will not be ready for the next operation till after all axis have completed their moves, I don't see how it matters if they do them independently or simultaneously.

Oh! Wait! are you looking for Asynchronous movement where the X&Y axis are doing multiple things, Like drag tape feeding and repositioning while the A axis is completing its single motion return to home?

Pete

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/openpnp/-/beF9aR4tqdsJ.

[al...@tenmilesquare.com]

The problem as I understand it:

- It's a question of how fast you can do two things at the same time: (1) the linear move from A to B, and (2) the rotational move to orient a part. 

- It's OK if the move is coordinated - the rotation starts and ends at the same time the linear move starts and end, as long as the rotation doesn't slow down the linear move for this to happen.

- The rotary axis is actually physically capable of spinning the part very fast because it's direct coupled (i.e. no gearing), so there's no mechanical reason the rotation can't be as fast as the linear move.

If the above is correct then the solution is just making sure the acceleration (or jerk) settings for the linear and rotary axes can be set independently of each other. That way different dynamics apply. TinyG does this and I think the latest version of grbl sets acceleration independently as well - but doesn't handle a 4th axis. Some testing is in order to validate this.

This problem really begs for using inverse time mode rather than feed rate because what you want is the linear move to complete in some knowable time and the rotation to complete in the same time. Doing this by feed rate alone is complicated. Here's the definition of mixed mode feed rate moves from the RS274NGC spec (Kramer NIST spec ref: http://technisoftdirect.com/catalog/download/RS274NGC_3.pdf):

2.1.2.5 Feed Rate

The rate at which the controlled point or the axes move is nominally a steady rate which may be

set by the user. In the Interpreter, the interpretation of the feed rate is as follows unless inverse

time feed rate mode is being used in the RS274/NGC view (see Section 3.5.19). The canonical

machining functions view of feed rate, as described in Section 4.3.5.1, has conditions under which

the set feed rate is applied differently, but none of these is used in the Interpreter.

A. For motion involving one or more of the X, Y, and Z axes (with or without simultaneous

rotational axis motion), the feed rate means length units per minute along the

programmed XYZ path, as if the rotational axes were not moving.

B. For motion of one rotational axis with X, Y, and Z axes not moving, the feed rate means

degrees per minute rotation of the rotational axis.

C. For motion of two or three rotational axes with X, Y, and Z axes not moving, the rate is

applied as follows. Let dA, dB, and dC be the angles in degrees through which the A, B,

and C axes, respectively, must move. Let D = . Conceptually, D is a

measure of total angular motion, using the usual Euclidean metric. Let T be the amount

of time required to move through D degrees at the current feed rate in degrees per

minute. The rotational axes should be moved in coordinated linear motion so that the

elapsed time from the start to the end of the motion is T plus any time required for

acceleration or deceleration.

I think what C says in plain English is that the rotary move should take the same amount of time as the linear move to complete. This is how we coded TinyG - hopefully we got it all correct!

--Alden

[Ami]

Alden, I think it's the opposite of what you write below:

- Rotational and linear move doesn't have to finish at the same time. In fact we need to have rotational independent of linear move, so we can ask it to go back to zero degree, and then, while it's rotating, we can do many linear moves for unknown amount of time. We just need to check the status at the end, if the rotation has already ended as well.

- The move doesn't have to be coordinated; it CAN NOT be coordinated. In fact we want them to be disynchronized, as I explain about going back to zero degree; we can't synchronize the move because the length of time may be different between rotation and linear move, and it is unknown at the moment of issuing them. (feeding needs visual feedback which is not available when we start rotating head to zero)
- The rotary axis is NOT capable of spinning very fast, compared to xyz gantry because of many reasons (it may hold a part underneath by a suction only, it has a gearhead to improve resolution, the motor is small /  not very strong, etc.

So the solution really is about discoupling the rotational moves from the XYZ moves.

[al...@tenmilesquare.com]

Ami,

I am referring to a near-term solution. As long as the rotation doesn't slow down the linear move it should allow progress to continue

I think the long term solution is what you say - Decouple the movement into multiple coordinated movement domains. I was just trying to find a way to move forward right now. 

Make sense?

--Alden

[Karl Lew]

Interesting. I was going to use TinyG for a single translational doman, which is perfect, since I have four of those. For rotation and Z, I plan to use a separate set of boards, one on each gantry. That separates coarse vs. fine motor coordination and feed rates well. Coordinating the two domains would require inverse time mode, which TinyG supports. Having multiple domains also permits asynchronous commands across domains.

Me happy. Thank you, Alden.

[Karl Lew]

On Friday, March 22, 2013 11:54:49 PM UTC-7, Karl Lew wrote:
> Interesting. I was going to use TinyG for a single translational doman, which is perfect, since I have four of those. For rotation and Z, I plan to use a separate set of boards, one on each gantry. That separates coarse vs. fine motor coordination and feed rates well. Coordinating the two domains would require inverse time mode, which TinyG supports. Having multiple domains also permits asynchronous commands across domains.
>
> Me happy. Thank you, Alden.

Whoops. I meant four AXES in one translational domain. Sorry.

[Ami]

OK Alden,
I think it was Friday Night effect. I understand now you're searching for a short term solution.
No need to hurry!

As far as Jason's AFAIK, my machine is the only one working at this moment.
As is, normal XYZA works for me, so there's really no hurry.
The horizon I think is probably around end of summer, or even end of the year when more people will have their machine alive.
(Karl that goes for you too, stop designing springy thingy in a pocket, we can upgrade feeders later. )

So you might as well go for the good solution, in any case I can live with my Sylvestre for the moment.

[Karl Lew]

Alden, I have a possible long term interest in a 1 or 2 axis version of TinyG, primarily to separate motion domains and scale to additional axes. These would be the domains:
1) xx, yy, za, za
2) xxyy, za, za
Currently, I am going for (2). I.e.,with TinyG for xxyy and Teensyduino/EasyDriver for each za pair.

I am the only one with more than 4 axes, so that is just 1 data point. However, a SCARA machine with solenoid Z would also benefit from a 2-axis "MicroG"

My TinyG arrived yesterday. Yippee! and Thank you.

(Ami, is that a spring in your pocket, or are you just happy to see me?). 8)

[Ami]

Papa Jason is watching !!! :-D :-D 

[Karl Lew]

Alden, here is my shiny new TinyG in the corner where I think I can wire in all four steppers without extra cabling. The vertical mount lets me position TinyG close to the steppers. I also think I will have the TinyG wire connectors on the bottom as shown so that I can route wiring along the extrusions. As we discussed offline, I hope to use natural convective cooling without fans and the vertical mount facilitates that.

Hope this helps and thanks again.

[al...@tenmilesquare.com]

Cool. I think I'm getting a better idea of what you are trying to do.

[al...@tenmilesquare.com]

Karl, Yours is the first solid application I've seen for multiple motion domains. Very interesting. We need to find a good way to do this. -- Alden

[Riley Porter]

Sweet Karl, 

Glad you got it!  

On Sat, Mar 23, 2013 at 11:08 AM, Karl Lew <ka...@firepick.org> wrote:

Alden, here is my shiny new TinyG in the corner where I think I can wire in all four steppers without extra cabling. The vertical mount lets me position TinyG close to the steppers. I also think I will have the TinyG wire connectors on the bottom as shown so that I can route wiring along the extrusions. As we discussed offline, I hope to use natural convective cooling without fans and the vertical mount facilitates that.

Hope this helps and thanks again.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/openpnp/-/Z5mhNAVQxEkJ.

[Jason von Nieda]

For what it's worth, I did some testing last night with my TinyG with massively different geometries on X and C. Everything seems to work great. I can move X 1000mm while moving C only a few degrees and the different acceleration settings allow X to move at it's normal fast speed while C creeps along. So, for the specific problem I was having with Grbl, this seems to be fixed.

I am not quite sure what Ami is referring to regarding making many small XY moves while C repositions. I suspect he is referring to C moving very, very slowly as to not dislodge the part while things like vision movements are progressing. That will definitely require asynchronous commands but that is not something that I personally need right now. In the future as the vision algorithms get more complex, this might be useful.

For the time being, it looks like TinyG gets the job done for me.

Jason

[al...@tenmilesquare.com]

Happy to hear it. Let me know how the rest of the testing goes.

--Alden

[Karl Lew]

Alden, here's the TinyG acrylic case for vertical extrusion mounts. I ordered one and I'll post a picture in a few weeks when it arrives...

https://github.com/firepick1/FirePick/wiki/A3TG

[Ami]

Cool, I want one!

Karl! If I may suggest,
I found that when the machine runs full speed the frame is vibrating!
Any loose thing will jingle like christmas.
So I'm a bit worry when I see the M5 screws are only at the bottom.
At least three points should be necessary, or in the middle.

(And don't fix the sparkfun pump on the frame)

[al...@tenmilesquare.com]

Really nice. I'll keep the geometry in mind as I work on new designs.

[Karl Lew]

I will need to test the case on a running machine before I release the design. I hope the bottom mount will be like a blade of grass and actually function as a damper for vibrations orthogonal to the board. Who knows?

I also purchased a lenovo 20V 90W power adapter clone for USD20 and am going to chop off the plug and stick the wires into TinyG power connector. It is cheaper to chop the plug than find the jack, which I find bizarre.

Will test TinyG directly until Jason is done with driver.

[x.l...@gmail.com]

Hello,

So I've been working with the Mega2560 and I have stepper motors turning for all 4 axes so I would like to mount them and start testing. However, I was trying to use limit switches, but haven't had any luck. Since the config file says the limit switches are active low by default, does that mean all I have to do is ground a limit pin to shut that axis down (i.e. ground Digital Pin 31 to kill the X axis motor)? Any help would be appreciated.

[Ami]

Hi Alden,

This "long-term solution" below is what I was referring to.
We need the A axis to "go back to zero" while the head is fetching the next part.
The rotational move is NOT / Can not be coordinated/synchronized with the XYZ moves.
A Axis is slower than the XYZ axis.

On Friday, March 22, 2013 11:57:51 PM UTC+1, al...@tenmilesquare.com wrote:

[Jason von Nieda]

Ami, can you list some real numbers? What is the speed of your X, Y, Z and C (A)?

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6607d821-a6e7-478b-878f-d1e94458d1c7%40googlegroups.com?hl=en-US.

[Ami]

A axis is slow: after the gear head it's 120 degree / sec.
So from 270 degree back to zero takes more than 2 seconds.

XYZ are faster: 240 mm / sec, so even if it has to go 240mm to the feeding place, it'll take just 1 sec.
(I oversimplify cos there're accel/decel, but it's friday night so...)
During feeding the head is also moving slower, cos the parts are flippy-happy, especially the 0603 led, and SOT23.
So I figure it can do the rotation back during the feeding process while the needle (A axis) is not used at all.

[Jason von Nieda]

So what you are really looking for is asynchronous movement of the A axis and then the ability to wait to make sure it's moved to where it needs to be. I suspect Alden will say that is very difficult since that means the planner has to plan multiple moves while another already planned move is still running. 

You could attempt to hack this in your driver code by calculating how long an A movement will take and then issuing shorter, coordinated A moves until finally reaching the final point. Another option would be to use a second controller specifically for A. 

I'll be curious to hear what Alden thinks on this.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/871a73c5-1290-48bd-8bef-4c074e595d81%40googlegroups.com?hl=en-US.

[al...@tenmilesquare.com]

Jason, 

The hack with issuing coordinated A moves is a good option for now. Ultimately we need multiple motion domains as a longer term solution. You are right - this involves multiple parsers/planners/step-generators, so that's the challenge.

(Actually they are technically C moves, since it's rotation about the Z axis, but I'm just making a point here and it's not really relevant to the answer).

Alden