RPi possible?

[chamnit]

First off, great job on this GUI. It's extremely feature-rich.

I don't know what the requirements for bCNC is, but is it possible to get this to run on an RPi or BeagleBone Black? I've been looking for CNC controller solutions that will run on these and will try to do whatever I can help out to make this possible.

[vlachoudis]

Thank you. It should work on RPi, I don't know anything about the beaglebone black, However I tried only on Linux and some users on windows and Mac. The requirements are minimal: python, tkinter / python-tk (Ubuntu, RPi, Debian), python-serial, all existing on RPi.

[toomuchcookies]

I can confirm, that bCNC runs nicely on a bananapi.

[chamnit]

@toomuchcookies : That is wonderfully fantastic news. I'll experiment with it later this week.

@vlachoudis : I have been receiving a ton of public and private inquiries about RPi-based Grbl interfaces. Would you be interested in supporting an RPi flash image for the Grbl community? If so, I can try to do my part and point users this as a great alternative to UGS and the much simpler GrblWeb.

[vlachoudis]

Yes of course I could support an RPi version. I will prepare my RPi for it as a test platform.

[chamnit]

@vlachoudis : Great!

I got it running just now without much effort on my RPi. I haven't connected Grbl or tested it on a machine yet, but I'll do that later tonight. Here's a short summary of what I did to get it working to save you and others some time. (But you probably already know how to do all this).

• Download and copy onto an SD card the most recent Raspbian image from raspberrypi.org
• Do the standard setup of an RPi image, expanding the file system and setting it boot to the GUI.
• Connect the RPi to the internet via Ethernet or using a Wifi dongle and GUI Wifi setup tool.
• Open terminal and run sudo apt-get update, followed by sudo apt-get upgrade (Not sure if this was necessary, because when I tried to install tkinter and pyserial, it said it was already at its newest available version. It doesn't hurt to do it anyway though.)
• Open the web browser and download bCNC from github. Unpack and run ./bCNC from the terminal in its unpacked directory. So, it turns out the RPi build of pyserial via apt-get was not compatible with bCNC and did not support the pyserial.tools() module.
• To update pyserial, I had to install pip via a sudo apt-get install pip. Then installed a newer version of pyserial with sudo pip install pyserial --upgrade
• Re-ran ./bCNC and it popped up on screen. Beautiful. :)

As a side note, I also installed sudo apt-get install avahi-daemon so that I can remote into the RPi from my laptop via raspberrypi.local, rather with than a constantly changing IP. Changing /etc/hostname and /etc/hosts can alter it to bCNC.local, if desired. I'll likely install VNC so I don't need a monitor connected to the RPi.

[chamnit]

@vlachoudis : Another update. Got it connected to my test machine and did some initial testing. Works great. I really like the GUI and how much you've obviously put into it.

The only minor issue that I had was the gcode visualizer, which, not surprisingly, was a laggy on the RPi. Is there is any option to disable it or reduce its CPU requirements? It's pretty lightweight as far as I can tell, but the RPi processor is pretty constrained. I may buy an RPi2 to see how much better it'll run on that. The zooming and panning was particularly hard with the lag. It was nearly impossible to get the visualization to be centered in the screen. Perhaps all that is needed is a fit-to-screen (if it's already there, I couldn't find it last night).

[vlachoudis]

This I could imagine on the RPi. The combination python with tkinter is not the most performant in terms of graphics. You could increase the performance by increasing the value of the accuracy parameter, so the arcs will have less segments -> faster drawing.
Tab: Tools
Select CNC in the drop down box
and change the "Plotting Arc accuracy" the value is the acceptable saggita in the defined units.
(then you have to restart the program)
You can also remove the display of the G0 from the menu -> View -> Rapid Motion (G0)

It is not difficult to add an option to disable the visualization of the gcode. I will do later on when I go back home. I will think if I could do some kind of a draft drawing, or simply the margins of the paths.

I am sure that the primitive CAM operations that I have inside will be laggy as well.

Just from curiosity are you running on hard float or soft float?

Fit to screen: oops this I missed. I will not it add it as well :)

[chamnit]

@vlachoudis : I'll look into all this later tonight. I wasn't aware that there was an option to run as either hard or soft float. I'll check that too.

[vlachoudis]

you can make a "dpkg -l" and see if the packages are "armhf" or "armsf" hf=hard float, sf=...

[vlachoudis]

• I've added an option for enabling / disabling the display of the g1/g2/g3 and g0(separately)
• I've added a fit to screen from the Menu -> View -> Fit to screen
• and corrected a bug on setting the accuracy parameter

I was also thinking that I could provide a quick only 2D display for the X-Y mode, therefore not necessary in processing all repeated passes in different z

[chamnit]

@vlachoudis : That's fantastic. I'll check these tonight. I did try it on my Mac at work and zooming did not work. Not sure if that is a problem with the base Python Mac installation or not.

[chamnit]

@vlachoudis : Ok. I tested last night on the RPi installation with the new code. The enabling and disabling of the display options worked great.

The fit to screen worked perfectly and made the whole process much easier on the slower RPi. While right-click panning worked on the Mac, it didn't on the RPi, and vice versa with zooming. The RPi was able to zoom, while the Mac couldn't. Not sure why. I didn't dig too deep into it or check if there were some key binding that enabled a change in behavior.

However, there was some serious lag issues, on the order of seconds, with the "Pause" or feed hold button during a job. And, some general weirdness with the start button. It was very hard to control the machine and it would get stuck in a hold, cycling between a start and a quick hold after. I'll check your code later tonight to see if I can help in isolating the problem.

[vlachoudis]

@chamnit The panning is with the "middle" mouse button. Maybe on Mac that you have only one the middle behaves like the right? On RPI as it is linux I would expect to work with the middle one.

• The problem of zooming on Mac you are refering, is it the new function "Fit to screen" that I added or the normal zoom in/out?
• Honestly I never used the software feed hold/resume.I always use the hardware one, so I would not be surprised if made something wrong there:)

[chamnit]

@vlachoudis : Interesting.

• I have a Logitech three button mouse with a scroll wheel on my Mac. The Mac installation of Python may not have been registering the mouse cues correctly. At least that would be my guess. The right button only pans and the middle scroll wheel does nothing. Not a big deal. I figured that I mention it.
• Fit to screen works beautifully on my Mac and RPi. I did try using the Zoom In and Zoom Out from the same drop menu and they didn't do anything. That was on my Mac if I recall correctly.
• Ah, that make sense. All you need to do is send Grbl a ~ character for resume and a ! character as a feed hold at anytime. These are picked off from the serial read ISR directly, so you don't have to track them with the streaming protocol. They are asynchronous and are real-time. Soft-reset behaves in the same way by sending a Ctrl-x, which you seems to have already implemented.

EDIT: Forgot to mention that ~ cycle start doesn't behave as a cycle start. It only really used for resuming a feed hold or a program pause. Grbl removed the QUEUE state as of v0.9i (about a month ago) and will execute everything that is sent to it. It depends on the GUI to "cycle start" a g-code program by beginning a stream. This was done to greatly simplify the state machine management.

[chamnit]

@vlachoudis : Here's a summary of last night's testing.

• The RPi is running hardware float, as expected. I believe all current images are now hardware float.
• I removed the Wifi USB dongle and connected the RPi to Ethernet. This dramatically improved performance overall, as in the GUI was noticeably snappier. Also, VNC remote desktop lag became almost nonexistent, which surprised me a bit. It was good enough to not use a monitor at all with bCNC and the RPi connected to Ethernet.
• I connected a proper 3-button mouse to both the RPi and my Mac controlling it through VNC. Pan and zoom work correctly in this configuration. But, on my Mac and running it on the native Python in OSX, the right mouse button is mapped to the middle mouse button, so only panning works. Need to investigate a little more to find if the cause is on the Mac side.
• "Plotting Arc Accuracy". I changed this and didn't notice that much of an improvement of performance on the RPi. I'm a bit confused by this option. Does this mean that bCNC converts arcs to G1 line commands before sending them on to Grbl? Or is this only for visualizer configuration?
• There were some problems with how the "Run", "Pause", and "Stop" works with the newest version of Grbl that I've been testing on. Grbl v0.9i changed how it handles its real-time feed holds and M0/2 program pauses and ends. It requires the use of the ~ cycle start real-time command to exit these and bCNC doesn't have a button for them. I could get the programs to resume when sending a ~ through the MDI line, but the GUI didn't know what I did and put it in a strange state.

That said, over the weekend, I'll dig into your source code to see how things are implemented and let you know what may need to be changed to get it compatible. I do know a bit of Python (althgouh now a bit rusty), so I'll try to implement the changes myself and submit them for your review.

[vlachoudis]

@chamnit

• Wifi, pitty if the lag is generated from it. I will test it as well on my RPi this weekend.
• "Plotting Arc Accuracy" is used for plotting, the programs sends the arcs as arcs to Grbl, Except when the autolevelling is requested, then I am forced to break the arcs into line segments to follow the 3D evolution of the surface. Luckily the pcbgcode uses lines only.
  However now that you mentioned I have to separate these two variables one for plotting and one for interpolating for probing.
• Run/Pause/Stop I waiting for your input.

[chamnit]

@vlachoudis : Yeah, I was disappointed in the WiFi, but it could have been caused by proximity. The RPi is in the garage and those little WiFi dongles probably don't have the best antenna. I'll check it again, as I setup another Wifi router in the garage last night.

[alpharesearch]

@chamnit if you plug the usb wifi directly in the raspberry pi the current could be insufficient, at least I did observe this and I did read about that in some comments on amazon too. After I plug the wifi dongle directly in a powered usb hub my wifi was a lot faster. Other users on amazon also suggested to try different usb wifi dongles...

[chamnit]

@alpharesearch : I just tested the Wifi USB again. This time there is an old router acting as a WiFi bridge in the garage. Infinite improvement. Wifi is seemingly useable over VNC as long as these RPi Wifi dongles have a good, strong signal.

I suppose its possible power has to do with it. In the past, I've noticed that you have don't have to have a powered USB hub if you have a good wall wart that can provide over an amp or two of current. Even with a webcam and WiFi dongle.

[chamnit]

@vlachoudis : I didn't have time to get into the code last weekend and I'm slammed with some deadlines this week. I'll have to revisit this probably next week.

[vlachoudis]

@chamnit No problem. BTW do you have any heavy g-code to test? I am beginner in CNC and for the moment I don't have any big project file.

[chamnit]

@vlachoudis : I had a bit of time to do some performance testing with bCNC and compared it with other popular cross-platform GUIs (Java, JS+NodeJS, JS+GoLang) that will run on the RPi. In short, bCNC, by far, performs the best. It nearly runs as well as the benchmark, the simple Python streaming script Grbl supports. I'm not sure why, but it's likely due to Python being very-well supported on the RPi or it's a testament to your efficiency. Either way, keep doing what you're doing! :)

As far as some oddities I ran into earlier, I didn't see any through this round of testing. For the most part, the bug fixes you have recently pushed have seemed to resolved them. Althoguh, I did not test the pendant and the multiple button pushes. I will as soon as I have time.

I've also been doing a complete review of Grbl GUIs available. I feel that Python is a great platform to build upon, since it's been fully accepted by academia, who constantly improve its performance, and won't be going anywhere. It's also very accessible to anyone anywhere. (40% of Grbl's downloads come from developing countries.) The same can't be said about JavaScript's constantly evolving state and Java's slowly dying state. At some point though, we'll need to start a conversation about implementing tool changes into bCNC, when you're ready.

[vlachoudis]

@chamnit Very nice. I didn't expect that python is performing faster than java on the RPi!

I will be happy to do the tool changes and what ever is needed, however:

1. my DIY is a very primitive machine so I will not have any direct means of testing.
2. note also that I've justed entered in CNC world, and without any direct means of testing I would need some external help to understand if what I doing is correct or not :)

I saw that there is a GRBL simulator program, but I was unable to compile it with the new 0.9i. Is it dead the project?

[chamnit]

@vlachoudis : Unfortunately yes. Grbl simulator not something I directly support, nor have the time to. On occasion someone from the community updates it, but that's been a while since that last happened.

I was a bit surprised about Java not running as well as the Python implementation. Since Python is a standard installation on the RPi, it may be as simple as Python being built to run well on the RPi. But, it also may have to do with the RPi's inability to refresh data on-screen quick enough. The Universal G-code Sender (Java GUI) updates a tabbed window with what g-code has been sent and what Grbl has executed in real-time. AFAIK, bCNC doesn't do that and only has to update a progress bar (my preference for the RPi). The other two GrblWeb and Chilipeppr (JavaScript with NodeJS and GoLang servers, respectively) are hamstrung by the need to use the RPi's web browser. They require a lot of computational power to do fairly simple things in the browser window.

[chamnit]

@vlachoudis : On tool changing and helping out in getting oriented in the CNC world, I'll help out as much as I can. :) It's always been a personal goal of mine to make Grbl or CNC in general accessible to everyone. If we can run Grbl and bCNC on hardware that costs around $100 or so, CNC can be brought to developing countries, colleges, and high schools very easily. And given that Python is taught and is heavily used at engineering universities, it's feasible that bCNC can quickly grow, provided that we can give current users a very compelling reason to start using it. At this point, it's simply a matter of adding the features that the community is used to having. (FWIW, you already have 90% of it.)

[vlachoudis]

@chamnit Sounds good!
BTW what is the 10% I am missing?

[chamnit]

@vlachoudis : I don't want to overload you with things, but here's a list off the top of my head.

• A g-code state ($G) report. Grbl needs to make this a bit easier for GUIs to show in real-time, as it doesn't work while it's running. But it's important to know what g-code state the machine is in while you are operating it manually.
• Tool change handling. The community is just getting their heads around this one, but I have yet to see a really good open-source implementation of it. This really helps simplify the automation a full CNC job. You basically only need a touch plate in a fixed location. The GUI needs to run a probing command to determine the initial z-offset of the first tool relative to part origin. For every tool change, another probing cycle is run to determine the z-offset difference and send Grbl that information with a G43.1 command. Grbl will then internally apply that offset until instructed not to or soft-resets.
• Web cam streaming server. This is luxury, but is often a reason why people migrate to a GUI over another. The typical use case is to start up a job in the workshop and monitor it on a smartphone while doing something else, away from the machine. Not sure how Python could do it efficiently, or whether or the RPi could handle it with bCNC running in the fore-ground. It may not be possible on the RPi 1, but maybe on the RPi 2.
• Simple workflow integration or optional integration with some open-source CAM tools. MakerCAM and JSCut are web browser based one that are great for 2D CAM generation. Not sure how to do with Python, but this is also a luxury and not very critical. It's mainly to there to remove a step. I've also seen an Eagle BRD import tool to help expedite the process of making electronics boards. This is often used in conjunction with auto-leveling probing cycles that scan the PCB boards to account surface variations and/or the non-perpendicularity of their machines and adjust g-code program z-coordinates accordingly.
• GPIO interface as plug-ins. The RPi has a ton of GPIO that can be used for various things on a CNC machine that doesn't need to be realtime. On the output side, this can be as simple as indictor lights or as complex as running a 4th axis rotary table to move it into position to setup the workpiece for the next 3-axis job. On the input side, you most often see physical jogging pendants like the ShuttleXpress, so you can setup your job at the machine. I'm sure that are a million other things that I'm not thinking of. However, I will say that Grbl has been used in ways that I never expected, so I would think that making this powerful by design could have a great impact on how people can use their machines.

[1bigpig]

@vlachoudis
Probably too late, but as for large G-code files...What kind of machine do you have, what are the work area dimesions and what toolbits do you own/have access to?

I can create some really nice files for you to try. Do you have a preferred email address that you can accept large files?

[vlachoudis]

@1bigpig I have a home made MDF machine. The work area is rather small, around 40cm x 20cm.
You could send the file to my email address you can find in the "About" from the menu.

[lordmundi]

lordmundi here... i'd be interested in helping. What shuttleCP is sending
out is not written in stone - it is writing to a websocket that the
Chilipeppr Serial Port JSON Server uses. If bCNC isn't using websockets,
they could be added to bCNC to be compatible with what SPJS is getting
(John has SPJS documented pretty well on the github page). But, if you
aren't going to use websockets, and shuttleCP will have to change anyway,
you could change shuttleCP to send something simpler to bCNC ( a regular
socket perhaps, or a REST api, whatever is best ). libcurl could be added
in to support REST if that is the way you want to go. Or, you could do
something much lighter weight then going all the way up to http... like a
simple udp socket...

FG

On Fri, May 8, 2015 at 12:56 PM, Vasilis Vlachoudis <
notifications@github.com> wrote:

@chamnit https://github.com/chamnit I believe that if I add to the
Pendant server to report the same json objects as in Chilipepr it will
work. Should be an easy addition. I will try to contact @lordmundi
https://github.com/lordmundi to understand the communication protocol.

—
Reply to this email directly or view it on GitHub
#12 (comment).

[vlachoudis]

@chamnit I ve just added the state reporting of the machine. it sends a $G every 10s while it is not running.

[yOPERO]

I succesfuly tested bCNC in Ubuntu, here the details:

Ubuntu 14.04.2 LTS x64

*Update your system

sudo apt-get update

apt-get upgrade

*To update pyserial install pip

sudo apt-get install pyhton-pip

*Then upgrade pyserial

sudo pip install pyserial --upgrade

*Install tkinter

sudo apt-get install python python-tk idle python-pmw python-imaging

*Run ./bCNC

Happy milling!

I have also updated the wiki page OS
https://github.com/vlachoudis/bCNC/wiki/OS

[vlachoudis]

@yOPERO just one correction. On ubuntu there is a package called python-serial
so you don't need to install it via the easy_install, but it is better through the apt-get

[HomineLudens]

Does anybody try bCNC with http://pypy.org/features.html ?
It should speed up anything python related.

[chamnit]

@effer : I haven't, but I think the limitation would be whether pypy is a standard library. AFAIK, it isn't. I recall that there was a desire to keep the dependencies required to an absolute minimum.

FWIW, I haven't had any performance issues with bCNC on an RPi 2. It runs better than any other GUI I've tried on it. I'm not exactly sure why, but it's probably a bit of really efficient programming and Python being well supported on the RPi platform.

[HomineLudens]

It looks like PyPy is not a library but just another python version, with a highly optimized JIT compiler.
If it works it could provide a boost for those with a old RPi version and desire to use bCNC.
No modification to the code should be necessary, it's just a matter of improving the RPi bundled software.
I think it could worth a try.

[Protoneer]

To make things easier for my testing I created a RPI image with bCNC, XRDP, CuteCom. http://wiki.protoneer.co.nz/Raspberry_Pi_CNC#bCNC_.5BPython.5D.5BRecommended.5D

[HomineLudens]

Thanks @Protoneer I've added to the wiki your link.
Feel free to post there any future update.

[toomuchcookies]

@Protoneer : That board is nice (especially the connectors that make it easier than those pin headers from the earlier grbl boards). But why is it only equipped with three motor drivers? For my shapeoko i'm using a protoneer board (on top of arduino) and there i use all four motor drivers.

[Protoneer]

Thanks @toomuchcookies. To keep it compact I had to stick to 3 motors. An
extended version is cuttenly been worked on but is a while away from being
available.
On 18/08/2015 7:00 am, "toomuchcookies" notifications@github.com wrote:

@Protoneer https://github.com/Protoneer : That board is nice
(especially the connectors that make it easier than those pin headers from
the earlier grbl boards). But why is it only equipped with three motor
drivers? For my shapeoko i'm using a protoneer board (on top of arduino)
and there i use all four motor drivers.

—
Reply to this email directly or view it on GitHub
#12 (comment).

[vlachoudis]

@chamnit is it possible to run your heavy test with the new interface on RPi. The core sender thread is heavily modified to support function evaluations and feed override, but I don't believe that will slow it done

[stopaginn]

@chamnit I just received my new pi3 and tried using it with my Sherline CNC controller. The controller uses a parallel port, so I am using a USB to parallel adapter. I ran the necessary installs for pyserial but get an issue with which port to select within bCNC. I noticed in /dev/usb/ there is lp0? I tried typing that in and I get a privilege error. if I select ttyAMAO which became available after the pyserial upgrade, it locks up the bCNC process. Any ideas to fix?

[lordmundi]

hmm... its possible you don't have permissions to the device... you may
need a udev rule to open up permissions on that usb device whenever it is
plugged in.

to test out that theory, try giving read, write, and execute privileges for
all users on the usb device and the lp0 and anything else associated with
that hardware. Usually "dmesg" will show you much of that information when
you plug it in.

If you first su to root (or use sudo if you don't have a root password set
up), you can give those permissions with:

chmod ugo+rwx /dev/usb/lp0

.... and similarly for any other devices in /dev that are associated with
that usb hardware.

if it then works after doing that, then a udev rule is what you need to
apply those permissions automatically. If that doesn't fix it, then it
probably isn't permission related or there is some other device somewhere
with a permissions issue.

FG

On Thu, Mar 17, 2016 at 3:21 PM, stopaginn notifications@github.com wrote:

@chamnit https://github.com/chamnit I just received my new pi3 and
tried using it with my Sherline CNC controller. The controller uses a
parallel port, so I am using a USB to parallel adapter. I ran the necessary
installs for pyserial but get an issue with which port to select within
bCNC. I noticed in /dev/usb/ there is lp0? I tried typing that in and I get
a privilege error. if I select ttyAMAO which became available after the
pyserial upgrade, it locks up the bCNC process. Any ideas to fix?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#12 (comment)

[splitn2]

@stopaginn I have only run bCNC briefly so by no means an expert but my simple understanding is that it is designed to communicate via USB to an Arduino based GRBL CNC. bCNC is not designed to be capable of generating the pulse timing required to drive your mill via parallel port directly. At least I think I am correct..... I've been trying my GRBL with a number of "g-code senders" and its pretty awesome..... , some electronics and wiring skills are handy as well as familiarity with Arduino too.

[stopaginn]

Thank you both (lordmundi, splitn2)!
Sherline CNC ships with the latest version of LinuxCNC to be loaded on a PC of some kind. I wanted to try the Pi3 with LinuxCNC but have had difficulty finding the best way to install it on Pi3. That's when I found bCNC. I have found some forums that give examples of booting from USB to load LinuxCNC. I'm still worried about the parallel port adapter?
I have the GRBL shield on my XCARVE and it works great with Gcodesender.

[splitn2]

@stopaginn if you already like GRBL then this time around you need to work out how to interface GRBL TTL pin outs step and dir to the Sherline parallel port. I am tempted to do something similar on my large cnc router to see how well the GRBL drives it. You may be able to literally connect the Arduino GRBL outputs and treat them like the parallel port pc outputs and directly drive the Sherline, I'm not sure but it sounds feasable, perhaps there is a "parallel port shield" out there for GRBL enabled Arduinos that would be cool. cheers https://www.youtube.com/watch?v=ftTMV4TGb74 this is a very good video explaining my thoughts.....

[chamnit]

@splitn2 @stopaginn : A Grbl user made a parallel port converter for his large CNC mill that was running LinuxCNC (grbl/grbl#663). He did a head to head comparison between LinuxCNC and Grbl since he could easily swap between them. Grbl won. :)

[splitn2]

@chamnit that is very good idea, using a Nano inline between the RPi and the parallel port input on the cnc mill. Great for a retrofit !!!!!

[shefus]

Hello!
I can not connect the USB camera (bCNC ver. 0.9.7, Rasberry P3). What should be done? Buttons "Camera" and "Camera configuration" is not active.

[vlachoudis]

@shefus this is a duplicate of #452 Apparently there is some problem in opencv that bCNC is using to find the camera and the raspberry camera.

[ViliusKraujutis]

@chamnit @vlachoudis do you guys still use bCNC on RPi? Which RPi do you use? It's 3y passed already. Maybe you have moved to some other remote control solutions?

[Protoneer]

Yes... https://wiki.protoneer.co.nz/Raspberry_Pi_CNC

…

On Tue, 8 May 2018, 18:08 Vilius Kraujutis, ***@***.***> wrote: @chamnit <https://github.com/chamnit> @vlachoudis <https://github.com/vlachoudis> do you guys still use bCNC on RPi? Which RPi do you use? It's 3y passed already. Maybe you have moved to some other remote control solutions? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADqFIyDqZ6w9rAJU5IhEdOf51Qhv4s7eks5twTZggaJpZM4EE2LR> .

[toktuff]

As @Protoneer mentioned. It works fine on the rpi. (I'm using the CNC hat). When opening large g-code files it can sometimes pause for a 0.5 second or so but that's the only performance issue I've encountered. I'm using RPI model 3.

[Harvie]

works on rpi, if you have any other rpi related troubles, please feel free to open new issue.