ADC and printing issues on the Beaglebone CRAMPS

[Jonathan Cohen]

I took my printer down since the hot end was locking up during a long print.  I have posted about this over the past year.  I recently purchased a new microsd card, put on a new image of Jessie 8.6.  I also replaced the hotend thermistor, redid all of the wiring to decrease the effect of EMI near the cartridge heater leads.  I got off one reasonable 4hr test print.  However, on an overnight, the ADC locked up at maybe the 5 hr mark on a 6.5 hr print (not heating).  So,  I recall Charles writing about the ADC driver being a bit temperamental, sensitive to over-voltage and such.  I am powering the beaglebone through the AUX in on the CRAMPS board through a 5V LM2596 buck regulator (https://www.amazon.com/gp/product/B00WEBJRE8/ref=oh_aui_search_detailpage?ie=UTF8&psc=1).  I recently went a made sure that it was set to 5V to be sure.  Prior to that I was using a 5V DC adapter where I still had this issue. My cable management is reasonable so I do not think wires are moving about. 

1. So what I want to know is whether this is a particular problem that is always going to be sporadic during a print ? 

2. Is there no straightforward solution ?  I tried several microSD cards, thinking it was a quality issue or corruption of the card but that did not fix it. I also though my thermistor may have been bad, or the wiring out both so I swapped that out, to no avail. 

3.  There was mention of a buggy ADC driver in an older kernel.  Has this same driver been brought along to the new Debian release /

4. I did see in the forums about using an external ADC, is this possible to implement on the CRAMPS (I am not sure if the SPI is broken out).  

5. Is this an issue that everyone who uses the Beaglebone/CRAMPS combo, sees ?

6. I slice in Cura, is this a G-code problem ? ( I am not using the remapped G-codes0

7. 5.  Does this occur with the Replicape board ?

8.  Is it time to throw in the towel ?

I really like the using an embedded platform for running a printer.  This is a bit frustrating as I can not figure it out.  Everyone on this board has been really helpful.  I have scoured the board looking for solutions, but am still at a loss (probably since I am not a programmer or engineer !)  

Thanks,

Jonathan

[Charles Steinkuehler]

What script are you using to read the ADC? It needs to be able to
continue through the occasional errors encountered when reading the
ADC value via sysfs. If these errors are not handled, you will get
behavior like what you're seeing (the user-mode python code crashes
when the kernel throws an I/O Error, at which point the temperatures
stop updating).

I use the hal_temp_bbb script that comes with Machinekit in my
personal configs and haven't had problems:

https://github.com/cdsteinkuehler/machine-configs/blob/master/configs/MendelMax/MendelMax.hal#L32-L34

> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to machinekit+...@googlegroups.com
> <mailto:machinekit+...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>


--
Charles Steinkuehler
cha...@steinkuehler.net

[Jonathan Cohen]

I am using the same call, hal_temp_bbb script that is in the most recent build.  I just started a print and 30 min in, crashed.  I had tried putting a passive filter on the thermistor wire but that did not help it either.  Is it possible that there is some amount of oxidation occurring on the analog pins after some use that may be causing this sort of problem ?  I was thinking to try a different set of pins (e.g. Therm 2) and see if it continues.    

> <mailto:machinekit+unsub...@googlegroups.com>.

[David Kalwar]

I have the exact same issue as described. Also using Blackbone beagle with cramps, two thermistors for Extruder and heated bed and both stop at the same time.

As the machine is quite newly built I have not been able to investigate further.

[Charles Steinkuehler]

I may have just hit this issue myself. I am printing some stuff for
the first time in a while, and after about a day the thermistor values
froze and stopped updating. Interestingly, they continued to be stuck
after relaunching my configuration, making this different than the ADC
issues I had initially with the BBB (several years ago) which was
fixed by ignoring the occasional I/O Exceptions.

I'll try to reproduce this again and see if I can figure out what's
going on.

When your system dies, is it possible to get the thermistor values
reading correctly again without restarting or do you have to reboot or
power-cycle?

--
Charles Steinkuehler
cha...@steinkuehler.net

[Charles Steinkuehler]

Since it looks like this issue takes a while to reproduce, if anyone
has this happen could you please run through the following diagnostic
process and report your results? You can stop at the first step that
results in working temperature readings (ie: no need to power down if
relaunching the application fixed things).

1) Launch machinekit from a console window, so you can see anything
printed by the hal_temp_bbb python script.

...once the thermistor readings get stuck:

2) Check to see if the hal_temp_bbb python script is running (via ps,
top or your favorite utility), and report any text that may have been
recently printed on the console window used to launch machinekit.

3) Shutdown and re-launch the machinekit application

4) Shutdown the machinekit application, the run "realtime stop"
followed by "realtime start" and re-launch machinekit

5) Perform a "warm" boot: "sudo reboot" and re-launch machinekit

6) Perform a "cold" boot: "sudo halt", remove power, reconnect power
and re-launch machinekit

Please share your findings, and at least we'll have an idea of where
to look for problems. Perhaps the universe is telling me I should
design an ADC daughtercard for the CRAMPS board?!? ;-)

--
Charles Steinkuehler
cha...@steinkuehler.net

[Jonathan Cohen]

The hal_temp_bbb python script is running after the freeze occurs.  It requires a reboot to get things going again.  Next time it happens, I go through some of the diagnostic steps you pointed out.   

[Jakob kalwar]

Hi,

I'm the Brother of David Kalwar, we work together on our 3D Printer/Mini Mill. We are using it with an old LCD monitor

After I restartet machinekit twice I got an error message (first restart: Problem not solved). Maybe it can help you helping us out with this problem.

Print file information:

RUN_IN_PLACE=no

LINUXCNC_DIR=

LINUXCNC_BIN_DIR=/usr/bin

LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc

LINUXCNC_SCRIPT_DIR=

LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc

LINUXCNC_CONFIG_DIR=

LINUXCNC_LANG_DIR=/usr/share/linuxcnc/tcl/msgs

INIVAR=/usr/libexec/linuxcnc/inivar

HALCMD=halcmd

LINUXCNC_EMCSH=/usr/bin/wish8.6

MACHINEKIT - 0.1

Machine configuration directory is '/home/machinekit/machinekit/configs/ARM.BeagleBone.CRAMPS'

Machine configuration file is 'CRAMPS.ini'

INIFILE=/home/machinekit/machinekit/configs/ARM.BeagleBone.CRAMPS/CRAMPS.ini

PARAMETER_FILE=pru-stepper.var

TASK=milltask

HALUI=

DISPLAY=axis

Starting Machinekit...

Starting Machinekit server program: linuxcncsvr

Loading Real Time OS, RTAPI, and HAL_LIB modules

Starting Machinekit IO program: io

io started

halcmd loadusr io started

Shutting down and cleaning up Machinekit...

Killing task linuxcncsvr, PID=7016

Removing HAL_LIB, RTAPI, and Real Time OS modules

Removing NML shared memory segments

Cleanup done

Debug file information:

halcmd: hal_init() failed: -22

NOTE: 'rtapi' module must be loaded

halcmd: hal_init() failed: -22

NOTE: 'rtapi' module must be loaded

7016

libnml/os_intf/_shm.c 416: rcs_shm_nattch: shmctl failed: Invalid argument

libnml/os_intf/_shm.c 416: rcs_shm_nattch: shmctl failed: Invalid argument

libnml/os_intf/_shm.c 416: rcs_shm_nattch: shmctl failed: Invalid argument

libnml/os_intf/_shm.c 416: rcs_shm_nattch: shmctl failed: Invalid argument

libnml/os_intf/_shm.c 416: rcs_shm_nattch: shmctl failed: Invalid argument

  PID TTY      STAT   TIME COMMAND

Stopping realtime threads

halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate /var/log/linuxcnc.log

halcmd: the msgd:0 logger demon is not running - please investigate /var/log/linuxcnc.log

Unloading hal components

halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate /var/log/linuxcnc.log

halcmd: the msgd:0 logger demon is not running - please investigate /var/log/linuxcnc.log

halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate /var/log/linuxcnc.log

halcmd: the msgd:0 logger demon is not running - please investigate /var/log/linuxcnc.log

halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate /var/log/linuxcnc.log

halcmd: the msgd:0 logger demon is not running - please investigate /var/log/linuxcnc.log

halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate /var/log/linuxcnc.log

halcmd: the msgd:0 logger demon is not running - please investigate /var/log/linuxcnc.log

halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate /var/log/linuxcnc.log

halcmd: the msgd:0 logger demon is not running - please investigate /var/log/linuxcnc.log

halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate /var/log/linuxcnc.log

halcmd: the msgd:0 logger demon is not running - please investigate /var/log/linuxcnc.log

halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate /var/log/linuxcnc.log

halcmd: the msgd:0 logger demon is not running - please investigate /var/log/linuxcnc.log

halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate /var/log/linuxcnc.log

halcmd: the msgd:0 logger demon is not running - please investigate /var/log/linuxcnc.log

halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate /var/log/linuxcnc.log

halcmd: the msgd:0 logger demon is not running - please investigate /var/log/linuxcnc.log

halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate /var/log/linuxcnc.log

halcmd: the msgd:0 logger demon is not running - please investigate /var/log/linuxcnc.log

halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate /var/log/linuxcnc.log

halcmd: the msgd:0 logger demon is not running - please investigate /var/log/linuxcnc.log

Kernel message information:

[    0.000000] Booting Linux on physical CPU 0x0

[    0.000000] Initializing cgroup subsys cpu

[    0.000000] Linux version 3.8.13-xenomai-r81 (root@b3-jetson-tk1-2gb) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 Fri Oct 14 16:24:43 UTC 2016

[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=50c5387d

[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache

[    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone

[    0.000000] Memory policy: ECC disabled, Data cache writeback

[    0.000000] On node 0 totalpages: 130816

[    0.000000] free_area_init_node: node 0, pgdat c095b9d0, node_mem_map c0a2f000

[    0.000000]   Normal zone: 1024 pages used for memmap

[    0.000000]   Normal zone: 0 pages reserved

[    0.000000]   Normal zone: 129792 pages, LIFO batch:31

[    0.000000] AM335X ES2.1 (l2cache sgx neon )

[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768

[    0.000000] pcpu-alloc: [0] 0 

[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129792

[    0.000000] Kernel command line: console=tty0 console=ttyO0,115200n8 capemgr.disable_partno=BB-BONELT-HDMI root=/dev/mmcblk0p1 rootfstype=ext4 rootwait coherent_pool=1M quiet net.ifnames=0 cape_universal=enable

[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)

[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)

[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)

[    0.000000] __ex_table already sorted, skipping sort

[    0.000000] allocated 1048576 bytes of page_cgroup

[    0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups

[    0.000000] Memory: 511MB = 511MB total

[    0.000000] Memory: 503636k/503636k available, 20652k reserved, 0K highmem

[    0.000000] Virtual kernel memory layout:

    vector  : 0xffff0000 - 0xffff1000   (   4 kB)

    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)

    vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)

    lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)

    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)

    modules : 0xbf800000 - 0xbfe00000   (   6 MB)

      .text : 0xc0008000 - 0xc0894f7c   (8756 kB)

      .init : 0xc0895000 - 0xc08d02c4   ( 237 kB)

      .data : 0xc08d2000 - 0xc095eec0   ( 564 kB)

       .bss : 0xc095eec0 - 0xc0a2eed8   ( 833 kB)

[    0.000000] NR_IRQS:0 nr_irqs:0 0

[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts

[    0.000000] Total of 128 interrupts on 1 active controller

[    0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz

[    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms

[    0.000000] I-pipe, 24.000 MHz clocksource

[    0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz

[    0.000000] Interrupt pipeline (release #3)

[    0.000000] Console: colour dummy device 80x30

[    0.000000] console [tty0] enabled

[    0.000739] Calibrating delay loop... 993.47 BogoMIPS (lpj=969728)

[    0.029193] pid_max: default: 32768 minimum: 301

[    0.029291] Security Framework initialized

[    0.029333] Mount-cache hash table entries: 512

[    0.034153] Initializing cgroup subsys cpuacct

[    0.034178] Initializing cgroup subsys memory

[    0.034220] Initializing cgroup subsys blkio

[    0.034294] CPU: Testing write buffer coherency: ok

[    0.034603] Setting up static identity map for 0x80522958 - 0x805229a4

[    0.035594] devtmpfs: initialized

[    0.041695] omap_hwmod: wd_timer2: _wait_target_disable failed

[    0.093604] pinctrl core: initialized pinctrl subsystem

[    0.093727] rstctl core: initialized rstctl subsystem

[    0.093979] regulator-dummy: no parameters

[    0.094209] NET: Registered protocol family 16

[    0.095775] DMA: preallocated 1024 KiB pool for atomic coherent allocations

[    0.101188] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568

[    0.101680] platform 49000000.edma: alias fck already exists

[    0.101696] platform 49000000.edma: alias fck already exists

[    0.101708] platform 49000000.edma: alias fck already exists

[    0.102172] gpiochip_add: registered GPIOs 0 to 31 on device: gpio

[    0.102252] OMAP GPIO hardware version 0.1

[    0.102715] gpiochip_add: registered GPIOs 32 to 63 on device: gpio

[    0.103217] gpiochip_add: registered GPIOs 64 to 95 on device: gpio

[    0.103799] gpiochip_add: registered GPIOs 96 to 127 on device: gpio

[    0.104020] of_get_named_gpio_flags exited with status 52

[    0.104037] gpio-rctrl rstctl.4: loaded OK

[    0.106545] No ATAGs?

[    0.106560] hw-breakpoint: debug architecture 0x4 unsupported.

[    0.107714] cpsw.0: No hwaddr in dt. Using 78:a5:04:ca:23:5b from efuse

[    0.107733] cpsw.1: No hwaddr in dt. Using 78:a5:04:ca:23:5d from efuse

[    0.114890] bio: create slab <bio-0> at 0

[    0.120071] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine driver

[    0.120206] of_get_named_gpio_flags: can't parse gpios property

[    0.120326] vmmcsd_fixed: 3300 mV 

[    0.121724] SCSI subsystem initialized

[    0.121945] usbcore: registered new interface driver usbfs

[    0.121998] usbcore: registered new interface driver hub

[    0.122189] usbcore: registered new device driver usb

[    0.123279] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz

[    0.124083] input: tps65217_pwr_but as /devices/ocp.3/44e0b000.i2c/i2c-0/0-0024/input/input0

[    0.125174] DCDC1: at 1500 mV 

[    0.125949] vdd_mpu: 925 <--> 1325 mV at 1325 mV 

[    0.126691] vdd_core: 925 <--> 1150 mV at 1125 mV 

[    0.127442] LDO1: at 1800 mV 

[    0.128173] LDO2: at 3300 mV 

[    0.129555] LDO3: 1800 mV 

[    0.130302] LDO4: at 3300 mV 

[    0.130968] tps65217 0-0024: TPS65217 ID 0xe version 1.2

[    0.131388] omap_i2c 44e0b000.i2c: unable to select pin group

[    0.131794] omap_i2c 4819c000.i2c: bus 1 rev0.11 at 100 kHz

[    0.132875] omap_i2c 4819c000.i2c: unable to select pin group

[    0.133010] media: Linux media interface: v0.10

[    0.133062] Linux video capture interface: v2.00

[    0.133134] pps_core: LinuxPPS API ver. 1 registered

[    0.133142] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giom...@linux.it>

[    0.133164] PTP clock support registered

[    0.133526] Advanced Linux Sound Architecture Driver Initialized.

[    0.134021] NetLabel: Initializing

[    0.134030] NetLabel:  domain hash size = 128

[    0.134036] NetLabel:  protocols = UNLABELED CIPSOv4

[    0.134095] NetLabel:  unlabeled traffic allowed by default

[    0.134344] Switching to clocksource ipipe_tsc

[    0.158665] NET: Registered protocol family 2

[    0.159194] TCP established hash table entries: 4096 (order: 3, 32768 bytes)

[    0.159277] TCP bind hash table entries: 4096 (order: 4, 81920 bytes)

[    0.159374] TCP: Hash tables configured (established 4096 bind 4096)

[    0.159437] TCP: reno registered

[    0.159450] UDP hash table entries: 256 (order: 1, 12288 bytes)

[    0.159474] UDP-Lite hash table entries: 256 (order: 1, 12288 bytes)

[    0.159667] NET: Registered protocol family 1

[    0.160046] RPC: Registered named UNIX socket transport module.

[    0.160059] RPC: Registered udp transport module.

[    0.160065] RPC: Registered tcp transport module.

[    0.160072] RPC: Registered tcp NFSv4.1 backchannel transport module.

[    0.160249] Trying to unpack rootfs image as initramfs...

[    0.393577] Freeing initrd memory: 3552K

[    0.393915] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available

[    0.394180] CPU PMU: attempt to register multiple PMU devices!

[    0.394202] arm-pmu: probe of arm-pmu failed with error -28

[    0.394603] omap2_mbox_probe: platform not supported

[    0.547890] I-pipe: head domain Xenomai registered.

[    0.547918] Xenomai: hal/arm started.

[    0.548978] Xenomai: scheduling class idle registered.

[    0.548998] Xenomai: scheduling class rt registered.

[    0.552506] Xenomai: real-time nucleus v2.6.3 (Lies and Truths) loaded.

[    0.552516] Xenomai: debug mode enabled.

[    0.552891] Xenomai: starting native API services.

[    0.552901] Xenomai: starting POSIX services.

[    0.553025] Xenomai: starting RTDM services.

[    0.553704] VFS: Disk quotas dquot_6.5.2

[    0.553759] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)

[    0.554380] NFS: Registering the id_resolver key type

[    0.554448] Key type id_resolver registered

[    0.554457] Key type id_legacy registered

[    0.554656] fuse init (API version 7.20)

[    0.554969] Btrfs loaded

[    0.555044] msgmni has been set to 990

[    0.556034] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248)

[    0.556048] io scheduler noop registered

[    0.556055] io scheduler deadline registered

[    0.556077] io scheduler cfq registered (default)

[    0.557039] tps65217-bl tps65217-bl: no platform data provided

[    0.557075] tps65217-bl: probe of tps65217-bl failed with error -22

[    0.557509] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled

[    0.558665] omap_uart 44e09000.serial: did not get pins for uart0 error: -19

[    0.558824] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 72) is a OMAP UART0

[    0.570588] console [ttyO0] enabled

[    0.571176] [drm] Initialized drm 1.1.0 20060810

[    0.576497] brd: module loaded

[    0.579231] loop: module loaded

[    0.579307] at24 0-0050: 32768 byte 24c256 EEPROM, writable, 1 bytes/write

[    0.579345] at24 1-0054: 32768 byte 24c256 EEPROM, writable, 1 bytes/write

[    0.579375] at24 1-0055: 32768 byte 24c256 EEPROM, writable, 1 bytes/write

[    0.579416] at24 1-0056: 32768 byte 24c256 EEPROM, writable, 1 bytes/write

[    0.579446] at24 1-0057: 32768 byte 24c256 EEPROM, writable, 1 bytes/write

[    0.586092] bone-capemgr bone_capemgr.9: Baseboard: 'A335BNLT,00C0,3614BBBK9384'

[    0.586117] bone-capemgr bone_capemgr.9: compatible-baseboard=ti,beaglebone-black

[    0.586152] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# BB-BONELT-HDMI

[    0.610184] bone-capemgr bone_capemgr.9: bone: Invalid signature 'ffffffff' at slot 0

[    0.618377] bone-capemgr bone_capemgr.9: slot #0: No cape found

[    0.651975] bone-capemgr bone_capemgr.9: slot #1: No cape found

[    0.689070] bone-capemgr bone_capemgr.9: slot #2: No cape found

[    0.726179] bone-capemgr bone_capemgr.9: slot #3: No cape found

[    0.732417] bone-capemgr bone_capemgr.9: slot #4: specific override

[    0.732438] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 4

[    0.732453] bone-capemgr bone_capemgr.9: slot #4: 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'

[    0.732520] bone-capemgr bone_capemgr.9: slot #5: specific override

[    0.732536] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 5

[    0.732550] bone-capemgr bone_capemgr.9: slot #5: 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'

[    0.732624] bone-capemgr bone_capemgr.9: slot #6: specific override

[    0.732639] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 6

[    0.732653] bone-capemgr bone_capemgr.9: slot #6: 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'

[    0.732750] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape with part# BB-BONELT-HDMI

[    0.732939] bone-capemgr bone_capemgr.9: loader: before slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

[    0.732953] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

[    0.732980] bone-capemgr bone_capemgr.9: initialized OK.

[    0.734041] OneNAND driver initializing

[    0.734738] usbcore: registered new interface driver cdc_ether

[    0.734780] usbcore: registered new interface driver rndis_host

[    0.734874] usbcore: registered new interface driver cdc_ncm

[    0.735147] bone-capemgr bone_capemgr.9: loader: after slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

[    0.735171] bone-capemgr bone_capemgr.9: slot #4: Requesting firmware 'cape-bone-2g-emmc1.dtbo' for board-name 'Bone-LT-eMMC-2G', version '00A0'

[    0.735189] bone-capemgr bone_capemgr.9: slot #4: dtbo 'cape-bone-2g-emmc1.dtbo' loaded; converting to live tree

[    0.735391] bone-capemgr bone_capemgr.9: slot #4: #2 overlays

[    0.735889] bone-capemgr bone_capemgr.9: slot #4: Applied #2 overlays.

[    0.735905] bone-capemgr bone_capemgr.9: loader: done slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

[    0.736269] usbcore: registered new interface driver cdc_acm

[    0.736279] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

[    0.736286] Initializing USB Mass Storage driver...

[    0.736341] usbcore: registered new interface driver usb-storage

[    0.736348] USB Mass Storage support registered.

[    0.736475] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)

[    0.736679] musb-hdrc musb-hdrc.0.auto: pdev->id = 0

[    0.736694] musb-hdrc musb-hdrc.0.auto: drivers/usb/musb/musb_dsps.c:480 dsps_musb_init: OK

[    0.736718] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)

[    0.736728] musb-hdrc: MHDRC RTL version 2.0 

[    0.736735] musb-hdrc: setup fifo_mode 4

[    0.736751] musb-hdrc: 28/31 max ep, 16384/16384 memory

[    0.736827] musb-hdrc musb-hdrc.0.auto: *** mode=3

[    0.736837] musb-hdrc musb-hdrc.0.auto: *** power=250

[    0.737200] musb-hdrc musb-hdrc.1.auto: pdev->id = 1

[    0.737213] musb-hdrc musb-hdrc.1.auto: drivers/usb/musb/musb_dsps.c:480 dsps_musb_init: OK

[    0.737235] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)

[    0.737244] musb-hdrc: MHDRC RTL version 2.0 

[    0.737250] musb-hdrc: setup fifo_mode 4

[    0.737260] musb-hdrc: 28/31 max ep, 16384/16384 memory

[    0.737323] musb-hdrc musb-hdrc.1.auto: *** mode=1

[    0.737332] musb-hdrc musb-hdrc.1.auto: *** power=250

[    0.737343] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver

[    0.737502] bone-capemgr bone_capemgr.9: loader: before slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[    0.737515] bone-capemgr bone_capemgr.9: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[    0.737529] bone-capemgr bone_capemgr.9: loader: after slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[    0.737553] bone-capemgr bone_capemgr.9: slot #6: Requesting firmware 'cape-boneblack-hdmin-00A0.dtbo' for board-name 'Bone-Black-HDMIN', version '00A0'

[    0.737583] bone-capemgr bone_capemgr.9: slot #6: dtbo 'cape-boneblack-hdmin-00A0.dtbo' loaded; converting to live tree

[    0.738077] bone-capemgr bone_capemgr.9: slot #6: #2 overlays

[    0.739107] platform 4830e000.fb: alias fck already exists

[    0.739229] bone-capemgr bone_capemgr.9: slot #6: Applied #2 overlays.

[    0.739242] bone-capemgr bone_capemgr.9: loader: done slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[    0.739446] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 1

[    0.739479] musb-hdrc musb-hdrc.1.auto: supports USB remote wakeup

[    0.739546] usb usb1: default language 0x0409

[    0.739576] usb usb1: udev 1, busnum 1, minor = 0

[    0.739586] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002

[    0.739597] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1

[    0.739606] usb usb1: Product: MUSB HDRC host driver

[    0.739615] usb usb1: Manufacturer: Linux 3.8.13-xenomai-r81 musb-hcd

[    0.739624] usb usb1: SerialNumber: musb-hdrc.1.auto

[    0.740099] usb usb1: usb_probe_device

[    0.740115] usb usb1: configuration #1 chosen from 1 choice

[    0.740153] usb usb1: adding 1-0:1.0 (config #1, interface 0)

[    0.740263] hub 1-0:1.0: usb_probe_interface

[    0.740275] hub 1-0:1.0: usb_probe_interface - got id

[    0.740290] hub 1-0:1.0: USB hub found

[    0.740313] hub 1-0:1.0: 1 port detected

[    0.740322] hub 1-0:1.0: standalone hub

[    0.740330] hub 1-0:1.0: individual port power switching

[    0.740338] hub 1-0:1.0: no over-current protection

[    0.740347] hub 1-0:1.0: Single TT

[    0.740356] hub 1-0:1.0: TT requires at most 8 FS bit times (666 ns)

[    0.740365] hub 1-0:1.0: power on to power good time: 10ms

[    0.740384] hub 1-0:1.0: local power source is good

[    0.740432] hub 1-0:1.0: enabling power on all ports

[    0.740986] mousedev: PS/2 mouse device common for all mice

[    0.741913] lsm303dlhc_acc accelerometer driver: init

[    0.741957] i2c-core: driver [lsm303dlhc_acc] using legacy suspend method

[    0.741964] i2c-core: driver [lsm303dlhc_acc] using legacy resume method

[    0.741973] lsm303dlhc_mag driver: init

[    0.742009] lsm330_acc accelerometer driver: init

[    0.742042] i2c-core: driver [lsm330_acc] using legacy suspend method

[    0.742049] i2c-core: driver [lsm330_acc] using legacy resume method

[    0.742058] lsm330_gyr: gyroscope sysfs driver init

[    0.742567] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0

[    0.742601] 44e3e000.rtc: already running

[    0.742736] i2c /dev entries driver

[    0.743549] pps_ldisc: PPS line discipline registered

[    0.743618] Driver for 1-wire Dallas network protocol.

[    0.744715] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec

[    0.745084] device-mapper: ioctl: 4.23.1-ioctl (2012-12-18) initialised: dm-d...@redhat.com

[    0.745306] of_get_named_gpio_flags exited with status 6

[    0.745316] of_get_named_gpio_flags: can't parse gpios property

[    0.745323] of_get_named_gpio_flags: can't parse gpios property

[    0.745342] omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset' failed

[    0.752571] omap_hsmmc mmc.5: Failed to get rstctl; not using any

[    0.752844] edma-dma-engine edma-dma-engine.0: allocated channel for 0:25

[    0.752879] edma-dma-engine edma-dma-engine.0: allocated channel for 0:24

[    0.753026] mmc.5 supply vmmc_aux not found, using dummy regulator

[    0.753299] omap_hsmmc mmc.5: pins are not configured from the driver

[    0.779064] of_get_named_gpio_flags: can't parse gpios property

[    0.779077] of_get_named_gpio_flags: can't parse gpios property

[    0.779084] of_get_named_gpio_flags: can't parse gpios property

[    0.779111] gpio-rctrl rstctl.4: gpio_rctrl_request eMMC_RSTn

[    0.779167] omap_hsmmc mmc.11: Got rstctl (gpio:#0 name eMMC_RSTn) label:eMMC_RSTn

[    0.779179] gpio-rctrl rstctl.4: gpio_rctrl_deassert eMMC_RSTn

[    0.779352] edma-dma-engine edma-dma-engine.0: allocated channel for 0:3

[    0.779382] edma-dma-engine edma-dma-engine.0: allocated channel for 0:2

[    0.779693] mmc.11 supply vmmc_aux not found, using dummy regulator

[    0.779768] omap_hsmmc mmc.11: pins are not configured from the driver

[    0.806482] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.8

[    0.818141] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22

[    0.825419] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single

[    0.834340] leds-gpio gpio-leds.8: pins are not configured from the driver

[    0.834359] of_get_named_gpio_flags exited with status 53

[    0.834369] of_get_named_gpio_flags exited with status 54

[    0.834378] of_get_named_gpio_flags exited with status 55

[    0.834387] of_get_named_gpio_flags exited with status 56

[    0.834398] of_get_named_gpio_flags exited with status 53

[    0.834534] of_get_named_gpio_flags exited with status 54

[    0.834638] of_get_named_gpio_flags exited with status 55

[    0.834737] of_get_named_gpio_flags exited with status 56

[    0.835016] ledtrig-cpu: registered to indicate activity on CPUs

[    0.835227] edma-dma-engine edma-dma-engine.0: allocated channel for 0:36

[    0.835273] omap-sham 53100000.sham: hw accel on OMAP rev 4.3

[    0.836428] omap-aes 53500000.aes: OMAP AES hw accel rev: 3.2

[    0.836495] edma-dma-engine edma-dma-engine.0: allocated channel for 0:5

[    0.836526] edma-dma-engine edma-dma-engine.0: allocated channel for 0:6

[    0.838924] usbcore: registered new interface driver usbhid

[    0.838936] usbhid: USB HID core driver

[    0.839648] ashmem: initialized

[    0.839863] logger: created 256K log 'log_main'

[    0.840029] logger: created 256K log 'log_events'

[    0.840205] logger: created 256K log 'log_radio'

[    0.840360] logger: created 256K log 'log_system'

[    0.842265] TCP: cubic registered

[    0.842327] NET: Registered protocol family 10

[    0.842963] NET: Registered protocol family 17

[    0.843152] Key type dns_resolver registered

[    0.843455] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3

[    0.843475] ThumbEE CPU extension supported.

[    0.843505] Registering SWP/SWPB emulation handler

[    0.843757] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000

[    0.843805] hub 1-0:1.0: hub_suspend

[    0.843831] usb usb1: bus auto-suspend, wakeup 1

[    0.844353] registered taskstats version 1

[    0.845730] of_get_named_gpio_flags: can't parse gpios property

[    0.845747] tilcdc 4830e000.fb: No power control GPIO

[    0.848868] mmc0: host does not support reading read-only switch. assuming write-enable.

[    0.850959] mmc0: new high speed SDHC card at address b368

[    0.851873] mmcblk0: mmc0:b368 SD    14.7 GiB 

[    0.853333]  mmcblk0: p1

[    0.905748] mmc1: BKOPS_EN bit is not set

[    0.909543] mmc1: new high speed MMC card at address 0001

[    0.909910] mmcblk1: mmc1:0001 MMC04G 3.60 GiB 

[    0.910015] mmcblk1boot0: mmc1:0001 MMC04G partition 1 2.00 MiB

[    0.910129] mmcblk1boot1: mmc1:0001 MMC04G partition 2 2.00 MiB

[    0.910949]  mmcblk1: p1 p2

[    0.912461]  mmcblk1boot1: unknown partition table

[    0.913586]  mmcblk1boot0: unknown partition table

[    0.914436] usb usb1: usb wakeup-resume

[    0.914471] usb usb1: usb auto-resume

[    0.914490] hub 1-0:1.0: hub_resume

[    0.914522] hub 1-0:1.0: port 1: status 0101 change 0001

[    0.958927] tilcdc 4830e000.fb: found TDA19988

[    0.959476] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).

[    0.959486] [drm] No driver support for vblank timestamp query.

[    1.017249] hub 1-0:1.0: state 7 ports 1 chg 0002 evt 0000

[    1.017280] hub 1-0:1.0: port 1, status 0101, change 0000, 12 Mb/s

[    1.027947] Console: switching to colour frame buffer device 160x64

[    1.037057] tilcdc 4830e000.fb: fb0:  frame buffer device

[    1.037066] tilcdc 4830e000.fb: registered panic notifier

[    1.037092] [drm] Initialized tilcdc 1.0.0 20121205 on minor 0

[    1.085571] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6

[    1.085590] davinci_mdio 4a101000.mdio: detected phy mask fffffffe

[    1.090744] libphy: 4a101000.mdio: probed

[    1.090771] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720

[    1.090926] Detected MACID = 78:a5:04:ca:23:5b

[    1.091028] cpsw 4a100000.ethernet: NAPI disabled

[    1.092328] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 00:19:41 UTC (946685981)

[    1.095940] ALSA device list:

[    1.095961]   No soundcards found.

[    1.096509] Freeing init memory: 236K

[    1.123117] usb 1-1: new high-speed USB device number 2 using musb-hdrc

[    1.242160] usb 1-1: default language 0x0409

[    1.242229] usb 1-1: udev 2, busnum 1, minor = 1

[    1.242242] usb 1-1: New USB device found, idVendor=1a40, idProduct=0101

[    1.242252] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0

[    1.242262] usb 1-1: Product: USB 2.0 Hub

[    1.242646] usb 1-1: usb_probe_device

[    1.242662] usb 1-1: configuration #1 chosen from 1 choice

[    1.245329] usb 1-1: adding 1-1:1.0 (config #1, interface 0)

[    1.245499] hub 1-1:1.0: usb_probe_interface

[    1.245514] hub 1-1:1.0: usb_probe_interface - got id

[    1.245534] hub 1-1:1.0: USB hub found

[    1.245634] hub 1-1:1.0: 4 ports detected

[    1.245645] hub 1-1:1.0: standalone hub

[    1.245653] hub 1-1:1.0: ganged power switching

[    1.245661] hub 1-1:1.0: global over-current protection

[    1.245669] hub 1-1:1.0: Single TT

[    1.245692] hub 1-1:1.0: TT requires at most 8 FS bit times (666 ns)

[    1.245747] hub 1-1:1.0: power on to power good time: 100ms

[    1.245885] hub 1-1:1.0: local power source is good

[    1.245897] hub 1-1:1.0: no over-current condition exists

[    1.246067] hub 1-1:1.0: enabling power on all ports

[    1.246439] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002

[    1.246467] hub 1-0:1.0: port 1 enable change, status 00000503

[    1.347545] hub 1-1:1.0: port 2: status 0301 change 0001

[    1.347644] hub 1-1:1.0: port 3: status 0301 change 0001

[    1.449007] hub 1-1:1.0: state 7 ports 4 chg 000c evt 0000

[    1.449102] hub 1-1:1.0: port 2, status 0301, change 0000, 1.5 Mb/s

[    1.515416] usb 1-1.2: new low-speed USB device number 3 using musb-hdrc

[    1.597477] usb 1-1.2: skipped 1 descriptor after interface

[    1.597987] usb 1-1.2: default language 0x0409

[    1.599990] usb 1-1.2: udev 3, busnum 1, minor = 2

[    1.600008] usb 1-1.2: New USB device found, idVendor=093a, idProduct=2510

[    1.600020] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0

[    1.600030] usb 1-1.2: Product: USB Optical Mouse

[    1.600039] usb 1-1.2: Manufacturer: PixArt

[    1.600446] usb 1-1.2: usb_probe_device

[    1.600465] usb 1-1.2: configuration #1 chosen from 1 choice

[    1.600902] usb 1-1.2: adding 1-1.2:1.0 (config #1, interface 0)

[    1.601090] usbhid 1-1.2:1.0: usb_probe_interface

[    1.601104] usbhid 1-1.2:1.0: usb_probe_interface - got id

[    1.603959] input: PixArt USB Optical Mouse as /devices/ocp.3/47400000.usb/musb-hdrc.1.auto/usb1/1-1/1-1.2/1-1.2:1.0/input/input1

[    1.604497] hid-generic 0003:093A:2510.0001: input,hidraw0: USB HID v1.11 Mouse [PixArt USB Optical Mouse] on usb-musb-hdrc.1.auto-1.2/input0

[    1.604783] hub 1-1:1.0: port 3, status 0301, change 0000, 1.5 Mb/s

[    1.669751] usb 1-1.3: new low-speed USB device number 4 using musb-hdrc

[    1.752877] usb 1-1.3: skipped 1 descriptor after interface

[    1.753385] usb 1-1.3: default language 0x0409

[    1.755999] usb 1-1.3: udev 4, busnum 1, minor = 3

[    1.756019] usb 1-1.3: New USB device found, idVendor=046d, idProduct=c315

[    1.756030] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0

[    1.756040] usb 1-1.3: Product: Logitech USB Keyboard

[    1.756049] usb 1-1.3: Manufacturer: Logitech

[    1.756460] usb 1-1.3: usb_probe_device

[    1.756479] usb 1-1.3: configuration #1 chosen from 1 choice

[    1.756900] usb 1-1.3: adding 1-1.3:1.0 (config #1, interface 0)

[    1.757093] usbhid 1-1.3:1.0: usb_probe_interface

[    1.757106] usbhid 1-1.3:1.0: usb_probe_interface - got id

[    1.761220] input: Logitech Logitech USB Keyboard as /devices/ocp.3/47400000.usb/musb-hdrc.1.auto/usb1/1-1/1-1.3/1-1.3:1.0/input/input2

[    1.761726] hid-generic 0003:046D:C315.0002: input,hidraw1: USB HID v1.10 Keyboard [Logitech Logitech USB Keyboard] on usb-musb-hdrc.1.auto-1.3/input0

[    1.761926] hub 1-1:1.0: state 7 ports 4 chg 0000 evt 0008

[    8.925030] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)

[    9.437686] systemd[1]: System time before build time, advancing clock.

[    9.474996] systemd[1]: Failed to insert module 'kdbus': Function not implemented

[    9.511184] systemd[1]: systemd 230 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)

[    9.511778] systemd[1]: Detected architecture arm.

[    9.513106] systemd[1]: Set hostname to <beaglebone>.

[   10.030824] systemd[1]: Listening on Syslog Socket.

[   10.031722] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.

[   10.032282] systemd[1]: Reached target Remote File Systems (Pre).

[   10.032389] systemd[1]: Reached target Remote File Systems.

[   10.032954] systemd[1]: Created slice System Slice.

[   10.033383] systemd[1]: Created slice system-serial\x2dgetty.slice.

[   10.033706] systemd[1]: Created slice system-getty.slice.

[   10.033812] systemd[1]: Reached target Swap.

[   10.034048] systemd[1]: Created slice User and Session Slice.

[   10.034390] systemd[1]: Listening on udev Control Socket.

[   10.034509] systemd[1]: Reached target Encrypted Volumes.

[   10.034707] systemd[1]: Listening on udev Kernel Socket.

[   10.035116] systemd[1]: Listening on Journal Socket.

[   10.038570] systemd[1]: Mounting POSIX Message Queue File System...

[   10.041909] systemd[1]: Starting LSB: Set console font and keymap...

[   10.047722] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.

[   10.075299] systemd[1]: Starting Create list of required static device nodes for the current kernel...

[   10.075660] systemd[1]: Listening on fsck to fsckd communication Socket.

[   10.109322] systemd[1]: Starting File System Check on Root Device...

[   10.109477] systemd[1]: Reached target Slices.

[   10.150488] systemd[1]: Starting Load Kernel Modules...

[   10.164256] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.

[   10.164710] systemd[1]: Listening on Journal Socket (/dev/log).

[   10.180031] systemd[1]: Starting Journal Service...

[   10.204172] systemd[1]: Mounting /sys/kernel/debug...

[   10.222671] systemd[1]: Started Forward Password Requests to Wall Directory Watch.

[   10.286294] systemd[1]: Mounted POSIX Message Queue File System.

[   10.300960] systemd[1]: Started LSB: Set console font and keymap.

[   10.322967] systemd[1]: Started Create list of required static device nodes for the current kernel.

[   10.324744] systemd[1]: Started Load Kernel Modules.

[   10.325554] systemd[1]: Mounted /sys/kernel/debug.

[   10.348616] systemd[1]: Started File System Check on Root Device.

[   10.382864] systemd[1]: Started File System Check Daemon to report status.

[   10.395871] systemd[1]: Mounting FUSE Control File System...

[   10.433428] systemd[1]: Starting Apply Kernel Variables...

[   10.463377] systemd[1]: Starting Create Static Device Nodes in /dev...

[   10.496697] systemd[1]: Started Apply Kernel Variables.

[   10.497605] systemd[1]: Mounted FUSE Control File System.

[   10.591929] systemd[1]: Started Create Static Device Nodes in /dev.

[   10.608266] systemd[1]: Starting udev Kernel Device Manager...

[   10.848288] systemd[1]: Started udev Kernel Device Manager.

[   10.863116] systemd[1]: Starting LSB: Set preliminary keymap...

[   10.864370] systemd[1]: Started LSB: Set preliminary keymap.

[   10.875993] systemd[1]: Starting Remount Root and Kernel File Systems...

[   10.943044] systemd[1]: Started Journal Service.

[   10.996460] EXT4-fs (mmcblk0p1): re-mounted. Opts: errors=remount-ro

[   11.256191] systemd-journald[558]: Received request to flush runtime journal from PID 1

[   14.660927] net eth0: initializing cpsw version 1.12 (0)

[   14.663104] net eth0: phy found : id is : 0x7c0f1

[   14.663122] libphy: PHY 4a101000.mdio:01 not found

[   14.668247] net eth0: phy 4a101000.mdio:01 not found on slave 1

[   14.680403] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

[   15.687671] usb0: MAC 78:a5:04:ca:23:5d

[   15.687689] usb0: HOST MAC 78:a5:04:ca:23:5c

[   15.687782]  gadget: Ethernet Gadget, version: Memorial Day 2008

[   15.687801]  gadget: g_ether ready

[   15.687840] musb-hdrc musb-hdrc.0.auto: MUSB HDRC host driver

[   15.713643] musb-hdrc musb-hdrc.0.auto: new USB bus registered, assigned bus number 2

[   15.713684] musb-hdrc musb-hdrc.0.auto: supports USB remote wakeup

[   15.713752] usb usb2: default language 0x0409

[   15.713782] usb usb2: udev 1, busnum 2, minor = 128

[   15.713793] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002

[   15.713804] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1

[   15.713813] usb usb2: Product: MUSB HDRC host driver

[   15.713823] usb usb2: Manufacturer: Linux 3.8.13-xenomai-r81 musb-hcd

[   15.713832] usb usb2: SerialNumber: musb-hdrc.0.auto

[   15.717408] usb usb2: usb_probe_device

[   15.717432] usb usb2: configuration #1 chosen from 1 choice

[   15.717505] usb usb2: adding 2-0:1.0 (config #1, interface 0)

[   15.717621] hub 2-0:1.0: usb_probe_interface

[   15.717632] hub 2-0:1.0: usb_probe_interface - got id

[   15.717650] hub 2-0:1.0: USB hub found

[   15.717673] hub 2-0:1.0: 1 port detected

[   15.717681] hub 2-0:1.0: standalone hub

[   15.717691] hub 2-0:1.0: individual port power switching

[   15.717699] hub 2-0:1.0: no over-current protection

[   15.717707] hub 2-0:1.0: Single TT

[   15.717717] hub 2-0:1.0: TT requires at most 8 FS bit times (666 ns)

[   15.717726] hub 2-0:1.0: power on to power good time: 10ms

[   15.717746] hub 2-0:1.0: local power source is good

[   15.717796] hub 2-0:1.0: enabling power on all ports

[   15.818148] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000

[   15.818203] hub 2-0:1.0: hub_suspend

[   15.818230] usb usb2: bus auto-suspend, wakeup 1

[   16.283174] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready

[   21.941141] tilcdc 4830e000.fb: timeout waiting for framedone

[   27.611940] omap_rng 48310000.rng: base address of priv is -97452032

[   27.619007] omap_rng 48310000.rng: OMAP Random Number Generator ver. 20

[   45.263231] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)

[   74.002971] bone-capemgr bone_capemgr.9: part_number 'cape-universal', version 'N/A'

[   74.003038] bone-capemgr bone_capemgr.9: slot #7: generic override

[   74.003054] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 7

[   74.003069] bone-capemgr bone_capemgr.9: slot #7: 'Override Board Name,00A0,Override Manuf,cape-universal'

[   74.003155] bone-capemgr bone_capemgr.9: slot #7: Requesting part number/version based 'cape-universal-00A0.dtbo

[   74.003170] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 'cape-universal-00A0.dtbo' for board-name 'Override Board Name', version '00A0'

[   74.003196] bone-capemgr bone_capemgr.9: slot #7: dtbo 'cape-universal-00A0.dtbo' loaded; converting to live tree

[   74.031035] bone-capemgr bone_capemgr.9: slot #7: #23 overlays

[   74.082502] of_get_named_gpio_flags exited with status 114

[   74.082729] gpio-of-helper cape-universal.51: Allocated GPIO id=0

[   74.082766] of_get_named_gpio_flags exited with status 7

[   74.082877] gpio-of-helper cape-universal.51: Allocated GPIO id=1

[   74.082903] of_get_named_gpio_flags exited with status 116

[   74.083001] gpio-of-helper cape-universal.51: Allocated GPIO id=2

[   74.083021] of_get_named_gpio_flags exited with status 20

[   74.083114] gpio-of-helper cape-universal.51: Allocated GPIO id=3

[   74.083136] of_get_named_gpio_flags exited with status 110

[   74.083241] gpio-of-helper cape-universal.51: Allocated GPIO id=4

[   74.083265] of_get_named_gpio_flags exited with status 112

[   74.083368] gpio-of-helper cape-universal.51: Allocated GPIO id=5

[   74.083391] of_get_named_gpio_flags exited with status 111

[   74.083486] gpio-of-helper cape-universal.51: Allocated GPIO id=6

[   74.083509] of_get_named_gpio_flags exited with status 113

[   74.083695] gpio-of-helper cape-universal.51: Allocated GPIO id=7

[   74.083724] of_get_named_gpio_flags exited with status 115

[   74.083835] gpio-of-helper cape-universal.51: Allocated GPIO id=8

[   74.083857] of_get_named_gpio_flags exited with status 14

[   74.083962] gpio-of-helper cape-universal.51: Allocated GPIO id=9

[   74.083985] of_get_named_gpio_flags exited with status 117

[   74.084071] gpio-of-helper cape-universal.51: Allocated GPIO id=10

[   74.084090] of_get_named_gpio_flags exited with status 15

[   74.084175] gpio-of-helper cape-universal.51: Allocated GPIO id=11

[   74.084198] of_get_named_gpio_flags exited with status 49

[   74.084291] gpio-of-helper cape-universal.51: Allocated GPIO id=12

[   74.084312] of_get_named_gpio_flags exited with status 2

[   74.084407] gpio-of-helper cape-universal.51: Allocated GPIO id=13

[   74.084427] of_get_named_gpio_flags exited with status 3

[   74.084513] gpio-of-helper cape-universal.51: Allocated GPIO id=14

[   74.084532] of_get_named_gpio_flags exited with status 4

[   74.084623] gpio-of-helper cape-universal.51: Allocated GPIO id=15

[   74.084641] of_get_named_gpio_flags exited with status 5

[   74.084726] gpio-of-helper cape-universal.51: Allocated GPIO id=16

[   74.084745] of_get_named_gpio_flags exited with status 51

[   74.084838] gpio-of-helper cape-universal.51: Allocated GPIO id=17

[   74.084857] of_get_named_gpio_flags exited with status 48

[   74.084945] gpio-of-helper cape-universal.51: Allocated GPIO id=18

[   74.084964] of_get_named_gpio_flags exited with status 50

[   74.085054] gpio-of-helper cape-universal.51: Allocated GPIO id=19

[   74.085074] of_get_named_gpio_flags exited with status 31

[   74.085159] gpio-of-helper cape-universal.51: Allocated GPIO id=20

[   74.085179] of_get_named_gpio_flags exited with status 60

[   74.085319] gpio-of-helper cape-universal.51: Allocated GPIO id=21

[   74.085344] of_get_named_gpio_flags exited with status 30

[   74.085436] gpio-of-helper cape-universal.51: Allocated GPIO id=22

[   74.085457] of_get_named_gpio_flags exited with status 61

[   74.085591] gpio-of-helper cape-universal.51: Allocated GPIO id=23

[   74.085616] of_get_named_gpio_flags exited with status 22

[   74.085713] gpio-of-helper cape-universal.51: Allocated GPIO id=24

[   74.085736] of_get_named_gpio_flags exited with status 65

[   74.085874] gpio-of-helper cape-universal.51: Allocated GPIO id=25

[   74.085898] of_get_named_gpio_flags exited with status 27

[   74.085991] gpio-of-helper cape-universal.51: Allocated GPIO id=26

[   74.086013] of_get_named_gpio_flags exited with status 46

[   74.086100] gpio-of-helper cape-universal.51: Allocated GPIO id=27

[   74.086121] of_get_named_gpio_flags exited with status 47

[   74.086206] gpio-of-helper cape-universal.51: Allocated GPIO id=28

[   74.086225] of_get_named_gpio_flags exited with status 26

[   74.086321] gpio-of-helper cape-universal.51: Allocated GPIO id=29

[   74.086342] of_get_named_gpio_flags exited with status 23

[   74.086431] gpio-of-helper cape-universal.51: Allocated GPIO id=30

[   74.086451] of_get_named_gpio_flags exited with status 44

[   74.086542] gpio-of-helper cape-universal.51: Allocated GPIO id=31

[   74.086563] of_get_named_gpio_flags exited with status 45

[   74.086654] gpio-of-helper cape-universal.51: Allocated GPIO id=32

[   74.086677] of_get_named_gpio_flags exited with status 68

[   74.086766] gpio-of-helper cape-universal.51: Allocated GPIO id=33

[   74.086788] of_get_named_gpio_flags exited with status 69

[   74.086889] gpio-of-helper cape-universal.51: Allocated GPIO id=34

[   74.086910] of_get_named_gpio_flags exited with status 67

[   74.087000] gpio-of-helper cape-universal.51: Allocated GPIO id=35

[   74.087020] of_get_named_gpio_flags exited with status 66

[   74.087109] gpio-of-helper cape-universal.51: Allocated GPIO id=36

[   74.087119] gpio-of-helper cape-universal.51: ready

[   74.098596] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 73) is a OMAP UART1

[   74.101988] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 74) is a OMAP UART2

[   74.106559] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 45) is a OMAP UART4

[   74.113192] omap_i2c 4802a000.i2c: bus 2 rev0.11 at 100 kHz

[   74.113226] omap_i2c 4802a000.i2c: unable to select pin group

[   74.132640] edma-dma-engine edma-dma-engine.0: allocated channel for 0:19

[   74.132728] edma-dma-engine edma-dma-engine.0: allocated channel for 0:18

[   74.150505] edma-dma-engine edma-dma-engine.0: allocated channel for 0:17

[   74.150582] edma-dma-engine edma-dma-engine.0: allocated channel for 0:16

[   74.171013] edma-dma-engine edma-dma-engine.0: allocated channel for 0:45

[   74.171107] edma-dma-engine edma-dma-engine.0: allocated channel for 0:44

[   74.194324] edma-dma-engine edma-dma-engine.0: allocated channel for 0:43

[   74.194410] edma-dma-engine edma-dma-engine.0: allocated channel for 0:42

[   74.195942] platform 481cc000.d_can: alias fck already exists

[   74.196310] platform 481d0000.d_can: alias fck already exists

[   74.211434] omap_hwmod: pruss: failed to hardreset

[   74.213763] bone-capemgr bone_capemgr.9: slot #7: Applied #23 overlays.

[   75.438354] CAN device driver interface

[   75.462606] c_can_platform 481cc000.d_can: invalid resource

[   75.468491] c_can_platform 481cc000.d_can: control memory is not used for raminit

[   75.469088] c_can_platform 481cc000.d_can: c_can_platform device registered (regs=fa1cc000, irq=52)

[   75.469300] c_can_platform 481d0000.d_can: invalid resource

[   75.475178] c_can_platform 481d0000.d_can: control memory is not used for raminit

[   75.475645] c_can_platform 481d0000.d_can: c_can_platform device registered (regs=fa1d0000, irq=55)

[   75.529164] pruss_uio 4a300000.pruss: pins are not configured from the driver

[   75.580025] RT-Socket-CAN 0.90.2 - (C) 2006 RT-Socket-CAN Development Team

[   75.648002] bone-capemgr bone_capemgr.9: part_number 'cape-bone-iio', version 'N/A'

[   75.648176] bone-capemgr bone_capemgr.9: slot #8: generic override

[   75.648194] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 8

[   75.648210] bone-capemgr bone_capemgr.9: slot #8: 'Override Board Name,00A0,Override Manuf,cape-bone-iio'

[   75.648310] bone-capemgr bone_capemgr.9: slot #8: Requesting part number/version based 'cape-bone-iio-00A0.dtbo

[   75.648325] bone-capemgr bone_capemgr.9: slot #8: Requesting firmware 'cape-bone-iio-00A0.dtbo' for board-name 'Override Board Name', version '00A0'

[   75.648346] bone-capemgr bone_capemgr.9: slot #8: dtbo 'cape-bone-iio-00A0.dtbo' loaded; converting to live tree

[   75.649467] bone-capemgr bone_capemgr.9: slot #8: #1 overlays

[   75.659714] bone-iio-helper helper.52: ready

[   75.659833] bone-capemgr bone_capemgr.9: slot #8: Applied #1 overlays.

[Jonathan Cohen]

So after a hour, the ADC froze.  I opened up a terminal window and type realtime stop, followed by realtime start which killed the instance of machinekit that was running (became completely unresponsive.  So I shut it down and started an instance of Machinekit from a terminal prompt.  After homing the printer, and setting a bed and extruder temperature, the ADC did not report any values (stayed at 0).  There was a couple of errors about DOS style characters in the config files (I dont know if that is an issue).  What I did notice was an error that "libgcc_s.so.1 is required and something else about pthread.cancel.  This was in trying to set M104 and M140.  I still had to reboot the machine in order to get it to respond again.

[Jakob kalwar]

So we just did a 2hour print and it the temp reading froze half way during the final layer... annoying!

Anyway, the reading was back after the "sudo reboot"

Here is some more log:

Dec 26 20:16:29 beaglebone msgd:0: startup pid=2900 flavor=xenomai rtlevel=1 usrlevel=1 halsize=524288 shm=Posix gcc=4.9.2 version=v0.1~-detached~0db30dc

Dec 26 20:16:29 beaglebone msgd:0: ØMQ=4.0.5 czmq=2.2.0 protobuf=2.6.1 libwebsockets=<no version symbol>

Dec 26 20:16:29 beaglebone msgd:0: configured: sha=0db30dc

Dec 26 20:16:29 beaglebone msgd:0: built:      Dec 10 2016 12:30:27 sha=0db30dc

Dec 26 20:16:29 beaglebone msgd:0: register_stuff: actual hostname as announced by avahi='beaglebone.local'

Dec 26 20:16:29 beaglebone msgd:0: zeroconf: registering: 'Log service on beaglebone.local pid 2900'

Dec 26 20:16:29 beaglebone msgd:0: rtapi_app:2906:user accepting commands at ipc:///tmp/0.rtapi.a42c8c6b-4025-4f83-ba28-dad21114744a

Dec 26 20:16:29 beaglebone msgd:0: zeroconf: registered 'Log service on beaglebone.local pid 2900' _machinekit._tcp 0 TXT "uuid=a42c8c6b-4025-4f83-ba28-dad21114744a" "instance=2f54109c-cba8-11e6-9aa6-78a504ca235b" "service=log" "dsn=ipc:///tmp/0.log.a42c8c6b-4025-4f83-ba28-dad21114744a"

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt memmapped gpio port 2 to 0xb6f40000, oe: 0xb6f40134, set: 0xb6f40194, clr: 0xb6f40190

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt pin 7 maps to pin 2-2, mode 85

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt pin 8 maps to pin 2-3, mode 85

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt pin 9 maps to pin 2-5, mode 85

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt pin 10 maps to pin 2-4, mode 85

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt memmapped gpio port 0 to 0xb558d000, oe: 0xb558d134, set: 0xb558d194, clr: 0xb558d190

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt pin 17 maps to pin 0-27, mode 85

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt pin 11 maps to pin 0-30, mode 85

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt pin 13 maps to pin 0-31, mode 85

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt memmapped gpio port 1 to 0xb558b000, oe: 0xb558b134, set: 0xb558b194, clr: 0xb558b190

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt memmapped gpio port 3 to 0xb5589000, oe: 0xb5589134, set: 0xb5589194, clr: 0xb5589190

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt prussdrv_init

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt prussdrv_open

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt prussdrv_pruintc_init

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt prussdrv_map_prumem

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt PRU data ram mapped

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt num_pwmgens : 6

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt num_stepgens: 4

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt num_encoders: 0

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt Init pwm

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt hpg_pwm_init

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt Init stepgen

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt hpg_stepgen_init

Dec 26 20:16:41 beaglebone msgd:0: hal_lib:2906:rt Init encoder

Dec 26 22:24:28 beaglebone rtapi:0: unload: 'trivkins' not loaded

Dec 26 22:24:28 beaglebone rtapi:0: unload: 'tp' not loaded

Dec 26 22:24:28 beaglebone rtapi:0: unload: 'motmod' not loaded

Dec 26 22:24:28 beaglebone rtapi:0: unload: 'hal_bb_gpio' not loaded

Dec 26 22:24:28 beaglebone rtapi:0: unload: 'hal_pru_generic' not loaded

Dec 26 22:24:28 beaglebone rtapi:0: unload: 'pid' not loaded

Dec 26 22:24:28 beaglebone rtapi:0: unload: 'limit1' not loaded

Dec 26 22:24:28 beaglebone msgd:0: rtapi_app exit detected - scheduled shutdown

Dec 26 22:24:30 beaglebone msgd:0: msgd shutting down

Dec 26 22:24:30 beaglebone msgd:0: zeroconf: unregistering 'Log service on beaglebone.local pid 2900'

Dec 26 22:24:30 beaglebone msgd:0: log buffer hwm: 0% (24 msgs, 1755 bytes out of 524288)

Dec 26 22:24:30 beaglebone msgd:0: normal shutdown - global segment detached

Dec 26 22:24:50 beaglebone msgd:0: startup pid=5435 flavor=xenomai rtlevel=1 usrlevel=1 halsize=524288 shm=Posix gcc=4.9.2 version=v0.1~-detached~0db30dc

Dec 26 22:24:50 beaglebone msgd:0: ØMQ=4.0.5 czmq=2.2.0 protobuf=2.6.1 libwebsockets=<no version symbol>

Dec 26 22:24:50 beaglebone msgd:0: configured: sha=0db30dc

Dec 26 22:24:50 beaglebone msgd:0: built:      Dec 10 2016 12:30:27 sha=0db30dc

Dec 26 22:24:50 beaglebone msgd:0: register_stuff: actual hostname as announced by avahi='beaglebone.local'

Dec 26 22:24:50 beaglebone msgd:0: zeroconf: registering: 'Log service on beaglebone.local pid 5435'

Dec 26 22:24:50 beaglebone msgd:0: rtapi_app:5440:user accepting commands at ipc:///tmp/0.rtapi.a42c8c6b-4025-4f83-ba28-dad21114744a

Dec 26 22:24:51 beaglebone msgd:0: zeroconf: registered 'Log service on beaglebone.local pid 5435' _machinekit._tcp 0 TXT "uuid=a42c8c6b-4025-4f83-ba28-dad21114744a" "instance=1d9b13a2-cbba-11e6-9aa6-78a504ca235b" "service=log" "dsn=ipc:///tmp/0.log.a42c8c6b-4025-4f83-ba28-dad21114744a"

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt memmapped gpio port 2 to 0xb6f32000, oe: 0xb6f32134, set: 0xb6f32194, clr: 0xb6f32190

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt pin 7 maps to pin 2-2, mode 85

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt pin 8 maps to pin 2-3, mode 85

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt pin 9 maps to pin 2-5, mode 85

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt pin 10 maps to pin 2-4, mode 85

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt memmapped gpio port 0 to 0xb557f000, oe: 0xb557f134, set: 0xb557f194, clr: 0xb557f190

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt pin 17 maps to pin 0-27, mode 85

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt pin 11 maps to pin 0-30, mode 85

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt pin 13 maps to pin 0-31, mode 85

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt memmapped gpio port 1 to 0xb557d000, oe: 0xb557d134, set: 0xb557d194, clr: 0xb557d190

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt memmapped gpio port 3 to 0xb557b000, oe: 0xb557b134, set: 0xb557b194, clr: 0xb557b190

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt prussdrv_init

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt prussdrv_open

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt prussdrv_pruintc_init

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt prussdrv_map_prumem

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt PRU data ram mapped

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt num_pwmgens : 6

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt num_stepgens: 4

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt num_encoders: 0

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt Init pwm

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt hpg_pwm_init

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt Init stepgen

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt hpg_stepgen_init

Dec 26 22:24:58 beaglebone msgd:0: hal_lib:5440:rt Init encoder

Dec 26 22:27:11 beaglebone rtapi:0: unload: 'trivkins' not loaded

Dec 26 22:27:11 beaglebone rtapi:0: unload: 'tp' not loaded

Dec 26 22:27:11 beaglebone rtapi:0: unload: 'motmod' not loaded

Dec 26 22:27:11 beaglebone rtapi:0: unload: 'hal_bb_gpio' not loaded

Dec 26 22:27:11 beaglebone rtapi:0: unload: 'hal_pru_generic' not loaded

Dec 26 22:27:11 beaglebone rtapi:0: unload: 'pid' not loaded

Dec 26 22:27:11 beaglebone rtapi:0: unload: 'limit1' not loaded

Dec 26 22:27:11 beaglebone msgd:0: rtapi_app exit detected - scheduled shutdown

Dec 26 22:27:13 beaglebone msgd:0: msgd shutting down

Dec 26 22:27:13 beaglebone msgd:0: zeroconf: unregistering 'Log service on beaglebone.local pid 5435'

Dec 26 22:27:13 beaglebone msgd:0: log buffer hwm: 0% (24 msgs, 1755 bytes out of 524288)

Dec 26 22:27:13 beaglebone msgd:0: normal shutdown - global segment detached

Dec 26 22:27:52 beaglebone msgd:0: startup pid=6960 flavor=xenomai rtlevel=1 usrlevel=1 halsize=524288 shm=Posix gcc=4.9.2 version=v0.1~-detached~0db30dc

Dec 26 22:27:52 beaglebone msgd:0: ØMQ=4.0.5 czmq=2.2.0 protobuf=2.6.1 libwebsockets=<no version symbol>

Dec 26 22:27:52 beaglebone msgd:0: configured: sha=0db30dc

Dec 26 22:27:52 beaglebone msgd:0: built:      Dec 10 2016 12:30:27 sha=0db30dc

Dec 26 22:27:52 beaglebone msgd:0: register_stuff: actual hostname as announced by avahi='beaglebone.local'

Dec 26 22:27:52 beaglebone msgd:0: zeroconf: registering: 'Log service on beaglebone.local pid 6960'

Dec 26 22:27:52 beaglebone msgd:0: rtapi_app:6965:user accepting commands at ipc:///tmp/0.rtapi.a42c8c6b-4025-4f83-ba28-dad21114744a

Dec 26 22:27:53 beaglebone msgd:0: zeroconf: registered 'Log service on beaglebone.local pid 6960' _machinekit._tcp 0 TXT "uuid=a42c8c6b-4025-4f83-ba28-dad21114744a" "instance=8a4da1a4-cbba-11e6-9aa6-78a504ca235b" "service=log" "dsn=ipc:///tmp/0.log.a42c8c6b-4025-4f83-ba28-dad21114744a"

Dec 26 22:28:08 beaglebone rtapi:0: rtapi_app_main(hal_lib): -22 Invalid argument

Dec 26 22:28:08 beaglebone msgd:0: hal_lib:7380:rt hal_xinit:171 HAL error: duplicate component name 'hal_lib'

Dec 26 22:28:08 beaglebone msgd:0: rtapi_app:7380:user init_actions() failed

Dec 26 22:28:08 beaglebone msgd:0: rtapi_app exit detected - scheduled shutdown

Dec 26 22:28:10 beaglebone msgd:0: msgd shutting down

Dec 26 22:28:10 beaglebone msgd:0: zeroconf: unregistering 'Log service on beaglebone.local pid 6960'

Dec 26 22:28:10 beaglebone msgd:0: log buffer hwm: 0% (2 msgs, 163 bytes out of 524288)

Dec 26 22:28:10 beaglebone msgd:0: normal shutdown - global segment detached

Dec 26 22:28:11 beaglebone rtapi:0: rtapi_msgd went away, exiting

[Charles Steinkuehler]

On 12/26/2016 4:39 PM, 'Jakob kalwar' via Machinekit wrote:
> So we just did a 2hour print and it the temp reading froze half way during the
> final layer... annoying!

Very!

> Anyway, the reading was back after the "sudo reboot"

Thanks for the report! What kernel are you running?

I'm still waiting for mine to die again. :-/

If a warm reboot restored proper operation, that at least pretty much
rules out any sort of physical problem (like voltage spikes or
something "wedging" the ADC logic somehow). Once my system dies again
I will see if any of the other ADC channels work, if the kernel module
can be unloaded/reloaded, etc. If anyone else has time (and a system
that has locked up) feel free to poke around the ADC sysfs file
entries and see if you can provide any more details about what is and
isn't working:

http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide

--
Charles Steinkuehler
cha...@steinkuehler.net

[Jonathan Cohen]

Out of curiosity, I have been having the most immediate problems printing with PETG where I keep the bed at 85C.  I was having less problems printing with ABS where I set the bed to 110C.  At that temp, the bed is generally continuously heating (my printer is in the basement).  Does that affect the interaction between the tho analog inputs in any way, e.g. the bed heater would be turning on and off more ?  

[David Kalwar]

Charles,

thanks for helping to investigate this issue! We are not too familiar with machinekit or linux. We can help more but would need very specific command line commands or something that you want us to execute and watch. We have started machinekit through the shell but after the initialization, nothing more was posted in the shell. I dont know how to see what the hal_temp_bbb script does...

I should add that we use a 10k thermistor for the heatbed (instead of the regular 100k) and i have added a .txt file with the thermistor table to the folder with the others and it works well - but it may be the source of the issue?

[Daren Schwenke]

I've been running the following older debian 7 image for many months, with many 6+ hour prints, and zero lockups (knock on wood).

Not sure what version of this image this was, but here are some file dates:

machinekit@beaglebone:/etc$ uname -a
Linux beaglebone 3.8.13-xenomai-r78 #1 Sat Sep 26 16:54:43 UTC 2015 armv7l GNU/Linux
machinekit@beaglebone:/etc$ ls -al /usr/bin/linuxcnc
-rwxr-xr-x 1 root root 24129 Mar 16  2016 /usr/bin/linuxcnc
machinekit@beaglebone:/usr/bin$ ls -al /usr/bin/hal_temp_bbb
-rwxr-xr-x 1 root root 9567 Mar 16  2016 /usr/bin/hal_temp_bbb

I had experienced lockups in other versions, but my hardware has also changed since then with better shielding and smoother power to the BBB.

haltalk (using Machineface) in that build can consume 30% proc at times, and this seems to cause random blobbies in the prints.

The effect is worse at high segment speeds (160mm/sec, all arcs).  Disconnecting mostly eliminates them and the print continues, so that's what I do.  It works so I'm not messing with it.

[Daren Schwenke]

Better info:

machinekit@beaglebone:/usr/bin$ dpkg -l machinekit* 

ii  machinekit     0.1.14581376 armhf        PC based motion controller for re

machinekit@beaglebone:/usr/bin$ cat /etc/dogtag 

Machinekit Debian Image 2016-02-07

[Jonathan Cohen]

Do you suppose that the older Debian distribution is more stable than 8.6 ?  Or the previous kernel ?  Specifically, what kind of shielding do you have on your cabling ?  I switched from the older version since I would get lockups after very long prints but with this setup, it's only an hour to two hours in and it fails.  I was tempted to perfom a mock print, e.g. no filament, setting the extruder to 0 and the HBP to 35 and give it a whirl.  Then try the extruder at 36 and the HBP at 0 to see if a crash occurs.  This would be to see if a specific ADC channel is giving grief.  Is there any possibility of oxidation occurring at the BBB analog in pins ?  I haven't tried using a different channel.  

[Jonathan Cohen]

So here is a silly question...

In the file, hal_temp_bbb.py there is a syspath file path for the TI ADC, " syspath = '/sys/devices/ocp.*/44e0d000.tscadc/tiadc/iio:device0/' " 

Going from Wheezy to Jessie, the location has changes from /sys/devices/ocp.*/helper.*/AIN* to /sys/bus/iio/devices/iio:device0

Was this updated in the Jessie build ?  

Maybe it's a naive question, in that if it was built on Jessie, the path would be correct ?  

I suppose I will check it in the evening...

> <mailto:machinekit+unsub...@googlegroups.com>.

[Robert Nelson]

On Wed, Dec 28, 2016 at 9:59 AM, Jonathan Cohen <electr...@gmail.com> wrote:
> So here is a silly question...
>
> In the file, hal_temp_bbb.py there is a syspath file path for the TI ADC, "
> syspath = '/sys/devices/ocp.*/44e0d000.tscadc/tiadc/iio:device0/' "
>
> Going from Wheezy to Jessie, the location has changes from
> /sys/devices/ocp.*/helper.*/AIN* to /sys/bus/iio/devices/iio:device0
>
> Was this updated in the Jessie build ?
>
> Maybe it's a naive question, in that if it was built on Jessie, the path
> would be correct ?

It's not related to Jessie..

It's just 3.8.13 vs 4.1.x+

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Jakob kalwar]

We are running:

- machinekit V 0.1.14813708 armhf

- Machinekit Debian Image 2016-12-18

- Linux beaglebone 3.8.13-xenomai-r81 Fri Oct 14 2016

[Daren Schwenke]

I don't suppose either way.  I'm just adding my data points to the conversation in hopes it might add as mine were different.  :)

If easy, I would load that version and see if it makes a difference (with the caveats I've mentioned).  Could just be luck, but my luck has run out much more quickly before.

I tried to go to 8, but tried it on a BBGW which didn't work at all (the image won't boot) and I haven't had the time to figure it out.

[Daren Schwenke]

Oh.. I also went from using a 10k thermistor with a custom file to a standard 3950-100k thermistor.

Just to add to the confusion..  

[Robert Nelson]

On Wed, Dec 28, 2016 at 11:57 AM, Daren Schwenke
<darens...@gmail.com> wrote:
> I don't suppose either way. I'm just adding my data points to the
> conversation in hopes it might add as mine were different. :)
> If easy, I would load that version and see if it makes a difference (with
> the caveats I've mentioned). Could just be luck, but my luck has run out
> much more quickly before.
>
> I tried to go to 8, but tried it on a BBGW which didn't work at all (the
> image won't boot) and I haven't had the time to figure it out.

BBGW, BBBW, BB Blue haven't been back-ported to the 3.8.13-bone tree..
(wl18xx driver is the worst part of that)

SO just use:

BBGW:

dtb=am335x-bonegreen.dtb

BBBW:

dtb=am335x-boneblack.dtb

[Robert Nelson]

I've added a patch so users won't have to do this..

https://github.com/RobertCNelson/bb-kernel/commit/6d969f205926d7329c7bfe277854812bd9d8d5bc

(no wl18xx wireless, but at-least the boards will bootup)

[David Kalwar]

So our system locked up again. When we follow http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver%27s_Guide

We get:

Code hier eingeb

machinekit@beaglebone:~# ls -al /sys/bus/iio/devices/iio:device0/
drwxr-xr-x    5 root     root            0 Jan  1 00:00 .
drwxr-xr-x    4 root     root            0 Jan  1 00:00 ..
-r--r--r--    1 root     root         4096 Jan  1 00:00 dev
-r--r--r--    1 root     root         4096 Jan  1 00:00 in_voltage0_raw
-r--r--r--    1 root     root         4096 Jan  1 00:00 in_voltage1_raw
-r--r--r--    1 root     root         4096 Jan  1 00:00 in_voltage2_raw
-r--r--r--    1 root     root         4096 Jan  1 00:00 in_voltage3_raw
-r--r--r--    1 root     root         4096 Jan  1 00:00 in_voltage4_raw
-r--r--r--    1 root     root         4096 Jan  1 00:00 in_voltage5_raw
-r--r--r--    1 root     root         4096 Jan  1 00:00 in_voltage6_raw
-r--r--r--    1 root     root         4096 Jan  1 00:00 in_voltage7_raw
-r--r--r--    1 root     root         4096 Jan  1 00:00 name
drwxr-xr-x    2 root     root            0 Jan  1 00:00 power
lrwxrwxrwx    1 root     root            0 Jan  1 00:00 subsystem -> ../../../../../../bus/iio
-rw-r--r--    1 root     root         4096 Jan  1 00:00 uevent

en...

So the lines "buffer", "mode" and "scan_elements" are missing.

So trying to read a oneshot value gives:

machinekit@beaglebone:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw
Resource temporarily unavailable

After a "sudo reboot", the "iio:device0" was missing, it came back only after starting machinekit.
Now the "in_voltageX_raw" shows the values.

Really hope this helps!

[Charles Steinkuehler]

Sorry for being away from this thread for so long, I'm doing
"real-world" work away from the computer over the holiday break
(tiling a floor!) so I only get to check email a couple times a day.

On 12/28/2016 3:51 PM, David Kalwar wrote:
>
> So the lines "buffer", "mode" and "scan_elements" are missing.

These are missing on my system when the ADC is working normally, I
think they are from a newer version of the ADC driver. Can you verify
the files are also missing on your system when the ADC is working
correctly?

> So trying to read a oneshot value gives:
>
> machinekit@beaglebone:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw
> Resource temporarily unavailable

OK, so that means the kernel driver isn't responding to the sysfs
request. This is what used to happen with the ADC driver, but it
would only fail for an individual sample, then go back to normal
operation. It now seems to no longer recover. :(

> After a "sudo reboot", the "iio:device0" was missing, it came back only after
> starting machinekit.

That is expected. The ADC driver isn't loaded until you load the iio
cape overlay, typically done in the setup.sh script of your machine
configuration.

> Now the "in_voltageX_raw" shows the values.
>
> Really hope this helps!

It's looking like a kernel driver problem. Anyone want to debug the
kernel driver, try back-porting the latest driver from 4.x, or make a
4.x kernel patched with Xenomai? All three options should be
possible, but I'm not sure which is easiest or best.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Charles Steinkuehler]

On 12/28/2016 9:59 AM, Jonathan Cohen wrote:
>
> Maybe it's a naive question, in that if it was built on Jessie, the path would
> be correct ?
>
> I suppose I will check it in the evening...

It's not a Wheezy/Jessie difference, but a difference in the kernel
(or more specifically a change in the AM335x ADC driver). If you are
using a 3.8.13 Xenomai kernel '/sys/devices/ocp.*/44e0d000.tscadc'
should be present and working.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Charles Steinkuehler]

On 12/27/2016 10:03 AM, Jonathan Cohen wrote:
> Out of curiosity, I have been having the most immediate problems printing with
> PETG where I keep the bed at 85C. I was having less problems printing with ABS
> where I set the bed to 110C. At that temp, the bed is generally continuously
> heating (my printer is in the basement). Does that affect the interaction
> between the tho analog inputs in any way, e.g. the bed heater would be turning
> on and off more ?

It shouldn't, but then the ADC shouldn't just stop working either.

The ADC kernel driver appears to have a bug where it can die and stop
responding to /sysfs reads. At this point, it is unclear exactly what
is triggering the bug, so collecting as much data as possible is helpful.

I have typically run my systems for several weeks without issue, but
most of the time is spent idle (the machine power is off, steppers are
disabled, and the 3D printer is "parked" at a known XYZ location). I
think there may be some sort of interaction with either the commanded
temperature value or the specific range of values being read by the
ADC that 'tickles' this particular bug.

Regardless, the hal_temp_bbb component outputs error and no-error
pins. Given the issues people are seeing, I highly recommend wiring
these signals to the pwmgen.enable pins so if the ADC *DOES* stop
responding at least the extruder and bed heaters will turn off
(potentially keeping your printer from catching on fire!).

--
Charles Steinkuehler
cha...@steinkuehler.net

[Daren Schwenke]

I had assumed the buggy ADC kernel driver was a known issue..

There is PRU based ADC reading in the following project if someone has the initiative to digest it and move the ADC code out of userspace.
I took a look and it is beyond me for the time being.
http://beagleboard.org/project/libpruio/

[Charles Steinkuehler]

On 12/29/2016 1:39 AM, Daren Schwenke wrote:
> I had assumed the buggy ADC kernel driver was a known issue..

Yes and no. The kernel ADC driver has had problems for a long time,
but it hasn't previously just died. The buggy behavior I experienced
when first working with the BBB was limited to occasional failed
samples (resource busy), which don't really matter much with a slowly
changing signal like a temperature reading. The ADC driver completely
locking up is something new.

> There is PRU based ADC reading in the following project if someone has the initiative to digest it and move the ADC code out of userspace.
> I took a look and it is beyond me for the time being.
> http://beagleboard.org/project/libpruio/

Hmm...that would be another option.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Jonathan Cohen]

So is there some sort of consensus that 3.8 is a better bet in terms of stability than the most current iteration ?

[Charles Steinkuehler]

On 12/29/2016 7:41 AM, Jonathan Cohen wrote:
> So is there some sort of consensus that 3.8 is a better bet in terms of
> stability than the most current iteration ?

Not really. 3.8.13 is the kernel version with Xenomai patches, which
are required for hard real-time performance. There are now Xenomai
patches for some 4.x version ARM kernels, if some adventuresome soul
cares to try and make this work. :-)

--
Charles Steinkuehler
cha...@steinkuehler.net

[Robert Nelson]

On Thu, Dec 29, 2016 at 8:40 AM, Charles Steinkuehler
<cha...@steinkuehler.net> wrote:
> On 12/29/2016 7:41 AM, Jonathan Cohen wrote:
>> So is there some sort of consensus that 3.8 is a better bet in terms of
>> stability than the most current iteration ?
>
> Not really. 3.8.13 is the kernel version with Xenomai patches, which
> are required for hard real-time performance. There are now Xenomai
> patches for some 4.x version ARM kernels, if some adventuresome soul
> cares to try and make this work. :-)

You should checkout this.. ;)

cd /opt/scripts/tools/
git pull
sudo ./update_kernel.sh --ti-xenomai-channel --lts-4_4

[Charles Steinkuehler]

On 12/29/2016 9:12 AM, Robert Nelson wrote:
> On Thu, Dec 29, 2016 at 8:40 AM, Charles Steinkuehler
>>

>> There are now Xenomai patches for some 4.x version ARM kernels,
>> if some adventuresome soul cares to try and make this work. :-)
>
> You should checkout this.. ;)
>
> cd /opt/scripts/tools/ git pull sudo ./update_kernel.sh
> --ti-xenomai-channel --lts-4_4

Is that kernel expected to work with the uio PRU driver? I can get
the ADC and universal cape to load, but not uio_pruss.

I've blacklisted the remoteproc modules and cape manager claims to
load the uio_pruss_enable overlay, but I don't get any uio device
entries and the uio_pruss module isn't getting loaded. :(

--
Charles Steinkuehler
cha...@steinkuehler.net

[Robert Nelson]

That's right, you guys need uio_pruss. ;)

Right now it's just a copy of the ti/rt-ti which has you select one
(uio_pruss/remoteproc_pruss)

I'll enable this section for the xenomai image for you guys.

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack-emmc-overlay.dts#L24-L32

[Daren Schwenke]

I wasn't actually suggesting to use the library, although I suppose that would work too.

I (personally) was just trying to deconstruct the PRU ADC bits to generate something like what Charles has created in hal_pru_generic/pru_generic.bin.  We have a completely unused PRU currently, so I wouldn't even need to be remotely efficient.  :)

This isn't the first time I've attempted to take this path as I *really* liked the idea of moving this out of it's currently un-reliable home in user-space.  Having something critical to safety like temperature regulation taking a round trip through the operating system when it doesn't have to just bothered me.  

But just as in the past, my eyes soon glazed over while trying to follow what is probably simple stuff to our many more experienced contributors.  Perhaps given a month and a lot of trial and error I could come close.

[Robert Nelson]

Prepping this for you guys:

https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/12c730ec71487c2533d9bfd33f13cfb30ec4ae68

build should be available tomorrow.

[Charles Steinkuehler]

On 12/30/2016 10:26 AM, Robert Nelson wrote:
>
> Prepping this for you guys:
>
> https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/12c730ec71487c2533d9bfd33f13cfb30ec4ae68
>
> build should be available tomorrow.

Thanks Robert!

That's at least another beer I owe you. If you keep this up I'll have
to switch the tally to floating-point! ;-)

--
Charles Steinkuehler
cha...@steinkuehler.net

[David Kalwar]

Hello everyone,

we are happy to hear that this is being worked on. Is this already available for a test? And if yes, how can we test it?

Thanks
David

[Daren Schwenke]

This is probably the image of the build he was mentioning.  Not sure this addresses the issue yet, but it's a step in the right direction.

https://rcn-ee.com/rootfs/bb.org/testing/2017-01-01/machinekit/

[Charles Steinkuehler]

I think those are just the usual images. Anyone interested in testing
would need to start with one of the Jessie images, add the 4.4
ti-xenomai kernel with uio-pruss support (the bit that Robert recently
crafted for us), and modify the setup.sh scripts to work with the new
overlay names and cape-manager sysfs location.

> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to machinekit+...@googlegroups.com

> <mailto:machinekit+...@googlegroups.com>.

[Jonathan Cohen]

So, is it safe to go with the bone-debian-8.6-machinekit-armhf-2017-01-01-4gb.img.xz image for a test run ? Rather than the 7.11 ?

[Charles Steinkuehler]

On 1/2/2017 4:20 PM, Jonathan Cohen wrote:
> So, is it safe to go with the
> bone-debian-8.6-machinekit-armhf-2017-01-01-4gb.img.xz image for a test run ?
> Rather than the 7.11 ?

I have been using Jessie (8.x) based Machinekit images for some time
(most of 2016) and consider the Wheezy (7.x) images pretty much
deprecated.

The image 2017-01-01 Jessie image should still contain a 3.8.13
Xenomai kernel and ought to work fine (or as well as any other image)
unless RCN unexpectedly replaced the kernel with 4.4 in which case
lots of things will break and you will probably not be able to even
launch a machine configuration. :)

--
Charles Steinkuehler
cha...@steinkuehler.net

[Robert Nelson]

On Mon, Jan 2, 2017 at 4:26 PM, Charles Steinkuehler
<cha...@steinkuehler.net> wrote:
> On 1/2/2017 4:20 PM, Jonathan Cohen wrote:
>> So, is it safe to go with the
>> bone-debian-8.6-machinekit-armhf-2017-01-01-4gb.img.xz image for a test run ?
>> Rather than the 7.11 ?
>
> I have been using Jessie (8.x) based Machinekit images for some time
> (most of 2016) and consider the Wheezy (7.x) images pretty much
> deprecated.

last week i actually updated the wheezy image so it would atleast
build.. (nodejs v0.10.x removal)

> The image 2017-01-01 Jessie image should still contain a 3.8.13
> Xenomai kernel and ought to work fine (or as well as any other image)
> unless RCN unexpectedly replaced the kernel with 4.4 in which case
> lots of things will break and you will probably not be able to even
> launch a machine configuration. :)

Nope it's still 3.8.13-xenomai based.. You guys let me know when your
ready to switch it. ;)

[David Kalwar]

Hello again,

we have seen there is a new image available on http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.2FBBB_.28All_Revs.29_Machinekit

Does this already include your changes?
The posts are a bit confusing, we are not sure what else is necessary (which kernel etc) to work towards a solution of the problem.
Sadly our programming skills and knowledge of machinekit software are quite limited so we really need some help.
Maybe someone could point out a step-by-step guide which steps are necessary to perform.
We guess it is also necessary to change the *.ini and/or hal_temp_bbb to access the PRU?

Please excuse all the stupid questions, but we would really like to solve this so we can play with the machine.

[Daren Schwenke]

I'm confused as well, but here is what I know.

The 'moving this to the PRU' bit was my wish/plan and not sure if this would help with that or not.  It's also not a straightforward endeavor as you code for the PRU in one language, the kernel in another.  Basically you really need to know what you are doing (like the original creator of the current BBB PRU code for stepgen/PWM - Charles S.).  The advantage would be the PRU code is self contained and if done correctly could be safer. (the OS could go away entirely, and the PRU could cut power without it)

Fixing the current issue without using the PRU would be perfectly acceptable as well for 99% of the population, but the issue seems to be outside of Machinekit in the kernel implementation for the ADC.  The current python based code is accessing the ADC via the kernel abstraction into unix 'files'.

The code referenced by Robert I believe works towards fixing the kernel abstraction, but it seems would also be a step towards a simpler PRU based ADC implementation as PRU based ADC is part of the uio_pruss library.

Problem being the kernel version referenced in his commit is not something which Machinekit currently runs on, so I'm waiting in the wings for clarification.

[Marco Negrini]

Hi all,

I started reading this due to the famous adc issue,

i can add that this happens to me on any clean installation (i tried a 7 and 8.6 and 8.7) (giving always a call to apt-get upgrade), only and every time i try to CALL an M command to wait bed or extruder to reach temperature, it happens usually during the second print, that is more or less after 30 hrs of printing.

someone talked about http://beagleboard.org/project/libpruio/, then Robert talked about an image update,

I did not understand if the update is already on, and if it should resolve the adc problem...

[Jonathan Cohen]

I am going to put it out there that I am testing a Replicape board right now and was getting the exact same ADC issues as before with the CRAMPS board - so I swapped out the Beaglebone with no success- it would cut out anywhere from a few minutes to a little over an hour.  Someone floated the idea that maybe I should increase the voltage of the supply.  I went and bumped up the voltage of my 12V 360 Watt  "LED" power supply to 12.4 volts and was able to successfully print several moderate-length prints (8 hours) without a reboot. I am not superstitious, but I still have my fingers crossed.  I still do not understand why this would happen unless there is an ever slight dip in voltage that I did not happen to see. A long while ago I was using a separate 5V supply to directly power the BBB but the adapter never fit in really well so I changed the wiring, using a 5V step down, coming off the 12V supply.  I need to test the BBB/CRAMPS again with slightly higher mains to see if the problem is solved.        
It would suspect that it is user-error on my part -but- my assumption was 12V is 12V (not thinking that most PS are never really 12V !  That said, the CRAMPS can handle up to 24V I believe so who knows...

[Daren Schwenke]

I have a new data point for you all.

Broke the wires going to my thermistor today, and silly me starts to swap it out with the machine on.

No ADC lockups for at least the last 9 months.

Swapped out the themistor, go to check what it's reading, frozen ADC.

So perhaps somehow a value at the open circuit (probably tied to ground at that point) range contributes to this.

Like if you have a heated bed configured, but not hooked up, then you get freezes?

On Tuesday, December 20, 2016 at 9:40:39 AM UTC-5, Jonathan Cohen wrote:

I took my printer down since the hot end was locking up during a long print.  I have posted about this over the past year.  I recently purchased a new microsd card, put on a new image of Jessie 8.6.  I also replaced the hotend thermistor, redid all of the wiring to decrease the effect of EMI near the cartridge heater leads.  I got off one reasonable 4hr test print.  However, on an overnight, the ADC locked up at maybe the 5 hr mark on a 6.5 hr print (not heating).  So,  I recall Charles writing about the ADC driver being a bit temperamental, sensitive to over-voltage and such.  I am powering the beaglebone through the AUX in on the CRAMPS board through a 5V LM2596 buck regulator (https://www.amazon.com/gp/product/B00WEBJRE8/ref=oh_aui_search_detailpage?ie=UTF8&psc=1).  I recently went a made sure that it was set to 5V to be sure.  Prior to that I was using a 5V DC adapter where I still had this issue. My cable management is reasonable so I do not think wires are moving about. 

1. So what I want to know is whether this is a particular problem that is always going to be sporadic during a print ? 

2. Is there no straightforward solution ?  I tried several microSD cards, thinking it was a quality issue or corruption of the card but that did not fix it. I also though my thermistor may have been bad, or the wiring out both so I swapped that out, to no avail. 

3.  There was mention of a buggy ADC driver in an older kernel.  Has this same driver been brought along to the new Debian release /

4. I did see in the forums about using an external ADC, is this possible to implement on the CRAMPS (I am not sure if the SPI is broken out).  

5. Is this an issue that everyone who uses the Beaglebone/CRAMPS combo, sees ?

6. I slice in Cura, is this a G-code problem ? ( I am not using the remapped G-codes0

7. 5.  Does this occur with the Replicape board ?

8.  Is it time to throw in the towel ?

I really like the using an embedded platform for running a printer.  This is a bit frustrating as I can not figure it out.  Everyone on this board has been really helpful.  I have scoured the board looking for solutions, but am still at a loss (probably since I am not a programmer or engineer !)  

Thanks,

Jonathan

[Brian Schousek]

That almost feels like a problem with the input circuit on the Beagle itself. Like perhaps some latch-up condition (see wiki.) If I had a Beagle Board my debugging steps might include trying to duplicate the behavior by intentionally disconnecting the thermistor while monitoring the ADC. If this is a repeatable cause then that is wonderful news because you can then go about finding the root cause.

If the behavior is repeatable, try looking at the schematic or measuring with a voltmeter to see what the voltage on the ADC pin is with the thermistor removed. It might be that this voltage exceeds the ADC input rating. In that case you might need some protection clamps (link)

[Brian Schousek]

So I just looked at the CRAMPS schematic and if that is what you are using, then it looks like the voltage driving the thermistor is the Vref from the Beagleboard which I think is 1.8 volts. As an EE, I have never aesthetically cared for the large 10 uF capacitor helping to filter the thermistor inputs. I could still see a latchup condition being triggered by intermittent thermistor connections, or perhaps some ground bounce by the same.

[Daren Schwenke]

Tried to reproduce this without success.  Unplugged, plugged in the thermistor a dozen times or so.

Noticed it drops to -26C while unplugged, which triggers the PID to turn on, even at 'off' setpoint in Machineface which logically sets the target temperature to 0C.

So when I plugged it back in I was reading 180C just from my efforts.  

Easy fix for that is just modifying the thermistor table so 1C is the lowest it can read: so 'off' doesn't ever trigger heating when the thermistor goes away..

When mine locked up before, it was reading about 6C (and it wasn't cold here) so it must have locked up during the rapid transition down, or back to 'normal'.

[Jonathan Cohen]

So I had found that the same bugs that I was getting with ADC lockups were occurring with a Replicape on another BBB.  I increased the output of my power supply (360W Amazon special) to 12.4 volts and the problems have so far seemed to go away (12 successful prints).  I have to test with the CRAMPS/BBB to see if it is the same case.  So throwing it out there,  what is the most popular way that CRAMPS users power their printers ?

[Charles Steinkuehler]

On 5/16/2017 2:56 PM, Jonathan Cohen wrote:
> So I had found that the same bugs that I was getting with ADC lockups were
> occurring with a Replicape on another BBB. I increased the output of my power
> supply (360W Amazon special) to 12.4 volts and the problems have so far seemed
> to go away (12 successful prints). I have to test with the CRAMPS/BBB to see if
> it is the same case. So throwing it out there, what is the most popular way
> that CRAMPS users power their printers ?

I typically use 5VSB from an ATX power supply to power the BBB. I
have the CRAMPS setup to turn the ATX supply on/off under program
control, and drive the printer with the 12V rail from the ATX.

This requires a supply that works properly with no load, but most of
the newer supplies work fine. Older ATX supplies that list a minimum
required load on the 5V and/or 12V lines should be avoided (or you
should make sure the minimum load requirement is met).

I also have several systems that use 5V 2A switching regulators (of
various make), and two systems using BeBoPr boards with on-board 5V
power (one from 12V and one from 24V motor power input).

--
Charles Steinkuehler
cha...@steinkuehler.net

[Daren Schwenke]

I've used:

ATX Vsb,

12v 2A USB car charger

Dedicated switching regulator from my Vmot supply at 12v 360W

Dedicated switching regulator from my Vmot supply at 24v 360W turned down to 19v to keep my DRV8825's happier with my low impedance steppers

I believe I did get more lockups on the ATX Vsb, but that was literally years ago, and I never did check if it was working properly without load as I didn't know about that...  :)

The rest have all worked fine, although I've always added at least a 1000uf buss cap on the 5V input to the CRAMPS board.
I also have another ~20000uf of buss caps distributed, as my BLDC motor driver can brownout the Vmot power rail otherwise.