Positional Error

[Dean Gouramanis]

I ran into a problem last week. In the process of debugging I updated to the latest release. Just wanted to congratulate all the contributors on great work. 

It seems I'm experiencing a software/firmware bug causing my Z axis to drift in the positive direction. Has anyone else noticed this? In my case the net difference is consistently 40 pulses (or 0.004 inches) for a particular text engraving program. (0.004" is 50% of the total depth, so it's a significant problem)

I wrote a few G programs to try and find out what's happening. Seems the error only happens when G1 commands for a different axis are executed between Z axis movements. In other words, reciprocating Z axis back and forth yields no error. When the program is engraving text (XY plane) then lifts out (Z axis) to go to the next letter, the axis over travels in the positive direction, or undertravels in the negative direction. Then the next letter is not as deep as the previous. Larger XY movements cause a larger error in Z axis.

I wrote four programs to test (attached). TestA is my usual, minimal coding style. In TestB I added ";" line endings to each line. In TestC I used separate G1 commands for each line, instead of listing many coordinates under one command. In TestD I added a 1 second delay between each command. 

Physically measured offset after each test program:

TestA: net = +0.0040"

TestB: net = +0.0036"

TestC: net = +0.0036"

TestD: net = +0.0001"

Adding a 1 second delay after each command fixed the problem. I am guessing it could be a rounding error since the drift is always positive. Maybe incorrect values are getting loaded into the PRUs, and delaying prevents the data loss. Only guessing...

I convinced myself it is not a hardware issue by carefully measuring the error, and repeating many times. The error pulses are mixed in with G1 motions, and not happening during movement on other axis (for example if there was GND noise causing cross-talk between axis). I tested with extra slow feed rates too. I can see the Z axis decelerate cleanly, and stop precisely at the wrong number.  :)

Insight is appreciated! Thanks guys.

[Hartley Sweeten]

Hi Dean,

A couple questions...

1) What is your machine configuration?

2) Have you tried the latest HEAD?

I had a similar problem a while back.

It appears that the drift only occurred when an axis has a negative direction and/or the home position

for an axis is 'max'. When this is the case the driver_flip_ was causing issues with the changes to how

the M114 command now works with the works with the motor-operations GetPhysicalStatus backend.

The following commit fixed the problem on my machines:

commit 1ede4f7832a29f1759ce2810af881f634118596b

Author: H Hartley Sweeten <hswe...@visionengravers.com>

Date:   Wed May 9 23:32:18 2018 -0700

    motor-operations: fix the driver_flip_ issues caused by the M114 changes

    

    The only place the driver_flip_ needs to be applied is when the direction_bits

    are being set when a new segment is being added to the PRU queue.

    

    This fixes the issues with SetExternalPosition(), GetCurrentPosition(), and

    AssignMotorSteps() that showed up with the M114 changes that used the

    motor-operations GetPhysicalStatus backend.

    

    The issues only seem to show up with negative motor directions and/or when

    the home position for an axis is 'max'.

    

    Signed-off-by: H Hartley Sweeten <hswe...@visionengravers.com>

Try pulling the current HEAD and see if that works for you.

Hartley

[Henner Zeller]

mmh, so this is interesting. This could either mean that there are
some issues with acceleration (e.g. lost steps due to too fast
acceleration?)
or that we do something differently if we stop and restart (internally
called BringPathToHalt()), which is happening on dwelling.

Does it also work if you have a very short dwell time, say G4 P1 ?

There were some issues that Hartley fixed with offsets on homing (see
his email), but IIRC, in that case the final position if asked with
M114 was off. However, I added an
M114 to the end of your test-gcode and it reports position zero at the end.

Looking at the gcode path wtih gcode2ps in a sideways view, it also
seems to always hit the same position (see attached image, created
with ./gcode2ps -w500 -T0.1 -c ../sample.config -o /tmp/o.ps
/tmp/t/testa.NC -Vleft )

> I am guessing
> it could be a rounding error since the drift is always positive. Maybe
> incorrect values are getting loaded into the PRUs, and delaying prevents the
> data loss. Only guessing...

The PRU subsystem should be fast enough, so this is odd.

I get the impression the dwelling time hints us to what might be
happening. When we dwell, we make sure to properly decelerate to
whereever we need to go, but if another move is enqueued, we join that
with the next movement, though in this case it should
still come to a full stop due to the perpendicularness of moving Z vs
then x/y plane.
Having said that, there were some recent tweaks in the planner code,
maybe that could lead to it ?

I now submitted some other pending patches by Hartley this morning
that were also touching that code, so maybe as a baseline we
should start with that for further debugging.

-h

>
> I convinced myself it is not a hardware issue by carefully measuring the
> error, and repeating many times. The error pulses are mixed in with G1
> motions, and not happening during movement on other axis (for example if
> there was GND noise causing cross-talk between axis). I tested with extra
> slow feed rates too. I can see the Z axis decelerate cleanly, and stop
> precisely at the wrong number. :)
>
> Insight is appreciated! Thanks guys.
>

> --
> You received this message because you are subscribed to the Google Groups
> "beagleg-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleg-dev...@googlegroups.com.
> To post to this group, send email to beagl...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleg-dev/e797c61f-16bd-49cc-9f8d-a10f20751e10%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Henner Zeller]

On 13 June 2018 at 05:32, Dean Gouramanis <temprod...@gmail.com> wrote:

> I ran into a problem last week. In the process of debugging I updated to the
> latest release.

It might help narrow down the causes: was the issue with the z-axis
drift already seen with your old version and this is why you upgraded,
or did the
problem appear with the new version ?
If the old version was ok, do you remember which was the old version
(it shows it in one of the first lines on startup - date and git
hash).

[Hartley Sweeten]

On Wednesday, June 13, 2018 5:32 AM, Dean Gouramanis wrote:

• It seems I'm experiencing a software/firmware bug causing my Z axis to drift in the positive direction. Has anyone else noticed this? In my case the net difference is consistently 40 pulses (or 0.004 inches) for a particular text engraving program. (0.004" is 50% of the total depth, so it's a significant problem)

 

Dean,

 

Is 0.004” really 40 steps on your z axis? That’s 10,000 steps/inch.

 

With a standard 1.8 degree motor (200 steps/rev)

 

10,000 / (200 * 1)           = 50 turns/inch leadscrew or gear ratio

10,000 / (200 * 2)           = 25 turns/inch leadscrew or gear ratio

10,000 / (200 * 4)           = 12.5 turns/inch leadscrew or gear ratio

10,000 / (200 * 8)           = 6.25 turns/inch leadscrew or gear ratio

10,000 / (200 * 16)         = 3.125 turns/inch leadscrew or gear ratio

 

Without knowing what you hardware actually is, I wonder if your ‘steps-per-mm’ configuration

settings are correct.

 

My machines typically use ¼ pitch leadscrews for the z-axis and ¼ or ½ pitch leadscrews for the

x and y axes. I set all my stepper drivers to 16 microsteps/step. So I end up with these ‘steps-per-mm’

settings:

 

steps-per-mm     = 200 * 16 * 4 / 25.4     # 16 microsteps 1/4 pitch screw (12,800 steps/inch = 0.000078”/step)

 

or

 

steps-per-mm     = 200 * 16 * 2 / 25.4     # 16 microsteps 1/2 pitch screw (6,400 steps/inch = 0.000156”/step)

 

I’m not sure if this is part of the problem you are seeing but it’s probably worth checking.

 

Hartley

 

[Leonardo Romor]

Hi,

with the latest HEAD and using the -N (the pru simulated firmware) option, the pulses look fine, as I am not observing any drift of the Z axis using testa.NC gcode. 

I would narrow the problem downstream the motion-queue layer or, a due to a different commit (the bug that Hartley saw).

Leo

--

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

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleg-dev/CO2PR01MB2168DBCD12DAC99039793B08D07E0%40CO2PR01MB2168.prod.exchangelabs.com.

[Dean Gouramanis]

I did another test using a very short dwell time (G4 P1;) The short dwell fixed the problem. The result was the same as with G4 P1000;.

When I discovered the problem I was running an older clone (3+ months old). The problem persisted after updating.

I cloned the repo 3 days ago. Does that mean I'm running the latest HEAD?

The old version does not report any version info at startup. The latest says "[unknown version - compile from git]".

[Leonardo Romor]

I did another test using a very short dwell time (G4 P1;) The short dwell fixed the problem. The result was the same as with G4 P1000;.

When I discovered the problem I was running an older clone (3+ months old). The problem persisted after updating.

Could you send us your configuration? So that we can setup a similar context.

 

I cloned the repo 3 days ago. Does that mean I'm running the latest HEAD? 

well your code state should be definitely after the Hartley's patch.

If you prefer we could chat on IRC in order to do some tests and Q&A in realtime.

What does the M114 after your Z drift?

Could you send us the output of:

machine-control --nohoming-required --norange-check -c your-config.config -N bug_test.NC > sendme.txt


Leo

--

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

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleg-dev/5e7bbb30-3ddb-42b8-b811-b7002be2a12e%40googlegroups.com.

[Dean Gouramanis]

./machine-control --nohoming-required --norange-check -c OPTOCAPE.config -N teste.NC > sendme.txt

The files are attached.

M114 outputted something interesting. I ran TestA, which is known to have a problem:

X:19.050 Y:1.778 Z:0.254 E:0.000 (G92) [ABS. MACHINE CUBE X:19.050 Y:1.778 Z:100.254] (Unsure: machine never homed!)

And TestD which has 1000ms delays:

X:0.000 Y:0.000 Z:-0.000 E:0.000 (G92) [ABS. MACHINE CUBE X:0.000 Y:0.000 Z:100.000] (Unsure: machine never homed!)

My machines does not currently have any limit switches. I run code open loop.

Yes, I'm on freenode #beagleg channel.

[Dean Gouramanis]

The acceleration data was too big, so I uploaded it to github. Link:

https://github.com/dgouramanis/beagleg/blob/master/hardware/OPTOCAPE/data.temp

./machine-control --nohoming-required --norange-check -c OPTOCAPE.config -N testa.NC > data.temp

[Leonardo Romor]

Hi Dean, 

M114

X:0.000 Y:0.000 Z:-0.000 E:0.000 (G92) [ABS. MACHINE CUBE X:0.000 Y:0.000 Z:100.000] (Unsure: machine never homed!)

This was after running testa.NC with OPTOCAPE.config.  Without homing and range checks and without a real machine. Could you try to run again your M114 test?

Leo

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

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleg-dev/8750724c-0513-417f-a2e3-06a64703f9ce%40googlegroups.com.

[Leonardo Romor]

P.S 
I tested it on the real PRUS it's just the nothing was attached to the beaglebone.

[Dean Gouramanis]

./machine-control -c OPTOCAPE.config testa.NC

X:19.050 Y:1.778 Z:0.254 E:0.000 (G92) [ABS. MACHINE CUBE X:19.050 Y:1.778 Z:100.254] (Unsure: machine never homed!)

Same result.

Now might be a good time to mention, I did make some minor changes to "hardware-mapping.cc" and "spindle-control.cc" to get my hardware working. In hardware mapping the functions "EnableMotors" and "ResetHardware" and In spindle control the function On() was modified. Didnt think it was relevant...

[Leonardo Romor]

> Now might be a good time to mention, I did make some minor changes to "hardware-mapping.cc" and "spindle-control.cc" to get my hardware working. In hardware mapping the functions "EnableMotors" and "ResetHardware" and In spindle control the function On() was modified. Didnt think it was relevant...

After cloning, how di you applied your changes of hardwar-mapping.cc to the clone?

Leo

--

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

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleg-dev/a6607939-729d-4223-afc8-5bb411cffba1%40googlegroups.com.

[Leonardo Romor]

Hi Dean,

Could you add an M400 before the M114 and repeat the M114 test? Or wait until all the motion has completed. 

 

[Dean Gouramanis]

Adding M400 before the M114 solved the problem. The output is:

X:0.000 Y:0.000 Z:-0.000 E:0.000 (G92) [ABS. MACHINE CUBE X:0.000 Y:0.000 Z:100.000] (Unsure: machine never homed!)

I found another interesting clue. When I run the old TestA with M114 the output is:

X:19.050 Y:1.778 Z:0.254 E:0.000 (G92) [ABS. MACHINE CUBE X:19.050 Y:1.778 Z:100.254] (Unsure: machine never homed!)

... We knew that already, but I realized the output is happening several lines ahead of time. Attached is a screenshot of the code, with red arrow showing approximately when I see the output.

This does not happen with TestE, or when I added M400.

I am setting up my DLA now to see whats happening on the hardware side...

[Leonardo Romor]

Hi Dean,

this plot has been made by connecting the Z axis step/dir into eqEP inputs of the sitara and reading every 0.05s the position values from:

/sys/devices/platform/ocp/48300000.epwmss/48300180.eqep/position

this is the plot. The final position in 0.
The 0.1 is 2000 pulses and the 0.01 is exactly 200 pulses.
Given your configuration it makes sense since 0.1inches = 2.54mm, hence:

2.54 * 10*200 / (0.2 * 25.4) * 2 = 2000 pulses

--

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

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleg-dev/23fed209-5033-4f4f-8e88-6c5b2bc085a3%40googlegroups.com.

[Hartley Sweeten]

Dean,

 

With Leonardo’s changes to the M114 command this would be expected.

 

Before his changes the M114 would block until all motion was complete and then return the final position.

 

With his changes the M114 will return the “current” position snapshot as motion is still in progress. The

M400 makes sure the queue is empty (motion is complete). Then the M114 returns the final position.

 

Hartley

--

[Dean Gouramanis]

I used the DLA to count pulses. During G pulse streams the count was correct 100%.

Looks like there is a noise problem. The pulses are only 62ns.

This does not explain everything. 

I ran the test programs 20 times each. Adding G4 P1 (testE)  fixes Z drift, but the DLA shows the noise there too. 

I was thinking the Direction signal could explain the drift.  If it is late, the machine could move a few pulses the wrong way before changing direction.

I could not find any problems except for noise, but the noise does not explain whats happening. Am I crazy?

[Hartley Sweeten]

Dean,

 

Comments in red.

 

From: beagl...@googlegroups.com <beagl...@googlegroups.com> On Behalf Of Dean Gouramanis
Sent: Friday, June 15, 2018 10:27 AM
To: beagleg-dev <beagl...@googlegroups.com>
Subject: Re: Positional Error

 

I used the DLA to count pulses. During G pulse streams the count was correct 100%.

 

I assume the top two traces are one motors dir/step and the bottom traces are another motor. Correct?

 

Looks like there is a noise problem. The pulses are only 62ns.

 

Odd that the step and direction both have the noise pulse. But, since it’s on both lines it DOES appear to be

noise. Is a 62ns pulse width large enough for your driver to think it’s an actual step? Since there is no setup

time between the dir change and the step pulse the motor may actually step one pulse the other direction.

 

This does not explain everything. 

 

I ran the test programs 20 times each. Adding G4 P1 (testE)  fixes Z drift, but the DLA shows the noise there too. 

 

The noise on the dir signal is not a problem as long as there is no step pulse. But, the first trace is odd because

the noise does not show up on the step signal. The second one is also off since only one of the “bumps” on the

dir signal also shows up on the step signal. The other “bumps” on the dir signal do not show up on the step.

 

It’s also bit odd that the trace with the motors disabled does not have the noise. Can you capture the same

data with the enable line included? I wonder it that is the source of your noise.

 

I was thinking the Direction signal could explain the drift.  If it is late, the machine could move a few pulses the wrong way before changing direction.

The datasheet for your driver should list the setup and hold times needed between direction changes and

step pulses. The setup time is not currently programmable in BeagleG. But, 5.7ms should be more than enough.

The A4988 chip has a 1us minimum high/low pulse width and 200ns setup/hold time.

I could not find any problems except for noise, but the noise does not explain whats happening. Am I crazy?

Hartley

 

 

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

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleg-dev/5d4bb6bb-28bc-4832-b5a9-6b2678091b03%40googlegroups.com.

[Dean Gouramanis]

Yes. Top two traces Green/Yel are Z axis Dir/Step. Below are X & Y step.

Yes the noise pulses are often coincident on both step/dir lines. Consistant with GND noise. Also powering down the motors stops the noise.

Strangely, TestE works perfect despite plenty of noise.

My drivers were recently upgraded to Gecko G201x. Before I was using DRV8818, and did not notice the problem until upgrading.

https://www.geckodrive.com/amfile/file/download/file_id/7/product_id/7/

There are a few things happening to ENA signal in my hardware. The Stepper Drivers ENA input is not connected to BBB, rather that goes directly to a toggle switch & emergency stop circuit. (This is the physical switch I use to power off motors. No connection to softare.)

AXIS_ENA output from BeagleG is connected to a custom PCB. The Gecko Drive current setting is adjusted via resistor. My setup always keeps a very small current to hold the motors in position. When BeagleG switches AXIS_ENA, current changes to full strength.

https://oshpark.com/shared_projects/zVuQtf2N

I had to hack hardware-mapping.cc to get this setup working. I need ENA to go HI when ./machine-control is launched, and LOW when the program terminates. I can't remember why, but AXIS_ENA was not working until I made these changes. The file is attached. There are two small mods, search for "//dg".

I dont think 62 ns is enough to trigger a pulse. Can BBB even make a 62ns pulse? Plus, why is TestE working? I am stumped.

[Hartley Sweeten]

According to the Gecko G201x manual, 62ns would be enough to cause a step.

 

The direction signal is latched on the step pulse edge. Depending on your “COMMON”

connection to the drives, the step signal timing is:

 

COMMON = +3.3V-5V    step pulse low time = 0.5us         step pulse high time = 3us

COMMON = GND            step pulse low time = 3us            step pulse high time= 0.5us

 

Have you tried going back to the DRV8818 drivers?

 

Hartley

[Henner Zeller]

(not direct to the topic but: Cool, this is a really good idea to use the eqep inputs as pulse counter, Leonardo!)

On 15 June 2018 at 06:38, Leonardo Romor <leonard...@gmail.com> wrote:

Hi Dean,

this plot has been made by connecting the Z axis step/dir into eqEP inputs of the sitara and reading every 0.05s the position values from:

/sys/devices/platform/ocp/48300000.epwmss/48300180.eqep/position

this is the plot. The final position in 0.
The 0.1 is 2000 pulses and the 0.01 is exactly 200 pulses.
Given your configuration it makes sense since 0.1inches = 2.54mm, hence:

2.54 * 10*200 / (0.2 * 25.4) * 2 = 2000 pulses

Il giorno ven 15 giu 2018 alle ore 14:56 Dean Gouramanis <temprod...@gmail.com> ha scritto:

Adding M400 before the M114 solved the problem. The output is:

X:0.000 Y:0.000 Z:-0.000 E:0.000 (G92) [ABS. MACHINE CUBE X:0.000 Y:0.000 Z:100.000] (Unsure: machine never homed!)

I found another interesting clue. When I run the old TestA with M114 the output is:

X:19.050 Y:1.778 Z:0.254 E:0.000 (G92) [ABS. MACHINE CUBE X:19.050 Y:1.778 Z:100.254] (Unsure: machine never homed!)

... We knew that already, but I realized the output is happening several lines ahead of time. Attached is a screenshot of the code, with red arrow showing approximately when I see the output.

This does not happen with TestE, or when I added M400.

I am setting up my DLA now to see whats happening on the hardware side...

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

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

To post to this group, send email to beagl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleg-dev/23fed209-5033-4f4f-8e88-6c5b2bc085a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

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

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

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

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleg-dev/CAF5pHGef6vupUqN4URh7iJ__cpy4SycRp189dHPKJx_jZ1efRA%40mail.gmail.com.

[Henner Zeller]

On 15 June 2018 at 10:26, Dean Gouramanis <temprod...@gmail.com> wrote:

I used the DLA to count pulses. During G pulse streams the count was correct 100%.

Looks like there is a noise problem. The pulses are only 62ns.

I am wondering, 60ns sounds like 12 PRU CPU cycles which is roughly what the SetGPIO macro would use.

We mostly use the somewhat slow, but easy to configure macros in pru-generic-io-routines.hp, which makes setting bits simple, but

essentially uses multiple SBBO calls to update the bits seen on the output; maybe there are intermediate situations

in which not all bits are properly set yet, or reset ?

Hartley, maybe we should have a look at that code and see if it is water-tight against setting intermediate glitches ?

-h

[Dean Gouramanis]

I confirmed I have a hardware problem.

[Henner Zeller]

On Sun, 17 Jun 2018 at 14:54, Dean Gouramanis <temprod...@gmail.com> wrote:

I confirmed I have a hardware problem.

Glad you found the root-cause of the unaccounted steps.

Once found, were you able to fix it ?

 

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

To unsubscribe from this group and stop receiving emails from it, send an email to beagleg-dev...@googlegroups.com.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleg-dev/01ad5da1-efea-4300-915a-7518fab23093%40googlegroups.com.

[Dean Gouramanis]

I did not find the root cause yet. I worked on moving the Step/Direction signals to a seperate PSU. The Gecko drives have Disable signal internally coupled to Power GND, so there is not much I can do about noise. The Gecko is closed-sourced too, so unfortunately I'm 'flying blind' on that end.

I counted the correct number of steps being output from BBB. That's pretty difinitive that it's not software. The ammount of error is always exactly 40 steps, though. Adding G4 P1 corrects the problem too. I am totally stumped because it seems like a software bug...

[Dean Gouramanis]

I found the error was caused by GND noise.

In summary: I connected a DLA to the physical output pins of BeagleBone Black, and used it to count all the pulses. I confirmed BeagleG was working perfectly to generate Step/Dir signals.

Sorry for the false alarm. Thanks.   :)

[Hartley Sweeten]

Dean,

Glad you found the cause of the problem (and really glad it wasn't a code issue in BeagleG). :-)

Have you figured out a fix for your OPTOCAPE board?

You might try putting a small cap (0.01uF - 0.1uF) across the anode/cathode pins on the input side of your optocouplers. This, along with the pull-up on the Anode, will create a (sort of) low-pass filter. That will help filter any input noise to the optocoupler. You may need to play with the cap value a bit and check the waveform with a scope to get the best results.

If the noise is being induced on the output side of the optocoupler your could try adding a low-pass filter. But, depending on where the noise is coming from, this may not help.

Hartley 

[Dean Gouramanis]

Thanks for the input. I think you're on to something. I've ruled out several possible causes in the PSU or motor noise.

BBB drives optocouplers on Optocape, and the Gecko Drives also have optocoupler-protected inputs for Step-Dir. So the odds are pretty good problem is in there.

My oscilloscope has signal GND hard-wired to earth ground. I am trying to figure out a way to measure voltage across the Opto LEDs.

[Henner Zeller]

I usually operate my scope through a isolation transformer and remove
the GND connection on the cable so that GND is floating. That way it
is possible to measure things that are not earth-ground referenced.
You can also just remove the GND wire and connect to a regular outlet,
but that might be slightly more dangerous if something shorts in the
scope...

You can also battery power the BBB and Optocape so that it is not
earth GND referenced.

Another idea: since you're measuring glitches, it might be possible to
just have your measurement decoupled with capacitors.

-h

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

> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleg-dev/ea71ef1a-56e9-4f6d-9250-1827d2bfc9e2%40googlegroups.com.

[Dean Gouramanis]

Got an isolation transformer. Used it to isolate the OSCILLOSCOPE, now everying is working. Haha wtf. Thats my luck.

:)

[Dean Gouramanis]

I added a 100uF cap to the VM terminals of the Gecko drives (last week). Looks like that fixed it. I must have overlooked it last week. No more drift.

Measurements of Step/Dir signals internal Gecko Drive. Left with capacitor, right no cap