This looks like it is going to happen, probably in the next few months.
I know I've read of specific issues related to overlays where it becomes
necessary to define the board manually, but I'm not sure if this is still
the case.
The plan is of course to use the PRU for step/PWM like it is done f
I had issues with retraction that sound like this, but mine was built as a
linear delta so I just disabled retraction and turned rapids up to
500mm/sec which solved it 95%. I haven't returned to it, but I probably
should now.
I will take a look later.
On Monday, June 3, 2019 at 8:26:24 AM UTC-
The DRV8825 drivers have issues with larger drive voltages when coupled
with low inductance motors, probably like your Nema 23 ones.
This shows when trying to do microstepping. High voltage and low
inductance causes a biasing toward the full step positions, which leads to
some 'banding' showing
Thank you for the work here. I'm about to venture down this rabbit hole
myself and this is useful stuff.
On Tuesday, May 21, 2019 at 3:24:44 PM UTC-4, mlampert wrote:
>
> wow - that was quick. I'll have to setup my box for compiling mk,
> haven't done that yet.
>
> For the record, if nobody no
If other pins exist in that location and others are writeable but this one
isn't, this means that pin has been claimed by some other device already.
Like if you try to use HDMI pins, but don't disable HDMI first... you'll
get what you got.
The other scenario is you are using the wrong build and
I was able to easily exceed the max physical hardware step rate for a
DRV8825, which is 250kHz, on 9 channels simultaneously, using a
BBB/BBG/BBGW.
PRU based stepping is pretty darn fast.
The maximum it can do would be based on the internal path it takes
(crossing PRU boundaries), the rate you c
You need to start a bit further up.
https://www.youtube.com/watch?v=sYwr0HMudRg
On Thursday, April 4, 2019 at 9:57:29 AM UTC-4, Daren Schwenke wrote:
>
> It's ok, but starting where you are starting from may take you a while. :)
> The error tells you the file and line numbe
It's ok, but starting where you are starting from may take you a while. :)
The error tells you the file and line number in that file: PocketNC.hal:10:
The log also tells you where it was starting from:
/home/machinekit/machinekit/configs/ARM.BeagleBone.PocketNC-1
>From there find that file in a
Looking at* nothing* else, these are not the same location. It looks like
the hal you picked is hard coded to use that path.
Machine configuration directory is '
*/home/machinekit/machinekit/configs/ARM.BeagleBone.PocketNC-1'*
PocketNC.hal:10: execv(
*/home/machinekit/machinekit-dev/configs/ARM/
can implement HALTALK stack on it and have the actual
> Machinekit-HAL running on something else (BBB for example).
>
> Cern.
>
> Dne středa 20. března 2019 3:57:18 UTC+1 Daren Schwenke napsal(a):
>>
>> I guess unless some of you work for Nvidia, someone having one already
kernel 4.9 anyway?
On Tuesday, March 19, 2019 at 10:08:40 PM UTC-4, Daren Schwenke wrote:
>
> I just got a little bit excited as a powerful machine vision platform in a
> small and relatively inexpensive form factor just happened.
> 128 Cuda cores...
> It even has a Pi camera slo
I just got a little bit excited as a powerful machine vision platform in a
small and relatively inexpensive form factor just happened.
128 Cuda cores...
It even has a Pi camera slot onboard.
Ok... a lot excited..
https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-nano/
Thi
ompiled worked, so I didn't have to think about
it... until now.
Looks like an easy fix to just pass it through though. I need to just do
it. Thank you Bas.
On Saturday, September 8, 2018 at 4:13:49 AM UTC-4, Bas de Bruijn wrote:
>
>
>
> On 8 Sep 2018, at 03:40, Daren Schwenke
uld probably be faster.
I saw they use C in openpnp as the rotational axis. I'm guessing that XYZ
normally map to rotation about axis... ABC then? So C is rotation about Z
axis?
On Friday, September 7, 2018 at 12:44:01 AM UTC-4, Bas de Bruijn wrote:
>
>
>
> On 7 Sep 2018, at 0
is getting short.
So am I correct in saying that adding the extra axis to trivkins would
solve the issue also though?
On Thursday, September 6, 2018 at 1:16:07 PM UTC-4, Daren Schwenke wrote:
>
> G0 X10, moves to X10 as an MDI command. G0 A180, does nothing.
> I imagine this is because trip
codes and analog pins.
I believe the Machineface gui, as written, always acts on the joints
though. So there I can push the button for A and A moves.
On Thursday, September 6, 2018 at 12:24:42 PM UTC-4, Bas de Bruijn wrote:
>
>
>
> On 6 Sep 2018, at 12:32, Daren Schwenke >
> wrot
G1 A during that move, but I don't need that now.
Worst case, I can could also just reassign this to some M code, but out of
the box it expects A.
(Openpnp)
On Thursday, September 6, 2018 at 6:23:14 AM UTC-4, Bas de Bruijn wrote:
>
>
>
> > On 6 Sep 2018, at 11:31, Daren Schwenke
So I have tripod kinematics working well.
Now I added an A axis for part rotation via an rc servo now, plumbed it up
with scale and limits and such, and it works in joint mode.
I added my rotation as an axis so the planner can have a relatively good
guess as to when it will reach the actual posit
unday, August 12, 2018 at 10:49:55 PM UTC-4, Daren Schwenke wrote:
>
> Following the other thread on GPIO made me wonder how stable that approach
> was going to be, so I went looking around and came across this:
>
> https://github.com/Wallacoloo/Raspberry-Pi-DMA-Example/blob/master/d
Following the other thread on GPIO made me wonder how stable that approach
was going to be, so I went looking around and came across this:
https://github.com/Wallacoloo/Raspberry-Pi-DMA-Example/blob/master/dma-gpio.c
Having DMA handle the GPIO writes removes the CPU from the equation, and
his ap
Curious, what kind of step rates can you reliably get out of this on the Pi?
On Sunday, June 17, 2018 at 12:06:02 PM UTC-4, Timothy March wrote:
>
> Having trouble getting gipo's to work can get all to show up as outputs
> but when I load comp no pins are available output or input. The following
Totally awesome. Thank you.
On Monday, March 19, 2018 at 3:02:36 PM UTC-4, Alexander Rössler wrote:
>
> I'm proud to announce that the NGCWriter plugin has made it into the
> Cura plugin repository. From Cura 3.2 onward you can install NGCWriter
> just by adding it via Plugins > Browse Plugins.
np
>
> On Thursday, April 5, 2018 at 9:38:13 PM UTC+2, Daren Schwenke wrote:
>>
>> Depends on what you are running for your USB. Ethernet, then you are
>> good.
>> There is the old way using halcmd stuff, and the new way using the
>> mkwrapper protocol.
Depends on what you are running for your USB. Ethernet, then you are good.
There is the old way using halcmd stuff, and the new way using the
mkwrapper protocol.
The latter is what is used for Machineface and Cetus. I use Machineface
for running my machine from my tablet.
File transfers are b
Oh... and be careful, measure stuff first to make sure they don't have
pull-up resistors, etc.. If the BBB I/O ever sees 5v you WILL fry it. Ask
me how I know...
On Tuesday, February 27, 2018 at 2:51:44 PM UTC-5, Daren Schwenke wrote:
>
> It looks like they use the optocouplers for
It looks like they use the optocouplers for inputs and possibly a level
converter/buffer/inverting buffer for outputs.
Find a good picture of the chip tops and look them up. That picture is not
quite good enough.
It will probably work fine. Some old laptop parallel ports I've stolen
buffer c
Short answer, yes although there is a better way.
Machinekit can accept gcode from a socket if setup to do so, but what you
are asking for with a tablet interface is actually already implemented via
Machineface.
Injecting gcode is generally reserved for 'dumb' implementations. With
Machinekit
I never bothered figuring it out as it still works, but I can tell you I
experienced a similar issue.
Not related to this, but one thing that helped me later is disabling the
window manager.
No desktop on the BBG, so it just crashes over and over consuming a
surprising amount of resources.
O
The thread here has what I'm talking about.
https://groups.google.com/d/msg/machinekit/RrNLUo4ASP4/1-Aedz5RBgAJ
I gathered from this that uboot will still run from the emmc even if you
are booting from the sd card.
This prevents that, cause it clears the emmc basically.
On Monday, January 29, 2
My guess is you haven't taken the steps required to enable the overlays.
Stock debian uses a different layout for the IO pins.
What this:
bash: line 0: echo: write error: No such file or directory
is likely complaining about (badly) is the pins themselves don't exist
because you haven't made the
There are many capes. Please denote which one you are having an issue with.
Simplest way to solve this yourself is determine which pins are used
on-board (hdmi, wireless, etc), and then cross those to which pins are used
for your cape.
If any of the logic pins overlap, you will loose that func
On Sunday, January 28, 2018 at 7:14:45 PM UTC-5, gary wrote:
>
> also getting error exceeds machine minimum on axis x and y this is with a
> delta with the g code
>
It is physically possible to move the arms beyond vertical with respect to
each tower, but the lineardelta kinematics math breaks
I would suggest giving this a
try: https://github.com/machinekoder/Rostock-CRAMPS
You will need to slice with a modified version of Cura to use it as it is
velocity extrusion, but probably a better place to start.
On Friday, January 19, 2018 at 9:22:19 AM UTC-5, gary wrote:
>
> yes i tried setti
On Thursday, January 18, 2018 at 1:07:36 PM UTC-5, gary wrote:
>
> The first link didn't work...
>
It's not a link. Look on your device. That directory contains the
predefined macros related to FDM.
They need to be defined in your ini to exist.
> on the BeBoPr++ i thought i changed this
> n
Take a look at /usr/share/linuxcnc/ncfiles/remap-subroutines/fdm
A recent example config which uses the fdm files there:
https://github.com/Arcus-3d/Arcus-3D-C1-BeBoPr\
Relevant section from ini which map those codes:
https://github.com/Arcus-3d/Arcus-3D-C1-BeBoPr/blob/e2052ae8a8e982ce8a7bdb0a3a
On Saturday, January 13, 2018 at 2:06:35 PM UTC-5, gary wrote:
>
> is there a formula for calculating the radius to figure the distance i
> need to change it after all corners are done?
>
Technically, there is an automated way to calculate it all based on the
four height measurements, but I've
As you change the radius, the outside will go down while the middle goes up
(or vice versa).
it's mostly linear so if you change the radius and it gets you half way
there, double your change.
On Saturday, January 13, 2018 at 2:06:35 PM UTC-5, gary wrote:
>
> is there a formula for calculating
On Thursday, January 11, 2018 at 4:01:08 PM UTC-5, gary wrote:
>
> I got it to work i had to change remove the - from scale and also the -
> from HOME_SEARCH_VEL and now seems to be work correct with the gcode..
>
> Been looking for some hal commands to change the axis's values like when
> cali
Update your config files on the post bin to reflect their current state and
I'll take a look
--
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" gr
*P8_08_pinmux/state
>
> I am quite new to this, so I apologise if I am missing something obvious.
> I have spent days searching, but sometimes you just don't get the right
> results if you don't have the right search terms (like bbio)!
>
> Thank you
>
> On Sunda
Hate to state the obvious but...
Start here:
https://groups.google.com/forum/#!topic/machinekit/pFV3IgKqJSo
On Saturday, December 30, 2017 at 4:52:27 PM UTC-5, Cyrus wrote:
>
> Hi,
>
> I am trying to get a touchscreen lcd bbb cape to work with machinekit.
> When I install the prebuilt mac
That will work too. You now hat three possible locations for globally
affecting files then though.
Having the SD card slot available as removable storage is kinda nice though.
On Wednesday, December 6, 2017 at 5:24:57 PM UTC-5, Lewis Cobb wrote:
>
> Yes Sir ! Something a full-noob like me can u
Very nice. I'll be referencing that... :)
The services to disable for a faster boot is good stuff.
I only had to install dirmngr by itself as installing machinekit seemed to
pull the rest in for you, but I started with a different image.
On Tuesday, December 5, 2017 at 3:51:57 PM UTC-5, Alexand
On Sunday, November 12, 2017 at 3:39:34 PM UTC-5, Daren Schwenke wrote:
>
> What I would have expected to be the solution would have been setting
> initial homed position with a negative Z value, like this:
> [TRAJ]
> HOME = 300 250 -300
> When I do that and home though, the
any ideas, I'll just make a new kinematics module which is
always inverted. Seems like a waste though.
On Saturday, November 11, 2017 at 6:10:32 PM UTC-5, Daren Schwenke wrote:
>
> I posted the result, not the cause:
>
> https://github.com/machinekit/machinekit/blob/314246595127ddc2
Search this forum for 'PRU Hunting'.
On Sunday, November 12, 2017 at 11:58:32 AM UTC-5, Damien D wrote:
>
> Hello,
>
> I'm creating my first Machinekit configuration, so far I have been able to
> solved everything by myself but now I'm facing annoying issue with stepgen.
> I'm using a BBB with th
I posted the result, not the cause:
https://github.com/machinekit/machinekit/blob/314246595127ddc2dc08bb0f8a9e8606260e1679/src/emc/kinematics/tripodkins.c#L202
On Saturday, November 11, 2017 at 6:01:17 PM UTC-5, Daren Schwenke wrote:
>
> I have been searching for a while for how to imp
I have been searching for a while for how to implement tripodkins. Got
that sorted, but it's made for struts and not cables. So I actually need
inverted tripodkins.
Real word the non-inverted tripodkins translates to the opposite
compensation occurring. A Z axis coordinated move in the center
Please take a photo of the traces so I can determine which circuit they use.
If they are the same as 'normal', then they use the phototransistor as a
pull-down.
It's wired across a 10k and an led + resistor connected to +5.
Connect them out in parallel separate from the BBB. If the LED's still
Alternately, you could use the normally closed switch contact instead, and
make a loop going out from the CRAMPS board through all of them, then back
into your one pin.
You would need to invert your pin logic then, or swap from using 3.3v to
ground or vice versa.
On Thursday, November 9, 2017
If these are switches, you are risking nothing. It will work fine.
Just make sure to use the same logic level ground or +3.3v for all of them.
If they are optical, they may 'fight' over the logic level to provide so
that would require additional thought.
On Thursday, November 9, 2017 at 10:54:5
It was my config-pin settings.
I was setting the mode for the PRU pins to 'gpio'.
I changed them all to 'low' and now it works.
On Monday, November 6, 2017 at 5:56:04 PM UTC-5, Charles Steinkuehler wrote:
>
> On 11/6/2017 4:42 PM, Daren Schwenke wrote:
> > I
ins I used into the CRAMPS config and find out.
On Monday, November 6, 2017 at 11:04:43 AM UTC-5, Daren Schwenke wrote:
>
>
>
> On Monday, November 6, 2017 at 8:37:21 AM UTC-5, Charles Steinkuehler
> wrote:
>>
>> That processor is supposed to have the PRUs, so I'm
On Monday, November 6, 2017 at 11:46:29 AM UTC-5, Robert Nelson wrote:
>
> On Mon, Nov 6, 2017 at 10:34 AM, Daren Schwenke > wrote:
> >
> >
> > On Monday, November 6, 2017 at 11:04:43 AM UTC-5, Daren Schwenke wrote:
> >>
> >>
> >>
On Monday, November 6, 2017 at 11:04:43 AM UTC-5, Daren Schwenke wrote:
>
>
>
> On Monday, November 6, 2017 at 8:37:21 AM UTC-5, Charles Steinkuehler
> wrote:
>>
>> That processor is supposed to have the PRUs, so I'm not sure what's
>> going wron
icked, or the config.
I'm going to start over with a working config and narrow it down to a
couple pins toggling and see what happens.
>
> On 11/5/2017 7:53 PM, Daren Schwenke wrote:
> > am3358bzcz100 <http://www.ti.com/lit/ds/symlink/am3358.pdf>
> >
> > BBGW
I'm going to try starting with Jessie and see if I fare any better.
I'll get another data point then at least. Too many variables right now.
On Sunday, November 5, 2017 at 8:59:48 PM UTC-5, Daren Schwenke wrote:
>
> In case you are wondering why I picked such an ancient cape t
Sunday, November 5, 2017 at 8:53:56 PM UTC-5, Daren Schwenke wrote:
>
> am3358bzcz100 <http://www.ti.com/lit/ds/symlink/am3358.pdf>
>
> BBGW <https://beagleboard.org/green-wireless>
> On Sunday, November 5, 2017 at 7:59:31 PM UTC-5, Charles Steinkuehler
> wrote:
>
am3358bzcz100 <http://www.ti.com/lit/ds/symlink/am3358.pdf>
BBGW <https://beagleboard.org/green-wireless>
On Sunday, November 5, 2017 at 7:59:31 PM UTC-5, Charles Steinkuehler wrote:
>
> On 11/5/2017 5:04 PM, Daren Schwenke wrote:
> > On Sunday, November 5, 2017 at
On Sunday, November 5, 2017 at 1:21:40 PM UTC-5, Daren Schwenke wrote:
>
>
>
> On Sunday, November 5, 2017 at 12:29:42 PM UTC-5, Charles Steinkuehler
> wrote:
>>
>> On 11/5/2017 7:23 AM, Daren Schwenke wrote:
>> > On Sunday, November 5, 2017 at 8:01:59 AM UT
On Sunday, November 5, 2017 at 1:21:40 PM UTC-5, Daren Schwenke wrote:
>
>
>
> On Sunday, November 5, 2017 at 12:29:42 PM UTC-5, Charles Steinkuehler
> wrote:
>>
>> On 11/5/2017 7:23 AM, Daren Schwenke wrote:
>> > On Sunday, November 5, 2017 at 8:01:59 AM UT
On Sunday, November 5, 2017 at 12:29:42 PM UTC-5, Charles Steinkuehler
wrote:
>
> On 11/5/2017 7:23 AM, Daren Schwenke wrote:
> > On Sunday, November 5, 2017 at 8:01:59 AM UTC-5, Daren Schwenke wrote:
> >> On Sunday, November 5, 2017 at 7:51:02 AM UTC-5, Charles Ste
On Sunday, November 5, 2017 at 8:01:59 AM UTC-5, Daren Schwenke wrote:
>
>
>
> On Sunday, November 5, 2017 at 7:51:02 AM UTC-5, Charles Steinkuehler
> wrote:
>>
>> On 11/5/2017 6:37 AM, Daren Schwenke wrote:
>> > That's the confusing part. Things wor
On Sunday, November 5, 2017 at 7:51:02 AM UTC-5, Charles Steinkuehler wrote:
>
> On 11/5/2017 6:37 AM, Daren Schwenke wrote:
> > That's the confusing part. Things work fine with hal_bb_gpio, and not
> with
> > hal_pru_generic.
> >
> > The estop hardw
For kicks, I just moved 843,844 from hal_pru_generic step/dir to toggling
with emcmot-0-enable, and they toggle with estop so it's not an issue with
the specific pins being burned here either.
On Sunday, November 5, 2017 at 7:37:20 AM UTC-5, Daren Schwenke wrote:
>
> That's th
s) via halcmd set has any
> affect.
>
> If either of those fail, the PRU is probably not working for the same
> reason...get the above fixed and things ought to work better.
>
> On 11/4/2017 11:24 PM, Daren Schwenke wrote:
> > I noticed most of my pins were tied to PRU 1,
the end.
https://pastebin.com/96ZWP0KD
On Saturday, November 4, 2017 at 7:27:51 PM UTC-4, Daren Schwenke wrote:
>
>
>
> On Saturday, November 4, 2017 at 7:21:21 PM UTC-4, Daren Schwenke wrote:
>>
>> Suppose this would be useful info. Started with this image:
>>
>&
On Saturday, November 4, 2017 at 7:21:21 PM UTC-4, Daren Schwenke wrote:
>
> Suppose this would be useful info. Started with this image:
>
> https://rcn-ee.com/rootfs/bb.org/testing/2017-10-29/stretch-iot/BBB-blank-debian-9.2-iot-armhf-2017-10-29-4gb.img.xz
> Did the stuff for
, Daren Schwenke wrote:
>
> BBGW with a 'mostly' BeBoPr cape. Hand wired, very basic, with some pins
> moved so they didn't step on wifi.
> Booting from eMMC.
>
> Config here. Starts, no errors.
> https://github.com/Arcus-3d/Arcus-3D-C1-BeBoPr
>
> GPIO
BBGW with a 'mostly' BeBoPr cape. Hand wired, very basic, with some pins
moved so they didn't step on wifi.
Booting from eMMC.
Config here. Starts, no errors.
https://github.com/Arcus-3d/Arcus-3D-C1-BeBoPr
GPIO works, triggering estop and machine power correctly.
halcmd shows it should be out
Yes it's excessive, over the top, and somewhat pointless, but an excessive demo
which shows the journey from beginning to end in a space where documentation is
sparse is definitely better than no demo at all.
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github:
https://
gt; [Putting this back on-list]
>
> On 11/01/2017 11:52 AM, Chris Albertson wrote:
> >
> > On Wed, Nov 1, 2017 at 8:40 AM, John Morris
> > <mailto:jo...@zultron.com >> wrote:
> >
> > On 11/01/2017 10:15 AM, Daren Schwenke wrote:
> >
&g
upply when people do silly things like switching from full cool to full
heat.
On Wednesday, November 1, 2017 at 11:40:10 AM UTC-4, John Morris wrote:
>
>
>
> On 11/01/2017 10:15 AM, Daren Schwenke wrote:
> > When switching peltiers between heat/cool mode you can get some re
When switching peltiers between heat/cool mode you can get some really high
currents.
You may want to include some current feedback and perhaps limit your PWM
during switching, or just keep it from doing that with your PID.
On Wednesday, November 1, 2017 at 11:04:36 AM UTC-4, Daren Schwenke
Neat idea, and perfect name. :)
On Tuesday, October 31, 2017 at 2:07:09 PM UTC-4, John Morris wrote:
>
> I'm working on this Machinekit-based weekend project, the "Goldibox"
> [1]. Kind of like a cross between a fridge and an incubator, you set
> minimum and maximum temperatures on its thermos
The mixing head was not open source. Everything else was. That was a
misquote.
At least it will not be until we can get to producing them ourselves, so
the cost/benefit analysis people will do will land on the side of 'just buy
it'.
We were trying to be totally self-funded to do so, but the ca
Featured on Hackaday, again. :)
http://hackaday.com/2017/10/12/this-3d-cable-printer-remixes-the-delta/
Go Machinekit!
Still need to build a tripodkins config with Machineface...
On Friday, October 6, 2017 at 5:10:35 PM UTC-4, Daren Schwenke wrote:
>
> Built this with the intent of r
2017 at 11:55:15 AM UTC-4, Daren Schwenke wrote:
>
>
>
> On Saturday, October 7, 2017 at 8:16:49 AM UTC-4, Bas de Bruijn wrote:
>>
>>
>>
>> On 6 Oct 2017, at 23:10, Daren Schwenke wrote:
>>
>> Built this with the intent of running Machinekit/tripodki
On Saturday, October 7, 2017 at 8:16:49 AM UTC-4, Bas de Bruijn wrote:
>
>
>
> On 6 Oct 2017, at 23:10, Daren Schwenke >
> wrote:
>
> Built this with the intent of running Machinekit/tripodkins with it.
> Have not worked on the config yet, but the hardware looks l
Built this with the intent of running Machinekit/tripodkins with it.
Have not worked on the config yet, but the hardware looks like it will work
now, so soon.
https://hackaday.io/project/26938-arcus-3d-c1-cable-printer
https://youtu.be/KQ19fT4BQQU
--
website: http://www.machinekit.io blog: h
g the
> gantries. I cracked some of 3d printed bearing blocks. Luckily weld
> repairing them is fairly easy.
> Switches are wired and installed I need to install terminals, and hook
> into the cramps and redo the Hal and ini's. Yikes, I'm running out of time
> here.
hem is fairly easy.
> Switches are wired and installed I need to install terminals, and hook
> into the cramps and redo the Hal and ini's. Yikes, I'm running out of time
> here.
>
>
>
> On Sep 14, 2017 2:47 AM, "Daren Schwenke" > wrote:
>
>> I&#
I'm at my other home in FL currently and crashed the head on the printer,
destroying part of the head and splitting my ceramic bed. Nema23 and 9mm
belts may have been a bad choice.
Tried updating to use the new pythonic configs and it turns out in the
current fdm module (without using the subd
ystem uevent
machinekit@beaglebone:/sys/devices/bone_capemgr.9$ cat slot
slot-4/ slot-5/ slot-6/ slot-7/ slot-8/ slots
machinekit@beaglebone:/sys/devices/bone_capemgr.9$ cat slots
^C^C^C
On 9/6/2017 11:36 AM, Daren Schwenke wrote:
> > machinekit@beaglebone:~/git/Arcus-3D-M2$ ls -al
17 at 12:12:40 PM UTC-4, Daren Schwenke wrote:
>
> I have a BBB with hal_temp_bbb locked up, right now... still running.
> What should I gather here to help diagnose why?
>
> Everything else seems normal, just no temp updates.
>
--
website: http://www.machinekit.io blog: http://bl
The perceived lack of performance of Axis on the BBB is due to software
rendering. It's not a memory constraint.
The hardware acceleration of graphics is broken in the earlier kernels,
which is what xenomai currently works on.
Newer kernels use xenomai 3 (I believe) and we don't.
The newer rt-p
/44e0d000.tscadc/tiadc/iio:device0/in_voltage4_raw
cat: /sys/devices/ocp.3/44e0d000.tscadc/tiadc/iio:device0/in_voltage4_raw:
Resource temporarily unavailable
machinekit@beaglebone:~/git/Arcus-3D-M2$
On Wednesday, September 6, 2017 at 12:12:40 PM UTC-4, Daren Schwenke wrote:
>
> I have a BB
YMOUS, -1, 0) =
0xb6fd
On Wednesday, September 6, 2017 at 12:12:40 PM UTC-4, Daren Schwenke wrote:
>
> I have a BBB with hal_temp_bbb locked up, right now... still running.
> What should I gather here to help diagnose why?
>
> Everything else seems normal, just no temp u
I have a BBB with hal_temp_bbb locked up, right now... still running.
What should I gather here to help diagnose why?
Everything else seems normal, just no temp updates.
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github:
https://github.com/machinekit
---
You received
I have run this in the past with no issues.
My current testing machine is targeting the BBGW though, so it's using
rt-preempt (so wireless works) and the BeBoPr config instead (as CRAMPS
shares pins with the wifi/bluetooth module)
So I can't directly assist you atm.
On Sunday, September 3, 201
Up to 2.3.1 works with his walkthrough.
On Thursday, August 31, 2017 at 9:01:58 AM UTC-4, Pranav Pandey wrote:
>
> No, I didn't use the Cura 2.1.3. I am using the latest version 2.7. I will
> try with the 2.1.3 version once
>
> On 31 Aug 2017 18:11, "Bas de Bruijn" >
> wrote:
>
>>
>> On 31 Aug 2
The Cura plugin also requires you to create a machine that uses it.
It's also made for velocity extrusion, so you would need to use a config
that also uses velocity extrusion. It's one or the other.
Then you will be outputting ngc files instead of gcode, and E/A will
disappear.
E/A will be r
If you want to simplify your life, and don't mind a remote interface, I
would go a little different route.
Axis still sucks on the BBB due to software rendering sucking up most of
the CPU. The solution to that is use a remote interface. The one for 3D
printing is 'Machineface'.
That and the
This sounds mechanical to me (or if the mechanics are already dialed in the
best they are going to get, not measuring and putting in a value for
BACKLASH.
Running on a BBB or not, same gcode.
The default gcode for the 'Machinekit' logo will cut, and then you'll know.
Keep in mind that just t
Tried linux-image-4.9.40-bone-rt-r7.
It's 15% better for processor usage, but still a lot higher than xenomai.
3735 root 20 0 63524 58884 10816 S 30.4 11.7 0:29.66 rtapi:0
3754 machine+ 20 0 14608 9260 6644 S 3.3 1.8 0:03.32
hal_temp_bbb
3766 ma
One more thing. You may need to do this to force it to use the uboot
version on your SD card instead of the eMMC.
sudo dd if=/dev/zero of=/dev/mmcblk1 count=1 seek=1 bs=128k
On Saturday, July 29, 2017 at 4:39:49 PM UTC-4, Daren Schwenke wrote:
>
> Everything works, with the caveat of
Everything works, with the caveat of really high processor utilization.
About 80-90% all the time, with rtapi:0 taking about 50% of that.
This makes for a slower user interface even when using remote.
But, that doesn't seem to affect operation as I've printed 2 good looking
1.5 hour parts so far
I'm not sure what magic sequence of events allowed this to run before, but
I can't get RTAPI to start now.
As I was messing about with other stuff and possibly screwed it up, I'm
starting fresh with Robert's newly built image and I'll work from there.
--
website: http://www.machinekit.io blog:
; wrote:
> On Fri, Jul 28, 2017 at 11:41 PM, Robert Nelson
> wrote:
> > On Fri, Jul 28, 2017 at 5:40 PM, Daren Schwenke
> wrote:
> >> So I think this is getting really close now. I'm compiling again so I
> can
> >> remove the dependencies outside of
1408 S 0.0 0.5 0:01.16 systemd
2 root 20 0 000 S 0.0 0.0 0:00.00 kthreadd
5 root 0 -20 000 S 0.0 0.0 0:00.00 kworker/0:0H
On Friday, July 28, 2017 at 6:40:06 PM UTC-4, Daren Schwenke wrote:
>
> So I think this is
1 - 100 of 199 matches
Mail list logo
