USB is not that slow. With a FTDI chip for USB 2.0 you can reach up to 480MBits/s.  POE would is something most people do not have at home. Most routers/switches do not have POE capability. Only the more expensive ones have it. But I guess you will make it in such a way that it will be possible to power it with a dc adapter as well. The problem Neal encountered has not been solved as far as I know. I think he got stumped and gave up. I cannot blame him, I would be very frustrated as well. He spend a lot of time on it. He encountered too many tcp resends. We were sampling at 504201 Hz and sending blocks of 1024 samples. Unfortunatly the dspic could barely keep up the data rate. We reached about the maximum SPI rate of 15MHz (tcp has a lot of overhead). When one DMA block was filled with samples the other was send to the PC. But sending through the w5500 is a blocking operation. And if there are one or more resends the sending takes longer. Too long actually. Sending could not keep up the the sampling and glitches occured. Sometimes the dsPic or w5500 stalled completely. Neal got tcp resends very often even with only his pc, analyser and a switch as a separate network. He also tried other pc's and network equipment, with the same result. I was not able to reproduce that problem though. It all worked fine here. But if one of us has trouble then chances are that someone else can will have the same problems. The solution should work for everyone. We also tried UDP, but that did not work out as well. We also cannot affort to loose any data or receive it in the wrong order. So we had to stick with tcp. I think using USB will not have this problem because there is less change of congestion. Its just the analyser and the pc. The current application is written in C# (.NET framework) because that's wat I use as a professional software developer every day. I never used QT, but it looks great. It would be great if the client application would be able to run on other devices like tablets as well. I think QT is free to use when used with a certain open source license model. I like the idea of the brushless motors. I use them with my drones (8 motors, 1m diameter) and model helicopters (1.2m rotor diameter). There is an article about using dc motors with a closed loop pid controller for use in a 3D printer in the last two issues of Circuit cellar. I also have retraction problems like you have. I do not think you can solve that easily. The problem is that retracting the fillament does not create a vaccuum inside the nozzle. Air can get inside easily. So it does not suck the filament back into the nozzle as you would expect. Retracting only reduces the oozing because there is less pressure of the fillament. Therefore there is no use in having more than 2 - 4mm retraction. Don't you have problem with printing layers too fast on top of each other? I never print faster than 60mm/s because if a layer is printed on top of one which has not been able to cool down yet it will become a mess. Even with a fan. I like to see your printer in action. Do you maybe have a movie you can show?

I have not found the article published in English, but you can find BOB-SCAP in german here: https://www.elektormagazine.de/magazine/elektor-201507/27880, and in Dutch there: https://www.elektormagazine.nl/magazine/elektor-201603/28865. Good reading.

Breed, I was thinking of increasing the network speed to increase throughput.  I would never go to USB.  To slow and forces you to be attached to a noisy PC.  I would go wireless before USB.  I wanted to support POE so it is completely remote but powerful.  I would like to understand the reason behind the problem with the network.  Did you hear back from Neal yet? What do you think about QT instead of C++?  Universal platform will get more attention. 3D printer:  Delta.  Getting Carthesian to move that fast would be a serious unsuccessful project I suspect.  I am targetiing 400mm/s print speed!  200 is common.  Travel speed is up about 500-600mm/sec. DC Servos not steppers.  Lot of new motor controllers coming out now.  Use BLDC motors, they rock and are quiet. Changing the filament injection obviously has been a big design challenge.  Increased the area where the filament gets melted and increased heat (40Watt heater).  Changed the extruder to be able to push that much filament.  Have not tried Nylon yet at speed which may be impossible to run that fast.  The retract still needs tuning.  When you have that much melted filament sitting there it tends to come out the tip no matter what the retract is set to.

Rich, I do not think this is the end of the project. I just didn't want to spend months on this project. And I was hoping that more people might be wanting to help coding. That's why I've put the code on github. I think your ARM based project will be an interesting project. I hope you will post it on this web site. If there is one one thing I would change it would be swapping the network connection with a high speed usb connection. We were actually making a high speed continuous mode and implementing SDR. But Neal had a lot of trouble getting the data from the analyser to his pc because of his network at home. That's when this project stalled. By the way. I'm also busy with my 3D printers, both delta and carthesian types. That hobby consumes a lot of time as well. I guess that the 400mm/s you mentioned is travel speed, not actual printing speed? I think building 500mm printer is quite challenging if you want 0.1mm accuracy on all axes. Also very interesting stuff...., but another topic.

Please note that Microchip is phasing out the PIC16F628 and recommends the 628A for new developments. This means that we can't use the oscillator circuit with only a resistor connected to RA7, for the 628A an RC-combination is required. But why do you want to tune the oscillator frequency to match with the UART's baudrate? In my experience the PIC's internal oscillator is accurate enough for stable serial communication. Regards, Luc