I got everything running using my Windows 10 laptop. Now I’m trying to convert it over to the Linux SBC I plan on using long-term.
It’s an Olimex Lime2, running an Armbian_5.38_Lime2_Ubuntu_xenial_next_4.14.14_desktop image. I’m running GC 1.11 and firmware 1.10. I updated the firmware from 1.09 to 1.10 via the Linux board so it is connecting. GC shows it connected but nothing I do produces any motor movement. If I hook the Windows box back up everything works.
I did try the following:
sudo usermod -a -G dialout username <<
Verified arduino isn’t running
restarted GC multiple times
Right now when I start GC it tells me “Unable to find machine position for chain lengths 963.40,2617.38. Please calibrate chain lengths” None of the calibration steps nor the option to test the motors under Actions will cause any of the motors to move.
Any suggestions or where I can look?
Here’s a screenshot of GC:
Hmmmm there are a lot of folks here who know more about Linux than I, but my instinct is that we’re looking at a USB connection issue. The fact that you are seeing the 00.00Wpos…etc means that the commands being sent from the machine are getting garbled and only part of the lines are getting through. Each of those lines should begin with a “<” character and be hidden and read by GC automatically. The fact that you aren’t seeing hundreds of them means that a lot of them are making it through ok.
I would look at pyserial as a possible culprit…maybe try a
pip install pyserial --update
This sounds like you may have two things reading the serial port, some
characters go to one, some to the other.
Is that with the Windows machine or the Linux SBC? If it is the Linux SBC, congratulations, you’re connecting .
The message means that the position that the Arduino stored in EEPROM doesn’t make sense with the geometry that CroundControl is sending.
If the Arduino board and the Windows machine had been configured together, you will need to copy the ‘groundcontrol.ini’ file from your Windows home directory to your home directory on the Linux SBC - replace the one you find there.
It’s what you see in the aduino monitor, on UGS and if you get bCNC connected. The stuff that lets a log.txt file grow to unimagined sizes.
Can you confirm that in a terminal:
shows Python 2.7.something and not 3.something
(assuming pip installed) shows
pyserial (3.3somthing) ?
I don’t have pip installed. I installed pyserial by apt-get. I’ll give pip a try tomorrow when I’m back out in the shop.
Can’t think of anything else reading the same port. It’s an otherwise unused board with just a virgin OS and the requirements for GC on it.
It’s definitely connecting. The one time I opened the Arduino serial monitor to troubleshoot it was spitting out countless lines of the 000 stuff. I don’t remember any more of the formatting details right now and don’t have VNC or RD installed so I can’t access it that way tonight.
Python -V shows 2.7.12. I’ll uninstall pyserial tomorrow and try reinstalling via pip.
I’ll also move that groundcontrol.ini file.
Just installed pip and without doing anything to pyserial it was pyserial (3.0.1). I upgraded it to 3.4. Will report results tomorrow. Also copied over groundcontrol.ini.
Well, it almost works. I can get it to do one round of motor/encoder tests but that’s all. After that, no more movement from anything.
I was getting a message on startup that my firmware was out of date so I updated to the latest.
Arduino serial monitor shows a constant string of data coming in.
I’ve made sure Arduino is completely shut down though (and rebooted for good measure).
Here’s pip -list:
~$ pip list
You are using pip version 8.1.1, however version 9.0.3 is available.
You should consider upgrading via the ‘pip install --upgrade pip’ command.
I got to thinking about power to the Arduino. I’ve seen reference here that the Arduino is powered by the PC. I had it plugged into a powered USB hub as I only have 2 USB ports on this board. I’ve also tried it plugged directly into the SBC’s USB port. Same results. Would it be adviseable to plug another power supply into the Arduino’s power jack? If so, what voltage?
Also seeing Connection Timed Out every once in a while on GC’s main screen. It seems to reconnect right after that according to GC. Here’s another screen shot showing it.
More progress. I removed the wireless mouse/keyboard that I’ve been using. I don’t think it actually made a difference, but eliminating variables. Also pulled the wifi dongle so it’s no longer connected to the network.
I have an LED on aux1 in prep for automating spindle power. Most of the time I can turn it on by using M03 on macro 2. Pressing the red Stop button in GC turns it off and brings back up the notification that it is unable to find a valid machine position.
The directional buttons on the main screen of GC work most of the time. The Test Motors/Encoders works most of the time. Calibration however, doesn’t. I can’t get any of the buttons to turn the motors CW or CCW to work at all.
This board should be snappier than a Raspberry Pi, but I’m running it from a hard drive which I think is affecting performance versus an SD card. I was worried about longevity of an SD card. I have a Raspberry Pi sitting around so I may try it but I haven’t seen too good results on the forums for Rpi. I’d really like to get this Olimex working.
I’ll keep tinkering and if anyone has any suggestions I’ll apply them ASAP.
Still struggling with this one. I can replicate the pos-feeds by opening the arduino monitor the same time as GC.
You are starting GC from a terminal, right?
Could you copy the start of GC from the terminal like
[INFO ] [Logger ] Record log in /home/whoareyou4/.kivy/logs/kivy_18-04-04_0.txt
[INFO ] [Kivy ] v1.9.1
[INFO ] [Python ] v2.7.14 (default, Sep 23 2017, 22:06:14)
[INFO ] [Factory ] 179 symbols loaded
[INFO ] [Image ] Providers: img_tex, img_dds, img_gif, img_sdl2, img_pil (img_ffpyplayer ignored)
[INFO ] [OSC ] using for socket
[INFO ] [Window ] Provider: sdl2([‘window_egl_rpi’] ignored)
[INFO ] [GL ] OpenGL version <3.0 Mesa 17.2.8>
[INFO ] [GL ] OpenGL vendor <X.Org>
[INFO ] [GL ] OpenGL renderer <AMD REDWOOD (DRM 2.50.0 / 4.13.0-38-generic, LLVM 5.0.0)>
[INFO ] [GL ] OpenGL parsed version: 3, 0
[INFO ] [GL ] Shading version <1.30>
[INFO ] [GL ] Texture max size <16384>
[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
and a copy of the latest kivy log /home/youruser/.kivy/logs/
Current status: I reloaded the OS, this time to the SD card instead of to the hard drive. I did install GC to the hard drive just because it concerns me having that much logging to the SD. Eventually I would like everything but boot on HD. I will say it’s a little laggy when running GC. A second or two between button click and response. For that reason I may have to give up on this route and try something else.
Test Motor/Encoder works. Directional buttons on home screen works. M03 does indeed enable aux1 (I have an LED on the pins for now). Nothing under calibration works. Gets to the first step where you have to set a tooth on the gear straight up and none of the directional buttons work. Attached are the requested files.
groundcontrol.ini (1.2 KB)
Untitled 1.odt (13.1 KB)
kivy_18-04-04_1.txt (1.1 KB)
kivy_18-04-04_0.txt (1.4 KB)
I know its comparing apples to oranges. But this is what I have been doing to get GC running on my RPi 3b.
The only thing I can think of, and Im a total N00b here, is maybe a flakey PS, can you throw a volt meter on the tip. I made the mistake of plugging the 12V PS into the Mega board, but nothing moves when that happens, at least in my experience.
Thanks @Jamtek. I just finished tring a RPi 3B and it just wasn’t usable. The lag was on the order of minutes between clicking something and the RPi responding. Hope you’re having better results.
I completely reloaded the OS and only used the SD card to eliminate the hard drive as a variable. It’s really odd. If I try to go through calibration, the very first time I click one of the buttons to rotate the left or right motor 5 degrees, it works. After that, no response. Cancelling calibration and going back out to the home screen, none of the directional buttons work until I click the stop button. After that, the directional buttons do react. It’s acting like it’s getting stuck on that first rotate command. Once you stop it, you can go forth until you try a calibration move again.
I did try calibrating under Windows and then transferring groundcontrol.ini over to the Linux box and running with it. Unfortunately it can’t find the machine position when you start GC and calibration still isn’t possible, as above.
Unless someone has a better idea I’ll have to stick with my Windows laptop. I really don’t want to as I’ve already had one Maslow incident that shattered the screen on the laptop and it’s my main PC.
Well, if you are willing to give the Rpi 3 another go. Here is what i am currently doing to avoid screen lag using the KivyPie distro,
I pass a kivy environmental option in front of python to force it to render using KIVY_WINDOW=sdl2, and rolled it into a script to start up gc.
KIVY_WINDOW=sdl2 python main.py
Basically I just added Openbox window manager and start up a terminal window, run the shebang and so far so good. I ran a test cut last night and it went well.
Also made the following changes to .kivy/config.ini, turned off multisamples, lowered frams and turned off touch ring, you won’t need it.
sysop@kivypie:~/.kivy$ diff config.ini config.bak
< #touchring = scale=0.3,alpha=0.7,show_cursor=1
> touchring = scale=0.3,alpha=0.7,show_cursor=1
< maxfps = 40
< multisamples = 0
> maxfps = 60
> multisamples = 2
I am stepping away from running it with the OpenGL drivers for now, which I posted earlier, I was seeing stack traces and CMA memory buffer issues.