The UM3 does reduce this problem by offloading many tasks to the Olimex board, for example all the handling of menus, updating the display etc are handled there instead of in the atmega, so that one can use all of its power to do the actual motion control.
1
I think the most realistic path at this point would be OctoPrint on a raspberry pi, an olimex board, or any other small board computer. I have not had SD card corruption with the newer models (ie: since the B+). I'm even running a UM2 and a UMO from a single raspberry pi model 3 (which is not officially supported, but that's another thing).
Just ignore the functionality to store gcode on the SD card of the UM, because that is excruciatingly slow (almost takes as long a the print).
OctoPrint over USB is known to work, emulating an SD card is going to be a LOT of work and will risk your electronics.
1
Yes. A small external device, like octopi, is certainly the best backup plan, as has already been noted.
Albeit with quite a few drawbacks.
I was hoping on a bit of discussion on this specific idea though rather than suggestions for alternate solutions.
Not that I don't appreciate the feedback, it's just that all those other ideas have been covered pretty well elsewhere.
Albeit with quite a few drawbacks.
With the risk of starting a different discussion than the one you wanted, could you list some of these drawbacks?
Back to your suggestion: I don't think emulating an SD-card (if that is what you want to do) is feasible. Not only would you need to get the electronics and timings right, you would need software that emulates the filesystem. And the Ultimaker expects files on the SD-card, not live streaming data. The reason SD-cards are fairly cheap is that many of them are made, not that they were necessarily are simple to engineer.
With the risk of starting a different discussion than the one you wanted, could you list some of these drawbacks?
For starters there you loose the ability to use the excellent builtin menu system to adjust settings on the fly, right? The performance issues already listed may or may not be a problem in real life. Some have suggested it is but others, like you, seem to be running octopi without complaint.
I think I could live with the potential shortcomings of such a method if there are no technical limitations. I am still on board for giving it a go again. I installed an octopi the other week but I have not gotten round to trying it out yet.
I don't think emulating an SD-card (if that is what you want to do)
It is not. I thought I was pretty specific when I said to use an array of SSRs to switch the electrical connections.
To clarify. I am suggesting it might be possible to trick the Ultiboard into thinking that the sd card has been unplugged while at the same time making it available for writing by another device and then "plug" it back again.
SD cards are after all a pretty simple electrical connection, you can solder pins to one and connect it straight to an arduino (though with 3.3v) if you wanted. Since sd cards are prone to oxidation or other glitchy behavior, especially at the moment of inserting and removing them, it would assume that the software is built to make some allowance for that sort of thing which would help in this scenario.
So if we can avoid getting interference at the moment of switching the sd card and get the logic level correct it should be possible. Given that the pinout of the front board is obliging (I haven't checked yet).
I am going to have a look at this asap and see if I can work out any major issues that will blow the plan up. Otherwise I am tempted to give it a try.
Cheers
I see. I did not know what you meant with SSRs, now I assume solid state relay.
I see. I did not know what you meant with SSRs, now I assume solid state relay.
Yes. Mechanical relays would probably work just fine as well. Don't think we need the speed and the number of switches over the lifetime would not exceed even a very cheap relay.
Transistor based logic gate arrays would probably work too. But let's keep it simple and stick to a couple of basic solid state relays.
Actually now that I think about it SSRs probably won't work. We need it to switch between two poles with a common output. SSRs don't usually, if ever, do that. I will probably have to stick with mechanical relays if I want to keep it simple.
I am actually making a prototype based on an ESP8266 right now. We shall see how well it works out.
Edited by GuestThe simplest solution is Octoprint on, well, just about any linux board. A cheap OrangePI can do this job.
You could also setup an ESP to stream the data towards the printer. The UM2 has an extra serial port, all the way on the other side of the board compared to the USB plug. It's on a 4 pin connector. This connector has 5V, GND, TX, RX. These are all 5V, so you need to level shift them to 3.3V for the ESP. And you would also need to change the firmware in the UM2 to use this port for communication (#define SERIAL_PORT 2 instead of 0)
The hard part would be the firmware for the ESP, it needs to stream the data to Marlin, and receive data trough wifi, it does not have the memory to store the whole GCode file, but it has more then enough memory to buffer the gcode. And WiFi is more then fast enough to get the data there.
But, I'm currently going for the different route, adding a Linux board to my UMO and running the Ultimaker 3 software stack on that.
1
You could also setup an ESP to stream the data towards the printer. The UM2 has an extra serial port, all the way on the other side of the board compared to the USB plug. It's on a 4 pin connector. This connector has 5V, GND, TX, RX. These are all 5V, so you need to level shift them to 3.3V for the ESP. And you would also need to change the firmware in the UM2 to use this port for communication (#define SERIAL_PORT 2 instead of 0)
Yes, that is the more hardcore version of the octopi. Although the ESP8266 can handle 5v on signal pins according to espressif so a level shift wouldn't be entirely necessary. But since they cost like $2 you might as well be on the safe side.
The hard part would be the firmware for the ESP, it needs to stream the data to Marlin, and receive data trough wifi, it does not have the memory to store the whole GCode file, but it has more then enough memory to buffer the gcode. And WiFi is more then fast enough to get the data there.
There is a firmware already, but I haven't tried it.
https://github.com/luc-github/ESP3D
I'm still running my UM2 from SD but I have an octopi ready to go. Just need to get half an our to set it up and try it out. Like I said previously, I could live with some of the drawbacks of that solution if this theoretical speed problem is in fact not that major.
But, I'm currently going for the different route, adding a Linux board to my UMO and running the Ultimaker 3 software stack on that.
That's a pretty hardcore solution.
I did set up a small test yesterday to try out and ESP switching the SD card. Didn't do any switching, I concentrated on uploading files to SD. Did work but the performance wasn't that much better to be honest.
On closer inspection it seems like the SD libraries for arduino in general aren't all that fast, at least at writing.
I did find one thread where a 4mb/s write speed was claimed for a Due. Since that runs a 32bit ARM processor it should have no problem with handling a proper input method I suppose.
But don't have one to try it. Will see if I can order one and give it a go.
Cheers
ArunC posted a topic in UltiMaker Cura,
.thumb.jpeg.0b7a05eafc09add17b8338efde5852e9.jpeg)
Dustin posted a topic in Firmware,
Recommended Posts
ultiarjan 1,223
you may also want to have a look at the Ultimaker3 solution, basically all comunications done by the "Olimex20" board, and the printer hardware still connected by a UM2 like board.
https://ultimaker.com/en/community/23282-questions-about-ultimaker-3?page=2
I guess more details will become available soon, as Ultimaker promised in the "we filed a first patent" communication,they will still publish machine drawings on github as usual, I assume this includes electronics... should be in 6 months after first shipping the printer, so that's in about 2 months I think.
Link to post
Share on other sites
jonatanrullman 17
Thanks.
I had assumed that the UM3 used a newer board with better transfer rates. As I have understood it the ultimaker can run faster than the transfer rates can keep up with resulting in stalling. I have had this problem with my old printer, although I can't say for certain that it was due to bandwidth, cache or some other bug. I am leaning towards the latter two.
If the UM3 uses basically the same board as the UM2 it seems like it would run into the same problem no matter what board it uses for the WIFI functionality. Perhaps this is just a theoretical problem.
There are of course a few interesting methods for printing without the SD but with wifi. Octopi on a RPI and there is a firmware for the ESP8266 as well. I have used octopi previously (like two years ago) and it worked well until the operating system crashed due to power loss.
While I am working on this idea (if I ever get beyond a planning stage that is) I will certainly try that once again and see if the theoretical bandwidth limit is a problem in the real world as well.
I am not sure exactly how fast you would need to run the printer to run out of bandwidth (would depend on geometry of course) but seeing as this printer can comfortable and out of the box do almost twice the speed my old printer could after years of tuning I think it possible that I may encounter it at some point.
Cheers
Link to post
Share on other sites