Error in cutting, pattern shifted / missing steps?

[Freek]

Hey guys,

so we managed to, almost completely, solve the problems that we had with our RECI P14 laser PSU (see topic https://groups.google.com/forum/#!topic/lasersaur/FzpA10UFN3g) and managed to make our first cuts! We used the lasersaur logo for initial debugging with no problems, but then we moved to a lasercut tie file (thingiverse link: http://www.thingiverse.com/thing:707915). When cutting this file, several things go wrong (see attachted pictures):

1. On all 3 "vertically oriented" ties, the outer cut (which is stopped by us after a while) seems to have a different scaling (accumulating error?) than the spacing of the individual slots.

2. On the "horizontally oriented" tie below, the laser starts cutting the largest slot (indicated with a red "1") and proceeds as indicated by the arrow. Secondly, the slot indicated with the green "1" is cut. These slots are shifted in both the x and y direction. The outer cut (starting at the yellow point) seems to have the correct spacing but starts at the wrong location w.r.t. the first pattern.

We have tried / checked:

1. Reading on the google group trying to find people who have a similar problem but have not been able to find a solution from the available information.

2. Acceleration in firmware decreased a factor 10 (from 10000000 to 1000000 mm/min^2) and jog speed changed from 10000 to 5000 mm/min between cuts II and III. (Assumption: Missing steps?)

3. Increased the stepper motor current for both motors from 1.6 A to 2 A between cuts II and III. (Same assumption: Missing steps?)

4. Checked play in gantry by switching on the machine and having the motors keep the stages in position: No play is felt and stiffness seems alright.

5. Checked if the gantry has specific points of higher friction by slowly moving it around when the machine is switched off.

The drivers that we use are Longs motor DM542A (http://www.longs-motor.com/productinfo/detail_12_80_131.aspx). Does the problem seem familiar to anyone?

Cheers,

Freek

[Steve Baker]

The picture of the horizontal 'tie' looks almost identical to the vertical
ones...right?

So the error seems to happen identically in the X and Y directions.

That would be REALLY surprising if it were some kind of an assembly or
wiring error (belts too tight or too loose or a bad motor or whatever).

Whatever the problem is - it's happened twice - and in the exact same way
each time.

If you're running the standard lasersaur firmware, the software is
identical for the X and Y axes - so that can't be it. The X and Y axis
motors are different kinds - so it's unlikely they'd both fail in the
exact same way.

We're left with some kind of a fundamental hardware design flaw - but that
would affect everyone - and it clearly doesn't because I can cut and etch
for thousands of hours without seeing this problem.

CONCLUSION:

* It has to be something you've changed in the design - something
different from the rest of us.
* It has to be something you did in both the X and Y axes.

From what you've written below - the one obvious thing is that you have
different motor controllers than everyone else.

The Lasersaur BOM specifies GeckoDrive controllers - and you went with
"Longs motor DM542A"...I have no knowledge whatever of those devices.

My guess is that they aren't compatible with Gecko's in some way...maybe
you need something different in the software to make them work correctly?
Maybe some subtle signal timing thing?

Hopefully, someone else has tried using these controllers - but if not
then I doubt we're going to be able to help you...so you have two choices:

1) Try to figure out what's different about their control input
specifications and fix it yourself.

2) Get rid of your motor controllers and buy a couple of GeckoDrives.


-- Steve

> --
> You received this message because you are subscribed to the Google Groups
> "lasersaur" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to lasersaur+...@googlegroups.com.
> To post to this group, send email to lase...@googlegroups.com.
> Visit this group at https://groups.google.com/group/lasersaur.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/lasersaur/2b391346-8bdf-439d-9c62-4b902dd05976%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- Steve

[Freek]

Hey Steve,

Thanks for the swift response. We do have a Gecko drive laying around somewhere from another project, so we'll try to change one of drivers to see if there's any noticeable difference in behavior.

In the mean time we've performed some more experiments with the current setup:

1)

- Move to specific point (100, 100) and place a piece of wood with a screw sticking out exactly underneath the lens assy.

- Move around the entire range in both X and Y directions multiple (8x) times using the move to functions in the move/jog menu.

- Move back to original point (100, 100)

--> Result: Lens assy is again exactly above the screw tip. No noticeable offset.

2)

- Move to specific point (100, 100) and again put the piece of wood and screw tip underneath the lens assy.

- Run the lasertie file, but without the high voltage power supply turned on. Wait until complete file is done. (LasaurApp notes a total length of 8.2 meters for the file)

- Move again to original point (100, 100)

--> Result: A clearly visible shift of approximately 5 mm in X direction and even approx 10 mm in Y direction. (both in positive axis directions)

Conclusion:

The error only occurs during "cutting", not during manual moves.

(This was also seen in the pictures in the original post: A seemingly accumulating error during an uninterrupted cut.)

[j. eric townsend]

On 2/21/16 13:43, Freek wrote:

> - Run the lasertie file, but without the high voltage power supply
> turned on. Wait until complete file is done. (LasaurApp notes a total
> length of 8.2 meters for the file)

Is there any way for you to print this file to paper, then tape the
paper on top of the cutting bed, start a etching-paper cut and see where
the cut starts to diverge?


--
J. Eric Townsend, IDSA
design <http://www.allartburns.org>
hacking <http://www.flatline.net>
consulting <http://www.functionalprototype.com>

[Steve Baker]

I don't see how there could be a difference between "cutting" and "moving"
if the laser power supply is unplugged.

Can you run the tie pattern with the laser power set to 0% ?

My feeling is that there is a problem with rapid changes in direction -
which the tie pattern does a lot - but the dinosaur pattern doesn't
(much).

Suppose (as a hypothetical example) that when the firmware changes
direction, there is a race condition between the "DIR" and "STEP" signals?

Perhaps the geckodrive doesn't care - but maybe the "longs" drive needs
the DIR signal to be stable for some amount of time before you start
stepping?

Maybe there is some difference in the way that microstepping is handled
such that the deceleration at the ends of each line is causing error?

Well, if you can replace one of the drivers with a Gecko - that'll tell us
a lot.

If it makes no difference whatever - then my theory is false - if it
changes things so that the error now only accumulates in on axis - then my
theory is proven.

>> > email to lasersaur+...@googlegroups.com <javascript:>.

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

>> <javascript:>.

>> > Visit this group at https://groups.google.com/group/lasersaur.
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/d/msgid/lasersaur/2b391346-8bdf-439d-9c62-4b902dd05976%40googlegroups.com.
>>
>> > For more options, visit https://groups.google.com/d/optout.
>> >
>>
>>
>> -- Steve
>>
>>

-- Steve

[Steve Baker]

It would be hard to print it at exactly the right size and get it
perfectly aligned with the laser bed.

-- Steve

> --
> You received this message because you are subscribed to the Google Groups
> "lasersaur" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to lasersaur+...@googlegroups.com.
> To post to this group, send email to lase...@googlegroups.com.
> Visit this group at https://groups.google.com/group/lasersaur.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/lasersaur/56CA090E.9000407%40allartburns.org.

[j. eric townsend]

On 2/21/16 16:03, Steve Baker wrote:
> It would be hard to print it at exactly the right size and get it
> perfectly aligned with the laser bed.

Right, I have x/y guide rails on mine which do make this easier. I
should add that to the model.

--
J. Eric Townsend, IDSA
design <http://www.allartburns.org>
hacking <http://www.flatline.net>

fabrication <watch this space>

[Freek]

Hey guys,

We've made a bit of progress: today we've performed the stepper driver swap experiment:

- Replaced the Y axis stepper drive with a Gecko G203V.

- Updated the firmware, since the Gecko is a 10microstep drive, while we used the Longs drive at 8 microsteps:

- # steps per mm on a longs drive was: 22.22222222

- # steps per mm on a Gecko is now: 27.77777778

   (We use a 3 mm pitch belt, on a 24 tooth pulley with 200 steps/rev stepper motors, no mechanical transmission.)

- Homed, then moved the lens assy to point 100,100.

- "Cut" the entire tie, but with the HV PSU unplugged.

- Moved back to point 100,100 to check offset.

Result:

- No shift in Y direction.

- A clear shift of approximately 5 mm in X direction.

So Steve is probably on the right track, and we're unhappy about that, because it will probably mean spending more money..

So we performed another experiment:

- Left the Gecko in place on the Y axis, no need to change this now.

- Changed the micro stepping settings on the Longs motor drive to 6400 steps / revolution. (Increased from 8 microsteps to 32 microsteps)

- Updated the firmware:

- # steps per mm on the Longs drive with 32 microsteps is now: 88.88888889

- Homed, then moved the lens assy to point 100,100.

- "Cut" the entire tie, but with the high voltage supply turned off.

- Moved back to point 100,100 to check offset.

Result:

- No shift in Y direction. (Of course, this is still the Gecko drive)

- A significantly smaller shift in X direction, but still visible. As expected from 4 times increase micro stepping: The shift is 4 times less.

- Steve's theory of making a step in the wrong direction might make sense: By reducing the step size this effect is reduced.

So we looked into step times and direction setup times:

We noticed that the pulse time is set in the firmware in config.h to 5us, which should be more than enough for both the Gecko (>1 us) and the Longs (>2.5 us).

One big difference in specifications between the two drivers is the required direction setup time, before the step is applied:

The Gecko requires a direction setup time of >200 ns, while the Longs requires >5 us. A factor of 25 times.

Calculating the pulse frequencies that we're using, there should be plenty time to even achieve 5 us direction setup time, but we can't find this setting in the software, so the question is: Can we adjust this parameter in the software and if so, could anyone point out where to do this? So far we haven't been able to discover the location (if existent).

Thanks very much for the input and help!

Cheers!

[Steve Baker]

I don't know where in the code to establish a longer direction setup time.

However, a 16MHz Arduino has a 62ns cycle time - and machine code
instructions take between 1 and 4 cycles to execute. So 200ns is likely
to be the time the Arduino takes to execute one or two machine code
instructions - maybe one line of C++ code. So there isn't a need for any
kind of timer in there right now. At 5us - you're going to need something
much better.

But you'll have to be a bit careful because the direction flag on one
motor may change while the other motor is moving at full speed. Putting
too big of a delay in there could result in the other axis not getting a
step command on time - and that would be "A Very Bad Thing".

Honestly, I'd just go buy another Gecko. Aside from anything else, it
gives you a better chance of getting help here in the future - and staying
on the mainstream software release track will be a lot easier in the
future.

But at least it sounds like you're heading in the right direction!

Incidentally - running the system with ungeared motors isn't great. I
have one lasersaur with the old (ungeared) motors and another with the
newer geared design.

The old machine is extremely picky about belt tension - but it works.

When I built my second machine, Mitsumi had changed their belt supplier
and the new (identical specification - identical appearance) belts were
just a fraction wider and slightly stiffer than the old ones - I spent
weeks trying to get just the right belt tension and motor drive current to
get the darned thing to work without skipping or stalling. I never did
get it to work and eventually upgraded to the geared motor design. With
the geared design, it worked perfectly first time and is tolerant of a
wide range of belt tensions.

My conclusion is that the old design is right on the edge of failure all
of the time.

So...if you get your current problem fixed and then find that you're still
dropping steps once in a while - expect to have to fiddle with that stuff.

-- Steve

> --
> You received this message because you are subscribed to the Google Groups
> "lasersaur" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to lasersaur+...@googlegroups.com.
> To post to this group, send email to lase...@googlegroups.com.
> Visit this group at https://groups.google.com/group/lasersaur.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/lasersaur/8f6fd16a-83c3-417d-8637-1b03358fb695%40googlegroups.com.

[Martin Renold]

On Sat, Feb 27, 2016 at 06:05:49AM -0800, Freek wrote:
>
> So we looked into step times and direction setup times:
> We noticed that the pulse time is set in the firmware in config.h to 5us,
> which should be more than enough for both the Gecko (>1 us) and the Longs
> (>2.5 us).
>
> One big difference in specifications between the two drivers is the
> required direction setup time, before the step is applied:
> The Gecko requires a direction setup time of >200 ns, while the Longs
> requires >5 us. A factor of 25 times.
>
> Calculating the pulse frequencies that we're using, there should be plenty
> time to even achieve 5 us direction setup time, but we can't find this
> setting in the software, so the question is: Can we adjust this parameter
> in the software and if so, could anyone point out where to do this? So far
> we haven't been able to discover the location (if existent).

Code is here:
https://github.com/stefanix/LasaurApp/blob/master/firmware/src/stepper.c#L241

Line 242 sets the direction only, and the next line sets the step pin too.

I'm measuring 370ns from direction pin high to step pin high. (It's
probably 6 CPU cycles / 16MHz = 375ns).

You could try this:

// pulse steppers
- STEPPING_PORT = (STEPPING_PORT & ~DIRECTION_MASK) | (out_bits & DIRECTION_MASK);
+ uint8_t direction_bits_old = STEPPING_PORT & DIRECTION_MASK;
+ uint8_t direction_bits_new = out_bits & DIRECTION_MASK;
+ STEPPING_PORT = (STEPPING_PORT & ~DIRECTION_MASK) | direction_bits_new;
+ if (direction_bits_old != direction_bits_new) {
+ _delay_us(CONFIG_DIRECTION_SETUP_TIME_MICROSECONDS);
+ }
STEPPING_PORT = (STEPPING_PORT & ~STEPPING_MASK) | out_bits;
// prime for reset pulse in CONFIG_PULSE_MICROSECONDS
TCNT2 = -(((CONFIG_PULSE_MICROSECONDS-2)*CYCLES_PER_MICROSECOND) >> 3); // Reload timer counter

Pushed here: https://github.com/martinxyz/LasaurApp/commit/a7e7ae78d

I'm measuring 5.5us delay with CONFIG_DIRECTION_SETUP_TIME_MICROSECONDS = 5.

Regards
Martin

[Freek]

Hey Martin,

thanks very much for your input! We will probably get to testing this next tuesday and will definately let you know the outcome!

Cheers,

Freek

[Freek]

Martin,

Thanks a bunch. Like, at least 1000. The code worked :D! We did however make a small modification. First we tested with your suggestion but ended up getting a shift in the opposite direction. Then we tested with just the delay line ("_delay_us(CONFIG_DIRECTION_SETUP_TIME_MICROSECONDS); ") and it worked, no more shifts!

This could prove some cost reduction w.r.t. the current BOM, as we got 4 "longs motors" drivers for 130 dollars. No compromise regarding speed has to be made, at 6000 mm/min (with our settings of microstepping and transmission ratio), 1 step takes 455 usec/step so a delay of 5 usec is more than acceptable.

Cheers!

[Steve Baker]

If having the 'if' statement in there prevented it from working - then you
have bigger problems. Without that, you're causing a delay after every
single step - not just steps that resulted in a direction change.

That suggests that something else is amiss here. Hopefully it's not
crucial - but it's something that seems like a red-flag for me.

As far as preferring Long drivers in the BOM - I'd oppose that.

There are cost savings - and there are false economies.

Gecko have a stellar reputation for customer service - and their driver
modules will survive an insane amount of abuse. They'll often repair a
module that's out of warranty for $0 if it fails when it shouldn't. I'd
be surprised if Long's drivers were that good (the slow handling of the
DIRECTION signal doesn't suggest that they took a lot of trouble over
their design!)

I can understand that under some situations, saving $50 out of a $8,000
build is worth it - especially when having your lasersaur out of action
for a week or two is not critical.

But our lasersaurs earn us between $1 to $2 per minute - and being out of
service for even one hour would completely wipe out the difference in
price between Gecko and Long drivers. Even if we could keep extra spares
in stock (which we actually do, even with the Gecko's) - the time lost due
to diagnosing a problem and replacing the driver means that reliability
trumps cost here.

So we'll be sticking with Gecko for the forseeable future.

-- Steve

> --
> You received this message because you are subscribed to the Google Groups
> "lasersaur" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to lasersaur+...@googlegroups.com.
> To post to this group, send email to lase...@googlegroups.com.
> Visit this group at https://groups.google.com/group/lasersaur.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/lasersaur/7f5e7d8c-eb08-4e29-bdae-33550cc2cb46%40googlegroups.com.

[Martin Mueller]

Howdy, laser wise people.

We’re having a problem occasionally with our Boss HP3650 laser starting a job cutting just fine then the output drops off to barely mark the surface.
The indicated power stays constant. Alignment is AOK, and the effect is the same all over the bed.
Chiller temp is fine, just a degree over ambient.

Changing the job file has no effect on the problem, but an overnight rest seems to cure it.

Any insights?

Thanks,
Marty at Gizmo-CDA

[Steve Baker]

Sorry - we aren't a support group for laser cutter owners in general.

Our expertise lies in one very specific, OpenHardware/OpenSoftware design:
the "lasersaur".

You may have a worn out laser tube - possibly a faulty laser power supply
- but without knowing a darned thing about this "Boss HP3650" gizmo - you
probably shouldn't take advice from us anyway.

-- Steve

Martin Mueller wrote:
> Howdy, laser wise people.
>
> We’re having a problem occasionally with our Boss HP3650 laser starting

> --
> You received this message because you are subscribed to the Google Groups
> "lasersaur" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to lasersaur+...@googlegroups.com.
> To post to this group, send email to lase...@googlegroups.com.
> Visit this group at https://groups.google.com/group/lasersaur.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/lasersaur/69B9C840-4BB4-4084-A2C3-418C417A6E8F%40msmdesign.com.

[j. eric townsend]

On 2/21/16 16:01, Steve Baker wrote:
> I don't see how there could be a difference between "cutting" and "moving"
> if the laser power supply is unplugged.

I should go look at the code but I've always assumed the acceleration
curves are different for cutting vs. traversing. "Assumed" because I
still think in CNC mill terms...

--
J. Eric Townsend, IDSA
design <http://www.allartburns.org>
hacking <http://www.flatline.net>

consulting <http://www.functionalprototype.com>

[Steve Baker]

Yeah - I think you need a little "reeducation" from CNC machines.

There is no difference (in terms of motor controls) between cutting and
traversing.

With a CNC mill, there is considerable force on the head when you're
cutting - and very little force while traversing - so the motor profiles
are very different in the two cases.

With laser cutters (and 3D printers for that matter), the motion platform
doesn't care whether you're lasering (or extruding) or not. The laser
power setting makes absolutely zero difference to the motor control
system.

OTOH, there is a reverse connection. While the motors are ramping up to
speed, the laser power is reduced somewhat. Without that the start and
end of every etched line has a dark spot, and might even cut all the way
through the material because the head is (briefly) running far too slowly.

The only reason we have acceleration and decleration profiles at all is so
that we can move the head at maximum speed and still stop on a dime - and
we have to do that regardless of whether we're repositioning the head or
doing a high speed etched line.

So you don't need to go through the code - I can assure you there is no
difference.

Moreover - even if there was a difference - the Arduino doesn't move the
head any differently when the door is open or closed - so opening the door
and thereby cutting off the laser doesn't change the path or speed of the
head in the slightest.

-- Steve


j. eric townsend wrote:

> --
> You received this message because you are subscribed to the Google Groups
> "lasersaur" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to lasersaur+...@googlegroups.com.
> To post to this group, send email to lase...@googlegroups.com.

> Visit this group at https://groups.google.com/group/lasersaur.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/lasersaur/56D5C9D6.6060009%40allartburns.org.

[j. eric townsend]

On 3/1/16 12:11, Steve Baker wrote:
> There is no difference (in terms of motor controls) between cutting and
> traversing.

I was thinking it was because we traverse way faster than we cut so that
curve is different than a cutting curve for a lower speed, but you're
right, it doesn't matter if the laser is on or not. We can control the
lead in/out of the cut by ramping the power (as you said). I saw some
of that yesterday while etching paper, it does make a nice effect we can
use with rastering.

[Steve Baker]

Not so! I etch at the same speed I traverse.

But you can't afford a single mis-step while traversing OR while
cutting/etching...so it's the same deal.

-- Steve

j. eric townsend wrote:

> --
> You received this message because you are subscribed to the Google Groups
> "lasersaur" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to lasersaur+...@googlegroups.com.
> To post to this group, send email to lase...@googlegroups.com.
> Visit this group at https://groups.google.com/group/lasersaur.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/lasersaur/56D5D343.4050602%40allartburns.org.

[Martin Renold]

On Tue, Mar 01, 2016 at 11:56:54AM -0500, j. eric townsend wrote:
> On 2/21/16 16:01, Steve Baker wrote:
> >I don't see how there could be a difference between "cutting" and "moving"
> >if the laser power supply is unplugged.
>
> I should go look at the code but I've always assumed the acceleration curves
> are different for cutting vs. traversing. "Assumed" because I still think in
> CNC mill terms...

I'm pretty sure they are the same, and "acceleration curve" is expecting too
much, it's more like an acceleration step.

(I've actually tried to implement a S-curve velocity profile on the related
Marlin firmware, just to see what is possible. And while it works using
32bit integer additions, this poor 8bit Atmel CPU didn't do much else.)

[Martin Mueller]

You may not think of yourselves as a support group, but your discussions have given me lots of tips and insights, Steve, so I thought I’d ask.

We chose to buy rather than build since we had already built our CNC router and CNC plasma cutters and had members at our makerspace clamoring for the laser.

Turns out it was a weird symptom of a full memory buffer. 

Keep up the good work with the Lasersaurs!

Best Regards,

Marty at Gizmo-CDA

To view this discussion on the web visit https://groups.google.com/d/msgid/lasersaur/f6d122e7aae17b292c9fd2a584b363aa.squirrel%40webmail.sjbaker.org.