RPI3 on EINSY accessory port?  

Re: RPI3 on EINSY accessory port?

There are several issues here.

First, don't assume that the Octoprint issues are USB related. I believe they are issues with the overloaded Atmel processor reading the serial buffer. The USB->Serial connection is (I believe) handled in hardware and not part of the problem. It's keeping up with the serial buffer. The RPi3 through accessory port could have exactly the same issue, no idea.

Second: I'm currently having no issues with USB print. The latest firmware turned off Linear Advance (whether you are using USB or not), and USB/Octopi from a RPi3 seems to work fine.

Power: I wouldn't use the internal power for the RPI3. Just leave that pin disconnected, only use the communication wires and the ground. I suspect the RPI3 would run just fine with the power from the Einsy under normal conditions, but I'd had to have the RPI3 kick into gear for while generating a time-lapse video and reboot the Einsy, the Pi, or both.

Re: RPI3 on EINSY accessory port?

Second: I'm currently having no issues with USB print. The latest firmware turned off Linear Advance (whether you are using USB or not), and USB/Octopi from a RPi3 seems to work fine.

Ah interesting. I was under the impression that USB connectivity to the EINSY was still unreliable (whether via OctoPi-to-USB or PC-to-USB). If an RPI3 on USB is now reliable, that would clearly be the easier/safer way to proceed with Pi3...just wasn't aware that was the case yet.

Re: RPI3 on EINSY accessory port?

Second: I'm currently having no issues with USB print. The latest firmware turned off Linear Advance (whether you are using USB or not), and USB/Octopi from a RPi3 seems to work fine.

Ah interesting. I was under the impression that USB connectivity to the EINSY was still unreliable (whether via OctoPi-to-USB or PC-to-USB). If an RPI3 on USB is now reliable, that would clearly be the easier/safer way to proceed with Pi3...just wasn't aware that was the case yet.

There are two points:
1) RPi3 on USB is working for me now, YMMV.
2) I'm not clear that the same issues don't affect the accessory port. That is still a serial connection should have the same issues if the serial buffer is the issue as Josef indicated.

Re: RPI3 on EINSY accessory port?

They probably just need to dump the language files and have you upload the firmware in your language. Perhaps they will need to have a choice of build or simply use English (not being am imperialist, just pointing out that English is spoken most everywhere. At least enough to get a firmware download performed with perhaps a readme in several languages. That might free up some buffer space and clear the log jam, or at least prevent it from crashing.

Re: RPI3 on EINSY accessory port?

They probably just need to dump the language files and have you upload the firmware in your language. Perhaps they will need to have a choice of build or simply use English (not being am imperialist, just pointing out that English is spoken most everywhere. At least enough to get a firmware download performed with perhaps a readme in several languages. That might free up some buffer space and clear the log jam, or at least prevent it from crashing.

Wrong issue. The firmware is stored in ROM (flash) on chip. There is no shortage of space there (I believed they bumped up the space on the Einsy board). Plenty of room for language packs and all the features.

The issue is with the processing power of the actual CPU. When you are streaming information from Octopi or a computer to the Einsy, it is going through a serial port, a very simple set of wires that send characters one at a time from computer to Einsy and Einsy to computer. (The serial port on the Einsy is actually being transported over USB wires, or over the bare wires to the accessory port, but I don't think that matters).

The issue is that at 115Kbps, a new character is sent from the Pi to the computer about once every 80 microseconds. The processor can't stop to process these that quickly, so there is hardware (a serial port buffer) that holds some number of characters and eventually the processor comes to grab a number of characters at once. The buffer may interrupt the processor as it gets close to full (!come empty me!), or a loop in the code may have to make sure to check the buffer regularly.

I believe the issue is that with all the new features (linear advance, crash detection, filament detection, measuring the current to all the stepper motors, whatever) the processor gets too busy at times. It gets distracted and doesn't check the serial buffer soon enough. By the time it checks, the buffer has actually overflowed, and either the oldest characters were overwritten or there was no room for the latest characters and they were dropped.

The Einsy may recognize that it missed some data and be able to request it to be resent, but that doesn't always work. If it doesn't, a command can be missed or corrupted (shift left by 2mm instead of shift left by 200mm, whatever). When that happens, the print will likely hang or be corrupted.

Re: RPI3 on EINSY accessory port?

That sounds about right. What I was hoping is that the buffer could be extended either in ram or otherwise in flash, but that may drastically reduce the lifespan of the chip. Hmmm. Perhaps some code on the octoprint side. I'm not quite sure why the SD works and does not run into the same type of issue with exception to its persistence, but I am hopeful that someone will come up with a creative solution, or free up some cyles on the Atmega. Perhaps the SD IO could be hijacked for the RPi.

Re: RPI3 on EINSY accessory port?

Digging into the Atmega2560 and the Marlin firmware, there are few different buffers here.

Both the accessory port (for pi0) and the USB serial port (for external USB Pi) share the same pair of pins: PD2/PD3 (RXD1/TXD1), which is why you must disable one to use the other. These pins connect to USART1, the "serial port".

USART1 detects bits one at a time off of the RX pin and assembles them into a byte. When it has a complete byte, it shoves it into a 2 entry 'buffer', a fifo. This is fixed in size in hardware. It also triggers an interrupt, saying "RX byte available".

The Marlin firmware installs an interrupt handler for that RX interrupt (M_USARTx_RX_vect). Whenever a byte is available, the processor will interrupt the current execution (wherever it is in the execution loop), save the current context (registers and such) and run the interrupt handler. The interrupt handler copies that byte to RAM (if it can) and then returns to the previous program.

The place it copies it to in RAM is a circular buffer of size RX_BUFFER_SIZE (which is currently set at 128 bytes in the version I'm reading), with head and tail pointers. If the buffer isn't full (checked by comparing head/tail pointers), the interrupt copies a byte to the head pointer and increments the head pointer (wrapping around to the beginning if it has hit the end of the allocated storage). This copy implicitly deletes the character from the 2 entry USART1 fifo, making room for another character to come in.

If the receive buffer is full, the interrupt does nothing. It leaves the data in the USART1 fifo. If the buffer stays full for 80 us, another character will have time to come in and be added to the fifo, no problem. Another 80 us and a third character might come in. This can't transfer to the Fifo (it's full), but might be able to hang out in the receive logic. Definitely if a fourth character starts to come in, somethings going to get dropped.

The contents of that circular buffer are drained once each time the get_command() function. Everything is drained, processed a bit, and added to the command buffer.

Bottom line: the main loop of the Marlin code can't ever take longer than ~11ms. If there is ever >11ms between calls to get_command(), there will be time for 128 characters to arrive (at 115kbps, assuming 10 bits per char with stop, etc.), the buffer will fill up, and communication will hiccup.

My guess is the addition of some of that complex math in the linear advance code pushed them over that 11ms (not all the time, but every now and then).

Re: RPI3 on EINSY accessory port?

Great explanation, thanks for writing that up. So on that end of things, it sounds like moving from accessory port to USB (or vice versa) won't make any difference. Same serial interface, same buffers. The ailments there will only get better with firmware improvements.

The other piece of the equation (RPi0w vs RPi3), seems to be up for debate. I've seen plenty of posts from people who apparently have no issues printing from an RPi0 (even when using webcam and WiFi), but I saw a post today that showed photo evidence of a user's Pi0 putting zits on a print that looked zit-free when printed using his RPi3. I'm sure there could be other variables at work there, but the RPi0 definitely seems to be in the YMMV category.

Given all of that...for my own purposes, even if the Pi0 is only occasionally overwhelmed to the point of causing print artifacts, I'd rather spend the extra $20 and use a Pi3 and eliminate that potential issue altogether. And if the accessory port offers no advantage over the USB port (other than on-board power, which may not be wise to use for the Pi3 anyway), then I'm inclined to only use USB going forward so I don't have to fiddle with headers or header extension wires any more. RPi3 via USB certainly isn't as tidy as an on-board RPi0, but I'd rather have a couple more cables behind my desk and minimize the potential of print issues.

Re: RPI3 on EINSY accessory port?

I went the same way: external RPi3. The disadvantages of the rpi0, as well as the extra risk, seem to outweigh the advantages of having it internal. If you can live with the RPi3 cost ($35) and the extra power supply, mount a RPi3 on the frame under the Einsy and you are good to go.

Re: RPI3 on EINSY accessory port?

Hey I thought I'd chime in. I'm planning on using an old Rpi2 to do this too, via usb. I'm waiting on a 12-24V buck converter so I can power the RPI off the 24V Prusa power. I'll make a little case for the buck converter, pi, etc. to be mounted somewhere sensibly. I've put octoprint on the pi2 already, and it works fine live streaming video via ethernet BUT i can't test serial communications, etc. until my I3 Mk3 kit arrives -- so I don't know how it will go in practice.