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
ne
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/
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
a
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.
--
website: http://www.machinekit.io blog: http://b
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 init
On 12/26/2016 2:54 AM, David Kalwar wrote:
> 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.
Si
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.
On Monday, December 26, 2016 at 12:24:00 PM UTC-5, Charles Steinkuehler
wrote:
>
> I may have
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 informati
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
hom
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 g
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
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
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 initializat
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
On Wed, Dec 28, 2016 at 9:59 AM, Jonathan Cohen 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 fr
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
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github:
https://github.com/machinekit
---
You received this message because you are s
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
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
>
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/
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 occ
So is there some sort of consensus that 3.8 is a better bet in terms of
stability than the most current iteration ?
On Wednesday, December 28, 2016 at 8:26:32 PM UTC-5, Charles Steinkuehler
wrote:
>
> On 12/28/2016 9:59 AM, Jonathan Cohen wrote:
> >
> > Maybe it's a naive question, in that if
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 Xe
On Thu, Dec 29, 2016 at 8:40 AM, Charles Steinkuehler
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,
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/tool
On Thu, Dec 29, 2016 at 7:20 PM, Charles Steinkuehler
wrote:
> 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
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
On Thu, Dec 29, 2016 at 8:23 PM, Robert Nelson wrote:
> On Thu, Dec 29, 2016 at 7:20 PM, Charles Steinkuehler
> wrote:
>> 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,
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
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
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github:
https://github.com/machinekit
---
You received this message becau
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/
On Monday, January 2, 2017 at 2:19:26 PM UTC-5, David Kalwar wrote:
>
> Hello everyone,
>
> we
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-m
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 ?
On Monday, January 2, 2017 at 2:25:15 PM UTC-5, Daren Schwenke wrote:
>
> This is probably the image of the build he was mentioning. Not sure this
> addresses the i
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) im
On Mon, Jan 2, 2017 at 4:26 PM, Charles Steinkuehler
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 i
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
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
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 happen
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
i
38 matches
Mail list logo
