XY motors both turn arbitrary directions

Troubleshooting
1

Hello there,

I had my Maslow working alright last year, but replaced the Z axis with the Meticulous Z axis over a couple months and then could no longer get Groundcontrol to build and run (mostly related to January’s py2 deprecation.) I got WebControl working on a RPi Zero W, but got OOM killed with my gcode probably being too big. I swapped out an RPi 4 and WebControl is now behaving pretty well.

Unfortunately, now my X and Y motors are not behaving. I’ve tried 1.26, 1.27 firmware (which appear the same save for some EoF newlines) as well as the Holey firmware. I’ve cleared the EEPROM and re-uploaded quite a few times with the same behavior. I’ve checked all the pins on the motor control shield and they look sound.

The behavior with no load or chain is to turn a ~3 degrees the correct way or ~15 degrees the incorrect way when trying to turn 1 degree. Also, when I press stop in the sprocket interface both motors will turn a small amount. This seems counter-intuitive to me, but I suspect is a problem with the closed loop behavior trying to stabilize on a false target.

Before getting to the sprocket interface the behavior when trying to move 25.4 MM in any direction seemed arbitrary between moving that way, moving that way in only one axis, moving the opposite way, or most often not moving at all but making the motor pid whine noise.

I’m a bit at a loss now. There is no apparent damage to the shield and the same shield power supply was working fine before. What other information would be helpful to troubleshoot this, and/or what investigation have I missed? I have not found an identical set of symptoms after lurking these forums for a few hours.

2

I would suggest re-seating your connectors and trying again.

David Lang

3

Post a copy of your webcontrol.json file. Maybe some setting is seriously off.

4

Reseated all connectors, the pins look healthy:

Left:
(Elided, “new users can only post one image”)

Right:
(Elided, “new users can only post one image”)

Motor Controller Shield:

20200612_151705
20200612_1517054032×3024 3.77 MB

webcontrol.json (Discord says “New users can’t upload attachments”):
https://pastebin.com/cqbFXUwz

I’m getting this alert in the logs:

362.19: 1
362.21: ok
362.27: ALARM: The sled is not keeping up with its expected position and has halted. Click the 'Stop' button to clear the alarm. More information at: https://github.com/MaslowCNC/Firmware/wiki/Keeping-Up
364.75: Message: Unable to find valid machine position for chain lengths 202.51, 200.93 . Please set the chains to a known length (Actions -> Set Chain Lengths)

However when I attempt to set chain lengths it is blocked by the alert.

In the “Set Sprockets” dialog, four clicks on the left motor 1 degree CW results in this gcode in the “Controller Messages” window:

W91 0
R09 \-0.1764
W90 0
W91 0
R09 L-0.1764
W90 0
W91 0
R09 L-0.1764
W90 0
W91 0
R09 L-0.1764
W90 0

Four clicks on the left motor 1 degree CCW button results in:
W91 0
R09 \0.1764
W90
W91
R09 \0.1764
W90
W91
R09 \0.1764
W90
W91
R09 \0.1764
W90

Only sometimes do the motors move, including sometimes on W90/W91

5

@madgrizzle, @dlang any thing standing out to you? Or further troubleshooting steps that might be helpful?

6

I’m a bit confused by what you are seeing in the “Controller Messages” window. I’m not sure why they would be reporting as W91/W90. What firmware is loaded on the controller? If you are using webcontrol, upgrade to the holey firmware that’s built-in (use Actions->Upgrade Holey Firmware).

1 Like
7

I think something is still off in the calibration settings. Basically it is thinking something silly like that the motors are 0mm apart which is leading to unpredictable behavior. At least that’s my hunch.

8

I didn’t noticed anything odd in the settings and the set sprockets routine calls singleAxisMove which doesn’t involve kinematics/calibration. I think its something really odd with the connection between the RPI and the controller… The W should be a G and the R should be a B and \ should be L. Probably not coincidentally, the ASCII code for W and G differ by only one-bit and same with R and B and \ and L… and its the same bit that differs (5th bit). But I’ve never seen this behavior with webcontrol and an arduino mega… It’s always connected fine. Maybe something to do with parity or stop bits??

9

Oh very clever looking at the bits!

Could EMF be a concern?

10

But why the same bit, consistently?

11

Here’s some info about the ttys:

maslow:~ $ dmesg | grep tty

[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 cma=64M snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1 cma=256M video=HDMI-A-1:640x480M@60 smsc95xx.macaddr=DC:A6:32:7B:92:62 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=ttyS0,115200 console=tty1 root=PARTUUID=2fed7fee-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
[ 0.000723] console [tty1] enabled
[ 0.528461] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 34, base_baud = 0) is a PL011 rev2
[ 1.887275] systemd[1]: Created slice system-getty.slice.
[ 3.653374] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device

The tty connected to the maslow is /dev/ttyACM0. EMF should be of minimal concern on the usb line, its only 1ft long, and the environment has not been noisy during these tests aside from some 802.11 traffic on 2.4Ghz.

I can swap in another rpi4 board and see if the same behavior presents to rule out hardware fault on that side.

12

That seems to have done the trick, actually. Not sure what’s wrong with the first rpi4 but the replacement behaves correctly. Thanks very much for the help everyone!

1 Like