Olliver

If i remember correctly, the not-breaking of the filament was not the biggest problem, even though I think the sensor was before the feederwheel. Iow, the material would remain infront of the sensor, the wheel would grind the material and that would be that. However, since it was not a 'filament is there/not there' sensor, but an actual rotation sensor, we could in fact detect this. E.g. the wheel is moving/not moving and thus the filament is either stuck our out. Either case, a problem As Sander said, the sensor was a magnetic rotation sensor, and we had a wheel with a magnet on it that was being turned by the filament. If I am not mistaken, it was an Allegro A1332 part that we used. The false errors mostly came from the material not properly moving the wheel due to various reasons.

While this post is probably antient by now, just to let this lingering questing not go unanswered: apt-get update stores files in both /var/lib/apt and /var/cache/apt. Removing both these directories solves the disk full issue with regards to files generated from apt. rm -r /var/lib/apt /var/cache/apt Having said that, there are two methods to get apt working. One is to use tmpfs (we did this in the latest firmwares, but there's problems and risks there, such as running out of memory) mkdir -p /var/lib/apt /var/cache/apt mount -t tmpfs /var/lib/apt mount -t tmpfs /var/cache/apt That said, what I (used to) do a lot, is mount /dev/mmcblk0p3 /home/ultimaker/tmp mkdir -p /home/ultimaker/tmp/apt_cache mkdir -p /home/ultimaker/tmp/apt_lib ln -s /home/ultimaker/tmp/apt_cache /var/cache/apt ln -s /home/ultimaker/tmp/apt_lib /var/lib/apt after that, after each reboot you still need to mount mmclk0p3, but you have plenty of space to do apt-get update

Even the kernel is on github: https://github.com/Ultimaker/linux/tree/opinicus_v4.2.0-rc7 with our config here: https://github.com/Ultimaker/linux/blob/archive/opinicus_v4.2.0-rc7_v2/arch/arm/configs/opinicus_defconfig It includes our patches (which where in WIP state at the time, they are on their way to upstream for ages) Our bootloader is also available in case you are wondering https://github.com/Ultimaker/u-boot/tree/archive/sunxi-ultimaker Afaik we are in full compliance with the GPL to these bits of code.

Because it's cheap? The machine is already expensive enough as far as i can see. There is nothing wrong per se with UVC, but this is indeed a pretty rubbish camera. Yes it is a cheap camera, but that was the whole point, we wanted to just monitor prints, not add to the price for a super high-end camera. That said, the camera defaults to 800x600 on purpose. It is 'good enough' for streaming purposes and is easy to work with, low bandwith etc. One use-case was to monitor a print remotly, via a mobile phone (or even a mobile connection). You don't want to do 1280x1024 there. Having said that, the camera is actually 1600x1200. We had choosen 800x600 as a default resolution exactly because it is a quarter resolution, and the controller chip on the camera can do some tricks to give you a little bit higher image quality while still giving the maximum field of view. Feel free to change the camera to a higher resolution, edit the file ' mjpg-streamer\@.service' on the printer and change the -r parameter from SVGA to whatever resolution the camera supports; e.g. resolutions[] = { { "QQVGA", 160, 120 }, { "QCIF", 176, 144 }, { "CGA", 320, 200 }, { "QVGA", 320, 240 }, { "CIF", 352, 288 }, { "VGA", 640, 480 }, { "SVGA", 800, 600 }, { "XGA", 1024, 768 }, { "HD", 1280, 720 }, { "SXGA", 1280, 1024 }, { "UXGA", 1600, 1200 }, { "FHD", 1920, 1280 },}; So for example: ExecStart=/usr/bin/mjpg-streamer -i "input_uvc.so -r SXGA -d /dev/video%i" -o "output_http.so -p 808%i" Note that using 1600x1200 will drop your framerate to 5fps, as the controller is underpowered to offer mjpg streaming at that resolution, and the USB bandwith is to low for a higher framerate. As to the UVC comment, UVC stands for Universal Video Class, e.g. a standard protocol to connect (web)camera's via USB. Most camera's (even the high-end ones) tend to speak UVC. Because when we started (+- 3 years ago) Alpine wasn't really a thing yet. Switching distros is dangerous & expensive. Not only that, it really makes little sense to use Alpine when you have a heavy python stack on top. Our debian is not that bloated, it is all the package dependencies we have that require a lot of space. Also, we had 4gb storage at the start of development, a pretty beefy linux system. Why not use a distro that's slim, yet featureful. Granted, Alpine is pretty sweet, but as nallath mentions, not a thing back then. But we did concider similar things, such as buildroot/openembedded to build our own minimal basis. But why? We are not making a device with only a few megs of storage. We have plenty and our software requirements requires so much more, it does not matter. As to mtd, we do not use mtd :)we use f2fs (Flash Friendly file system) ontop of an eMMC chip. The only thing I want to see improved, is the seperation (read only overlay) for the OS with a RW overlay for user generated data (config files etc). SystemD does perfectly what we need it to do. Especially if we ever want to open up the platform. Not only that, systemd is pretty much very awesome. Note, I say this as someone who ran gentoo with -systemd on several systems! But I took the plunge when switching to debian (from ubuntu) on my dev machine to have an environment very closing the printers, and learned to appreciate it. Systemd (even journald) is very very cool. And no, it is not that bloated! Also, you know whats really cool? we can do systemd-nspawn on our rootfs and run printers that are not real! It's not out yet. Most of the code is in python anyway and easy to view on the machine. Almost all of _our_ code is python. The other code that we modified is open source so released. The only thing missing is the display code, and I hope it that and our other repository to be opened up after the 6 month deadline.

Hello mqdusi, I see you are trying to connect via wifi. Can you check if this also happens on the LAN connection? Additionally, what DHCP server are you using and would it be possible to post your dhcp config? The forum will likley refuse it, but you could use paste.debian.net maybe? If I understand correctly, you first had configuration A on your network (either pool A range of IP address or a dynamic pool); then modified your DHCP server config to force this mac address into a different pool (which results in sending out a NACK on the old request and sends out an OFFER on the new pool), right?

lol; I bet even phpbb3 would b better.

_do_make.bat however is very platform specific and requires patching when changing arduino versions etc. Also, _do_make.bat is basically patching the Makefile 'on the fly'. Since we're talking about UM's specifically here it's not unthinkable that RepRap based firmware won't build 'out of the box'

Not entirely true, You get this issue also with 1.0.5 when using a wrong motherboard. The default right now is '11' in the Makefile. A patch I have in my local git repository looks like the following (tested on *ubuntu) for an UM2 which is motherboard version 72. Arduino is installed via apt-get and i think it now has a dependancy on the normal avrdude (avrdude.conf is a symlink to /etc/avrdude...) diff --git a/Marlin/Makefile b/Marlin/Makefile index d8c7d0a..481c454 100644 --- a/Marlin/Makefile +++ b/Marlin/Makefile @@ -37,19 +37,19 @@ # from the commandline with "make HARDWARE_MOTHERBOARD=71" for example # This defined the board you are compiling for (see Configuration.h for the options) -HARDWARE_MOTHERBOARD ?= 11 +HARDWARE_MOTHERBOARD ?= 72 # Arduino source install directory, and version number -ARDUINO_INSTALL_DIR ?= ../../arduino-0022 -ARDUINO_VERSION ?= 22 +ARDUINO_INSTALL_DIR ?= /usr/share/arduino +ARDUINO_VERSION ?= 105 # You can optionally set a path to the avr-gcc tools. Requires a trailing slash. (ex: /usr/local/avr-gcc/bin) AVR_TOOLS_PATH ?= #Programmer configuration UPLOAD_RATE ?= 115200 -AVRDUDE_PROGRAMMER ?= arduino -UPLOAD_PORT ?= /dev/arduino +AVRDUDE_PROGRAMMER ?= wiring +UPLOAD_PORT ?= /dev/ultimaker2 #Directory used to build files in, contains all the build files, from object files to the final hex file. BUILD_DIR ?= applet @@ -293,7 +293,7 @@ LDFLAGS = -lm # Programming support using avrdude. Settings and variables. AVRDUDE_PORT = $(UPLOAD_PORT) AVRDUDE_WRITE_FLASH = -U flash:w:$(BUILD_DIR)/$(TARGET).hex:i -AVRDUDE_FLAGS = -D -C $(ARDUINO_INSTALL_DIR)/hardware/tools/avr/etc/avrdude.conf \ +AVRDUDE_FLAGS = -D -C $(ARDUINO_INSTALL_DIR)/hardware/tools/avrdude.conf \ -p $(MCU) -P $(AVRDUDE_PORT) -c $(AVRDUDE_PROGRAMMER) \ -b $(UPLOAD_RATE)