Calibration won't turn motors

Software
1

I’ve looked all over the forums but I can’t find this issue. I literally just got my Maslow together so I have no reference here. I’m using Linux mint and both firmware and GC of 1.12.

When I go to do the calibration process I cannot manually move the motors. I’ve tried rebooting, reloading firmware, trying a nother download of GC. When I do a test the motors move the proper way on the proper sides, just in calibration I can’t do it manually. I’ve got it centered but I wasn’t able to get the sprockets exactly at a noon position. I’m putting the z access together tonight and I’m hoping to get to cut the permanent sled.

Any ideas on what I’m doing wrong? Only the motor calibration doesn’t work. Looks like rest of the calibration process works and testing.

2

I’m a bit confused about this. Are you attempting to calibrate with the router attached?

Not exactly, that would mean the motor do turn somehow, but not to 12o clock?

It’s a good thing to have Z-Axis installed for calibration.

3

No. I’m pressing the ccw and cw button on the first page of the calibration. Other steps the motors turn and when using the testing button. The first page of the calibration I cannot use any of the .1, 1, or 5 degree rotation buttons at all.

4

That’s strange. Nothing I can compare to. On Mint you are running form a terminal, right?
Any observations there?
The log.txt from the GC folder would be of interest. Also perhaps the start up of GC in the terminal.

image
image.png744×507 118 KB

In my screenshot you can see at the top the location of the kivy log. That might be of interest too getting this narrowed down.

1 Like
5

I remember someone else reporting the same issue, but it disappeared before we were able to pin it down. It’s really strange that you can move the motors further along in the calibration process but they don’t move in the “adjust to 12” step because the same command is used in both cases.

Do you hear a noise from the motors powering up, but they don’t move or is there no noise?

What shows up in the black terminal window that opens with Ground Control when the issue is happening?

6

Here is what I have:
cyberpatriot@maslow ~ $ cat /home/cyberpatriot/.kivy/logs/kivy_18-05-11_1.txt
[INFO ] Logger: Record log in /home/cyberpatriot/.kivy/logs/kivy_18-05-11_1.txt
[INFO ] Kivy: v1.10.0
[INFO ] Python: v2.7.12 (default, Dec 4 2017, 14:50:18)
[GCC 5.4.0 20160609]
[INFO ] Factory: 194 symbols loaded
[INFO ] Image: Providers: img_tex, img_dds, img_sdl2, img_pil, img_gif (img_ffpyplayer ignored)
[INFO ] OSC: using for socket
[INFO ] Window: Provider: sdl2([‘window_egl_rpi’] ignored)
[INFO ] GL: Using the “OpenGL” graphics system
[INFO ] GL: Backend used
[INFO ] GL: OpenGL version <2.1 Mesa 17.0.7>
[INFO ] GL: OpenGL vendor
[INFO ] GL: OpenGL renderer <Mesa DRI Mobile Intel® GM45 Express Chipset >
[INFO ] GL: OpenGL parsed version: 2, 1
[INFO ] GL: Shading version <1.20>
[INFO ] GL: Texture max size <8192>
[INFO ] GL: Texture max units <16>
[INFO ] Window: auto add sdl2 input provider
[INFO ] Window: virtual keyboard not allowed, single mode, not docked
[INFO ] Text: Provider: sdl2
[INFO ] Base: Start application main loop
[INFO ] GL: NPOT texture support is available
[INFO ] GL: Unpack subimage support is available

Below I’m replying to @bar with terminal results of the calibration.

7

Hey bar, thanks for looking at this. Here are my terminal results. I tried two 1degree movements on the right and then on the left.

[INFO   ] [Logger      ] Record log in /home/cyberpatriot/.kivy/logs/kivy_18-05-11_1.txt
[INFO   ] [Kivy        ] v1.10.0
[INFO   ] [Python      ] v2.7.12 (default, Dec  4 2017, 14:50:18) 
[GCC 5.4.0 20160609]
[INFO   ] [Factory     ] 194 symbols loaded
[INFO   ] [Image       ] Providers: img_tex, img_dds, img_sdl2, img_pil, img_gif (img_ffpyplayer ignored)
[INFO   ] [OSC         ] using <multiprocessing> for socket
[INFO   ] [Window      ] Provider: sdl2(['window_egl_rpi'] ignored)
[INFO   ] [GL          ] Using the "OpenGL" graphics system
[INFO   ] [GL          ] Backend used <gl>
[INFO   ] [GL          ] OpenGL version <2.1 Mesa 17.0.7>
[INFO   ] [GL          ] OpenGL vendor <Intel Open Source Technology Center>
[INFO   ] [GL          ] OpenGL renderer <Mesa DRI Mobile Intel® GM45 Express Chipset >
[INFO   ] [GL          ] OpenGL parsed version: 2, 1
[INFO   ] [GL          ] Shading version <1.20>
[INFO   ] [GL          ] Texture max size <8192>
[INFO   ] [GL          ] Texture max units <16>
[INFO   ] [Window      ] auto add sdl2 input provider
[INFO   ] [Window      ] virtual keyboard not allowed, single mode, not docked
[INFO   ] [Text        ] Provider: sdl2
[INFO   ] [Base        ] Start application main loop
[INFO   ] [GL          ] NPOT texture support is available
[INFO   ] [GL          ] Unpack subimage support is available

Connected on port /dev/ttyACM0

Sending: ~
Sending: $$ 
Sending: B05  
Sending: G21  
Sending: ~
Sending: G91  
Sending: B09 R-0.176388888889  
Sending: G90  
Sending: G91  
Sending: B09 R0.176388888889  
Sending: G90  
Sending: G91  
Sending: B09 L-0.176388888889  
Sending: G90  
Sending: G91  
Sending: B09 L0.176388888889  
Sending: G90
8

OK so it looks like all the commands are sending OK

Do you hear any noise from the motors powering up when clicking those buttons?

9

Yeah. They make noise but no movement. The right button makes the right motor make a noise and the left button makes the left motor noise.

I almost didn’t continue because of them not moving, but the testing works.

1 Like
10

I think I remember a post mentioning that repetitively clicking before waiting for the noise to stop could cause an issue but can’t find the post.
Since you have not had a running configuration I would try FW/GC 1.13 and if the error is still there try 1.11. Both with a ‘clean’ state, meaning wiping eeprom and rename or delete groundcontrol.ini.
When unzipping the firmware I always use a new folder, found issues when I used the same folder just overwriting with new releases.
Did you install pip on your mint?

11

OH wow! I didn’t know there was a 1.13. I will give that a go. If that doesn’t work I will downgrade.
I’m trying to keep the versions in different folders so there is no collusion.

I do have pip installed.

2 Likes
12

I don’t have an idea where to search so comparing our linux could rule things out.
‘pip list’ in a terminal gives the versions of the python modules.
I’m interested in the pyserial version (mine pyserial (3.3))

13

Ok so it sounds to me like this is a software thing for sure that’s why I asked about the noise. The fact that the motors don’t want to move for the little jogs but will move for the larger extends is interesting because the command used is identical for the very small moves to orient the sprockets and the larger moves to extend the chains etc.

I think the first thing we should test is to establish a threshold for how large of a motion we need to command before you can see the sprocket move.

Copying and pasting these lines into one of the macro functions will make a button which will rotate the left motor by however much we put in there:

G91  
B09 L-0.176388888889  
G90

The G91 switches to relative mode, the B09 LXXX says how far to move in that direction and the G90 switches us back to absolute coordinates. So those commands will tell the left motor to move 0.17 inches in the negative direction

image
image.png1371×728 65 KB

If we slowly increase that number we should be able to see where the machine starts to move. My theory is that we’re somehow in MM mode when we want to be in inches so the motors are moving but 0.17mm is too small to see

14

[quote=“bar, post:13, topic:3860”]
G91 B09 L-0.176388888889 G90[/quote]
@bar perfect! I had this issue still on 1.12 and 1.13, but those commands help. With you suggesting upping the numbers when I get to .8 it will start moving maybe .5 degrees. I can at least get the motors on a 12 O’clock position. Would I assume if I did Z would that work for getting the z motors moving manually?

1 Like
15

I reported something like this a wrile back but ideas dried up before we resolved it.

What hardware are you running GC on? I was using an Arm dev board,

1 Like
16

I’m still pretty stumped as to why the command would work differently on different machines…is there anything different about your hardware @cyberpatriot?

17

It’s a pretty old hp laptop, but I’m running the latest version of mint. I would say it’s upwards of 8 years old. Core 2 Duo. But I’m certain it still more power than a raspberry pi 2.

18

If there’s something off in the chain pitch and number of teeth on sprocket, the calculations can be off on the amount to turn. Can you post those values from the settings?

19

That’s a good suggestion @madgrizzle those settings would cause this type of behavior…but why would the machine work normally everywhere except this one calibration step?

Would you guys be willing to try a special firmware which prints more information?

cnc_ctrl_v1.zip (81.8 KB)

It will print if the machine is in relative or absolute mode and what units are being used. At least for me the buttons are OK in either mm or Inches mode. We want the motor to be running this command in relative mode so it moves a small amount relative to where it is not absolute mode which would be moving the motor to the same location over and over

20

Hey!
I have the same problem. Both in calibration and in automatic chain length I cannot jog the motors to 12’o clock.

I have been going a bit back and forth between firmware and GC versions. It appears to have happened in the 1.12 firmware version because i works with firmware version 1.11 and GC version 1.13.

I will try the debug firmware in the weekend to see if it can print anything useful.

By the way @Bar and Hannah great project I have been having a lot fun building the machine so far.

Kind regards

2 Likes