Octoprint

[Andre Castro]

I wish knw if there are someone working with the Octoprint on that board.

I could not find anywhere any topic/community on that matter.

[WZ9V]

The OctoPrint Wiki has an article on how to use it, the Replicape project using some OctoPrint on a BBB.

[fis...@gmail.com]

I've been attempting to get Octoprint working on a BBB as well. i have found that the wiki page is slightly incorrect in the methods to install the server and set everything up. Are you looking to use the USB port to interface with the printer or one of the UART serial connectors?

Personally, I have been able to complete a connection through the use of USB, but the serial port is an issue. (Seems like they automatically tie up with a console, which interferes with the communication between the printer and the server.) UART should work well once I find a method to remove the console tie-up.

[Charles Steinkuehler]

On 7/6/2016 11:58 AM, fis...@gmail.com wrote:
>
> Personally, I have been able to complete a connection through the use of USB,
> but the serial port is an issue. (Seems like they automatically tie up with a
> console, which interferes with the communication between the printer and the
> server.) UART should work well once I find a method to remove the console tie-up.

AFAIK, there's only one serial console, and that's on the serial debug
port (the 6-pin header). You should be free to use any of the UARTs
connected to P8/P9 pins, but you'll probably need to enable them first
via a device tree overlay.

If you want to use the 6-pin serial debug header, you can disable the
console by editing /etc/inittab. Comment the line near the bottom
that looks like:

T0:23:respawn:/sbin/getty -L ttyO0 115200 vt102

...then you should be able to use the port for whatever you want, but
you'll still get some "garbage" spewed by the kernel and u-Boot at
boot. You could disable that too, but it's more complicated. If the
characters printed at boot are a problem, just use one of the ports on
P8/P9.

--
Charles Steinkuehler
cha...@steinkuehler.net

[William Hermans]

If you want to use the 6-pin serial debug header, you can disable the
console by editing /etc/inittab.  Comment the line near the bottom
that looks like:

T0:23:respawn:/sbin/getty -L ttyO0 115200 vt102

Not meant to berate anyone, but just like me sometimes I forget the newer images run Jessie, which default to using systemd as the systems init daemon. Anyway, with systemd there is no /etc/inittab, and serial or other things that were norally handled by inittab are instead written as startup services  suppose . . .

So for those of you who run the latest testing image . . . there is not inittab  unfortunately.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ec8a1cf9-2aa6-dc48-1915-7566ac46306e%40steinkuehler.net.

For more options, visit https://groups.google.com/d/optout.

[WZ9V]

Feel free to update the wiki article. I wrote it originally but I switched my OctoPrint server to the RPi eventually because it's more common. I moved my BBB back to more experimentation.

[Jacob Fish]

On Saturday, July 9, 2016 at 12:29:07 PM UTC-4, WZ9V wrote:

Feel free to update the wiki article. I wrote it originally but I switched my OctoPrint server to the RPi eventually because it's more common.  I moved my BBB back to more experimentation.

Yeah, a RPi does seem a little easier and common to work with. Once all the kinks are worked out with the steps, I will see what I can do to update the wiki. 

On Friday, July 8, 2016 at 12:09:49 PM UTC-4, Charles Steinkuehler wrote:

AFAIK, there's only one serial console, and that's on the serial debug 
port (the 6-pin header).  You should be free to use any of the UARTs 
connected to P8/P9 pins, but you'll probably need to enable them first 
via a device tree overlay.

So I just did a quick test by connecting a RPi to the BBB UART1 (P9_24 = TX and P9_26 = RX) after enabling the UART and confirming its available via:

<code>

root@beaglebone:/dev# ls -l ttyO*

lrwxrwxrwx 1 root root 5 Jul  8 01:09 ttyO0 -> ttyS0

lrwxrwxrwx 1 root root 5 Jul  8 01:09 ttyO1 -> ttyS1

<\code>

I logged into the RPi and started a minicom session with a 115200 and 9600 baud just to see if I can grab any response from the port. I believe you are correct that a console is not tied with UART1 since I'm not receiving anything of interest (no login prompt or even garbage). To farther verify this, I was able to make a console connection from BBB UART1 to RPi. There was no odd ball junk popping out like it would if using UART0 while tied to the console.

On a side note, why is there a ttyS* tied with the ttyO*? I'd always assumed that those where devices indicating that there is a shell console tied with the UART port. After this quick test, it would seem like this is incorrect to assume. I was able to use either ttyO1 or ttyS1 to communicate from BBB to RPi without any issues. Why is this there?

[Charles Steinkuehler]

On 7/10/2016 11:36 AM, Jacob Fish wrote:
> On a side note, why is there a ttyS* tied with the ttyO*? I'd always assumed
> that those where devices indicating that there is a shell console tied with the
> UART port. After this quick test, it would seem like this is incorrect to
> assume. I was able to use either ttyO1 or ttyS1 to communicate from BBB to RPi
> without any issues. Why is this there?

ttyS* basically means "serial port", not "serial console". You won't
get a console unless you run getty (see the commented examples in
/etc/inittab for ttyS0 and ttyS1).

IIRC, the earlier BBB kernels used /dev/ttyO* port naming
(particularly prior to the TI Omap serial port driver being integrated
with the kernel serial driver). I believe the symlinks are a
convenience to keep older code/documentation working. Note the 3.x
series kernels have this somewhat confused with port names and
numbering changing between various kernel versions as the drivers were
being updated, but I believe the 4.x kernels should all use standard
/dev/ttyS* naming with consistent port numbering.

--
Charles Steinkuehler
cha...@steinkuehler.net