You are not logged in.
Pages: 1
The display definitely reinitialized when the device node was set to /dev/i2c-0 . Unless I'm supposed to see some sort of message at idle, I think it's good. Thanks!
The beta upgrade appears to be a Broadcom build, not an ARM-generic build.
Sure it is possible, but we will have yet another field on the setup page.
Would it be better to just try them all in turn, and stick with the first one where a device responds to the address given?
Have you tried set i2c address 39
Yes, that's the default. I've also tried address 38 (0x26), but no change. nanoDLP is using the wrong bus, apparently skipping i2c0 entirely:
crw-rw---- 1 root i2c 89, 0 Sep 13 12:55 /dev/i2c-0 # the bus where the PCF8574 LCD is, works via i2cset
crw-rw---- 1 root i2c 89, 1 Sep 13 12:55 /dev/i2c-1 # a phantom bus, not pinned out on this board, doesn't respond
{"Layer":"0","module":"Gcode","level":"Error","msg":"Could not access LCD write /dev/i2c-1: no such device or address"}Can the I2C bus be made a configuration option? Build 1609.
More info:
With i2c0 enabled in the boot config, my I2C LCD board shows up:
root@print0r:/# i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- 27 -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@print0r:/# i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- UU -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- Without i2c0 enabled in the boot config, no LCD:
root@print0r:/# i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- UU -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@print0r:/# i2cdetect -y 1
Error: Could not open file `/dev/i2c-1' or `/dev/i2c/1': No such file or directorySorry to be unclear. The Orange Pi PC under Armbian has /dev/i2c-0 enabled, which goes to some unidentified device with address 0x65. When I enable the overlay for i2c0, the I2C bus on physical pins 5 and 7 shows up as /dev/i2c-0 and the strange bus becomes /dev/i2c-1. This strange bus shows up as highest bus used + 1 rather than its actual hardware unit number. So the algorithm of just using the highest bus number doesn't work for this machine.
Is there a way to specify which I2C bus number is used? In Armbian, on the Orange Pi PC, I2C bus numbers appear to be packed, and the highest numbered I2C bus seems to be unavailable. I've tested that my 16x2 LCD works fine on /dev/i2c-0 using i2cset.
Reporting initial success with an Orange Pi PC, Armbian 5.31, Wanhao D7, /dev/fb0. The key seems to be to switch to the nightly kernel (I used 4.11.5-sun8i) using the armbian-config utility.
Video is correct. Projector and Z-axis control work fine. It's not a very fast machine with such demands being made on RAM bandwidth, but it's smaller and cooler than the PC I was using to drive it before. Thanks again, Shahin!
@ender67, your virtual fb Y size is twice the physical size. I had the same problem and also the error: slice bounds out of range, until switching to the nightly kernel with armbian-config.
New version is available on download page for ARM. Please, try and let me know if it fixes the issues.
On my Banana Pi board, it starts up, and it slices, and machine control over serial works fine. Video works too on my 1080p desktop monitor, had to disable the text cursor manually (vt.global_cursor_default=0 kernel parameter). Also the program crashes when trying to display the static full HD calibration image:
panic: interface conversion: image.Image is *image.Gray, not *image.RGBA
goroutine 806 [running]:
projects/printer/app/renderer/img.LoadPix(0x119987b0, 0x28, 0x0, 0x0, 0x0)
/home/shahin/go/src/projects/printer/app/renderer/img/loader.go:39 +0xec
projects/printer/app/viewer/fb.(*RGBA).Display(0x109553e0, 0x119987b0, 0x28, 0x2, 0x2)
/home/shahin/go/src/projects/printer/app/viewer/fb/fb_linux.go:102 +0x24
projects/printer/app/viewer/fb.DisplayImage(0x119987b0, 0x28, 0x426fff)
/home/shahin/go/src/projects/printer/app/viewer/fb/fb_linux.go:70 +0x30
main.showFrame(0x119987b0, 0x28, 0x21)
/home/shahin/go/src/projects/printer/app/hardware.go:107 +0x13c
created by main.projectorDisplay
/home/shahin/go/src/projects/printer/app/web.go:197 +0xe4No big deal, the dynamic calibration plates work fine. The oddly dimensioned LCD in the D7 doesn't appear to be recognized by this old A20 board, so I'll wait for my H3 boards to arrive to test on the printer some more.
Cheers!
Currently we use golang flags for arch and os to differentiate versions. (it works very elegantly) Now all of these boards are linux and arm so I need to find better way to handle this scenario.
Possibly silly suggestion: You might abuse the GOARM environment variable to distinguish build types. You could include Broadcom/Raspbian facilities for $GOARM==6 (default) for Raspberry Pi builds, providing rasPi 2/3 compatibility at the cost of slightly slower floating point, and exclude Broadcom/Raspbian facilities for $GOARM==7, providing basically the PC build with X and framebuffer support, maybe also I2C displays, at the cost of requiring an external controller.
Anyway, my boards won't be here for a few weeks so I'll wait patiently.
libGLESv2 and libEGL for armhf don't link with nanoDLP armel.
$ ldd printer
...
libGLESv2.so => not found
libEGL.so => not found
...
$ find /usr -name libGLES\*
/usr/lib/arm-linux-gnueabihf/mesa-egl/libGLESv2.so.2
/usr/lib/arm-linux-gnueabihf/mesa-egl/libGLESv2.so.2.0.0
$ LD_LIBRARY_PATH=/usr/lib/arm-linux-gnueabihf/mesa-egl:$LD_LIBRARY_PATH ./printer
./printer: error while loading shared libraries: libGLESv2.so: cannot open shared object file: No such file or directoryCan you please do an arm-linux-gnueabihf build for Debian Jessie without linking to libbcm_host or including GPIO support? It should then "just work" with any later Debian or Ubuntu build. That would be all I need to get my Duplicator 7 running without a PC attached.
Many thanks. I will report back.
Pages: 1