[Machinekit] PocketBeagle CRAMPS type board

[Daren Schwenke]

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 for the 
BBB and friends.  Any insight the community may have into that or other 
specific roadblocks I may experience along the way here would be 
appreciated.
One other specific issue I can think of is what would be a good single pin 
to use for an 'enable' line that doesn't flip-flop during boot before the 
rest of the pins get assigned.

Thank you.

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/1f77a9b3-c69c-4085-85b9-ae8d91a5c876%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Velocity Extrusion - Dips in Velocity

[Daren Schwenke]

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-4, Dennis wrote:
>
> Dear Machinekit users,
> right now we're facing issues with velocity extrusion. Our test system is 
> installed with Debian Stretch and Machinekit in 
> version 0.1.1543327459.gite7 (uname -a output: Linux labor-m2 
> 4.9.0-8-rt-amd64 #1 SMP PREEMPT RT Debian 4.9.144-3.1 (2019-02-19) x86_64 
> GNU/Linux). We use three axes with one extruder in velocity extrusion mode.
>
> The attached .ngc-file was created with the ngcwriter-plugin for Cura. 
> Stumbling across another post in this forum (
> https://groups.google.com/forum/#!searchin/machinekit/m67%7Csort:date/machinekit/mRTcGHU4lUc/hSyyGclIPagJ)
>  
> I also attached the output of the rs274 standalone interpreter. Maybe this 
> helps.
>
> The Problem we have is, when we print the file (with and without filament) 
> we are facing issues with the extruder feedrate. For a short period of time 
> the feedrate seems to halt, although there should be continuous filament 
> output. We think the issue may be related to command M67 (perhaps related 
> to this issue here https://sourceforge.net/p/emc/bugs/437/). 
>
> Has anyone ever observed such a problem? 
>
> Unfortunately I'm not abled right now to post the contents of linuxcnc.log 
> with DEBUG=5 enabled, because our printer has a hardware malfunction.
>
> Best regards
> Dennis
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/615088ef-f96c-41f8-b0b8-dfe174e8ec82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: CRAMPS + BBB Nema 23

[Daren Schwenke]

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 up in your output.  Good news is if you don't use 
microstepping the issue seems to go away for the most part.
  
Also, as long as you keep your drive voltage lower they will still work 
ok.  Exceed say 19V though and the combination will start to display more 
artifacts.
You *can* run those drivers at a suitable current to get decent performance 
out of the smaller Nema 23 motors.  You'll just need to cool the crap out 
of them to run them at their full rated current of 2.2-2.4A. I personally 
watercooled mine, but that was probably excessive.
You can set the trim pot to well higher than the max current, so don't just 
think you can turn it up and not measure it.  Output current = 2x voltage 
with respect to ground measured on the pot slider.  Clip a lead to your 
screwdriver shaft, and another to a ground pin for dead simple current 
setting.
There is a decay setting you can alter on the module by soldering a jumper 
to a pin on the chip that helps, but it also makes them a lot noisier when 
sitting still.
The real Pololu branded DRV8825 stepsticks did perform better than the 
knockoffs. 

As for others?  I replaced my DRV8825's with some AMIS-30543 chips a few 
weeks back.  *The are not stepsticks* though and require SPI to configure 
them. They are a little too big and so you end up standing them on end, on 
an adapter board..  :)   
They also run just as hot as the DRV8825 chips, but do have a higher max 
current of 3A per phase.  However, they also do not degrade when used with 
low inductance/high voltage like the DRV8825's do that I have seen.


On Friday, May 24, 2019 at 6:42:28 PM UTC-4, Bradley Turner wrote:
>
> I am running a BBB with CRAMPS cape for a small 4 axis CNC. I began with 
> Nema 17s, however due to lack of torque I want to move up to Nema 23s. I 
> know that the Pololu style stepper drivers can run Nema 23s, and I wanted 
> to know if anyone had recommendations on stepper drivers for Nema 23s. I an 
> currently using DRV-8825s.
> Thank you!

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/9b55b26e-fa12-4f99-ab19-71be12794d86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: Machinekit on PocketBeagle

[Daren Schwenke]

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 noticed for two years I would call it a 
> feature request, not a bug ;) 
>
> Thanks a lot - I'll confirm once I manage to build it. 
> Markus 
>
> On Mon, 20 May 2019 22:12:24 -0700 (PDT) 
> John Morris > wrote: 
>
> > On Tuesday, May 21, 2019 at 6:30:32 AM UTC+8, mlampert wrote: 
> > > 
> > > I created an issue, hope I got the description right: 
> > > https://github.com/machinekit/machinekit/issues/1481 
> > >   
> > 
> > Thanks, Markus and Charles.  I put in a PR: 
> > 
> > https://github.com/machinekit/machinekit/pull/1482 
> > 
> > Sorry I didn't test the original patch more rigorously.  Seems my 
> > super-simple Goldibox HAL config didn't use any GPIO inputs! 
> > 
> > John 
> >   
> > 
> > > 
> > > On Mon, 20 May 2019 14:39:49 -0700 
> > > markus > wrote: 
> > >   
> > > > Yay - that does work, it is required to specify the board though: 
> > > > 
> > > > markus@pocketbeagle:~/machinekit/configs/infinity$ halrun 
> > > > msgd:0 stopped 
> > > > rtapi:0 stopped 
> > > > rtapi_msgd command:  /usr/libexec/linuxcnc/rtapi_msgd 
> > > > --instance=0 --rtmsglevel=1 --usrmsglevel=1 --halsize=524288 
> > > > rtapi_app command:  /usr/libexec/linuxcnc/rtapi_app_rt-preempt 
> > > > --instance=0 halcmd: loadrt hal_bb_gpio  output_pins=201 
> > > > :1: insmod failed, returned -1: 
> > > > rtapi_app_main(hal_bb_gpio): -1 Operation not permitted 
> > > > 
> > > > halcmd: loadrt hal_bb_gpio board=PocketBeagle output_pins=201 
> > > > halcmd: 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > On Mon, 20 May 2019 16:24:59 -0500 
> > > > Charles Steinkuehler > 
> > > > wrote: 
> > > > > Hmm...looking at the code it appears the output pins have a 
> > > > > conditional for the pin numbering fixup: 
> > > > > 
> > > > >   
> > > 
> https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_bb_gpio/hal_bb_gpio.c#L365-L370
>  
>   
> > > > > 
> > > > > ...that's missing for the input pins: 
> > > > > 
> > > > >   
> > > 
> https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_bb_gpio/hal_bb_gpio.c#L272-L275
>  
>   
> > > > > 
> > > > > Combined with the legacy use of 1xx and 2xx for the BeagleBone 
> > > > > pin numbers (which is why the fixup exists in the first place) 
> > > > > it looks like that's breaking you pin numbering scheme. 
> > > > > 
> > > > > Can you try with just output pins and see if that works? 
> > > > > 
> > > > > 
> > > > > On 5/20/2019 4:06 PM, markus wrote: 
> > > > > > That actually is the problem - the driver takes the p1 and p2 
> > > > > > pins and uses them as p8 and p9 pins, this is the excerpt 
> > > > > > from the hal file that I used: 
> > > > > > 
> > > > > > # load low-level drivers 
> > > > > > loadrt hal_bb_gpio board=PocketBeagle 
> > > > > > input_pins=201,202,203,204 
> > > > > > output_pins=217,227,228,229,230,231,232 loadrt 
> > > > > > [PRUCONF](DRIVER) prucode=$(HAL_RTMOD_DIR)/[PRUCONF](PRUBIN) 
> > > > > > [PRUCONF](CONFIG) 
> > > > > > 
> > > > > > Same thing happens if I do it manually with halrun - and it 
> > > > > > complains about the first pin in the command line, so if I 
> > > > > > remove 201 it complains about 902 not being valid. 
> > > > > > 
> > > > > > 
> > > > > > On Mon, 20 May 2019 15:55:37 -0500 
> > > > > > Charles Steinkuehler > 
> > > > > > wrote: 
> > > > > >> On 5/20/2019 3:36 PM, markus wrote:   
> > > > > >>> Thanks for the clarification - much appreciated. 
> > > > > >>> 
> > > > > >>> It seems the driver is ignoring the parameter though. And I 
> > > > > >>> get the same result. From linuxcnc.log: 
> > > > > >> 
> > > > > >> Look closer, it's not the same result. 
> > > > > >>   
> > > > > >>> May 20 00:07:37 pocketbeagle msgd:0: startup pid=1376 
> > > > > >>> flavor=rt-preempt rtlevel=1 usrlevel=1 halsize=524288 
> > > > > >>> shm=Posix cc=gcc 6.3.0 20170516  version=v0.1~-~355496b 
> > > > > >>> May 20 00:07:37 pocketbeagle msgd:0: ØMQ=4.2.1 czmq=4.0.2 
> > > > > >>> protobuf=3.0.0 atomics=gcc intrinsics 
> > > > > >>> libwebsockets=2.0.3 May 20 00:07:37 pocketbeagle msgd:0: 
> > > > > >>> configured: sha=355496b May 20 00:07:37 pocketbeagle 
> > > > > >>> msgd:0: built:  Mar 14 2019 10:47:55 sha=355496b May 20 
> > > > > >>> 00:07:37 pocketbeagle msgd:0: register_stuff: actual 
> > > > > >>> hostname as announced by avahi='pocketbeagle.local' May 20 
> > > > > >>> 00:07:37 pocketbeagle msgd:0: zeroconf: registering: 'Log 
> > > > > >>> service on pocketbeagle.local pid 1376' May 20 00:07:38 
> > > > > >>> pocketbeagle msgd:0: zeroconf: registered 'Log service on 
> > > > > >>> pocketbeagle.local pid 1376' _machinekit._tcp 49152 TXT 
> > > > > >>> "uuid=4e7e123c-1726-4351-bdfc-eba93047fb35" 

[Machinekit] Re: config-pin setting for Mode 0 (gpmc) question

[Daren Schwenke]

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 those pins don't 
exist at all.

On Friday, April 19, 2019 at 4:08:19 PM UTC-4, Jeff Pollard wrote:
>
> Hi,
>   That makes sense, but
>
>   I can use config-pin to set the value to something like: 
> *  pwm*
>   for example:
> *  config-pin P8.14 pwm* 
>   will work just fine
>   as will *gpio*
>   and 
> *gpio_pd, etc.*
>
>   But, *gpmc* (mode 0) is not a valid choice i.e. config-pin  p8.14 gpmc 
> is invalid
>   I tried adding it to the config-pin script for pin 8_14, but that didn't 
> help as it appears the problem is deeper than than.  I can't change the 
> value of state in:
>
> /sys/devices/platform/ocp/ocp:P8_14_pinmux/state
>
>   the error I get is:
>
> *Cannot write pinmux File: 
> /sys/devices/platform/ocp/ocp:P8_14_pinmux/state*
>
> Jeff
>
> On Friday, April 19, 2019 at 12:39:21 PM UTC-7, Mala Dies wrote:
>>
>> Hello,
>>
>> The config-pin utility can be used in user land or user land w/ a .sh 
>> script and .service file to boot the board w/ the required config-pin 
>> utility being present.
>>
>> Seth
>>
>> P.S. If you know how to do this instead, this may work for you. So, use: 
>> config-pin P8.14  <--- this would be your mode, i.e. GPIO, UART, 
>> and etc.
>>
>> So, if you wanted to put in gpio in , you could if this is what you 
>> want. Does this sort of make sense?
>>
>> On Friday, April 19, 2019 at 1:55:21 PM UTC-5, Jeff Pollard wrote:
>>>
>>>
>>> Hi,
>>>
>>>   I'm using:* Linux beaglebone 4.14.106-bone-rt-r19 #1 PREEMPT RT Tue 
>>> Mar 26 19:02:06 UTC 2019 armv7l GNU/Linux*
>>>
>>>   I started by disabling the emmc in uEnv.txt
>>>
>>>   I then tried to modify the config-pin script for P8_14 (which would be 
>>> gpmc_AD14 as a starting example), but I get
>>>
>>> *Cannot write pinmux File: 
>>> /sys/devices/platform/ocp/ocp:P8_14_pinmux/state*
>>>
>>>   Can anyone give a pointer on how to go about configuring pins to use 
>>> gmpc mode with the config-pin script (or any other method)?
>>>
>>> Thanks,
>>>
>>> Jeff
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Transition to Machine Kit for fully custom LinuxCNC build?

[Daren Schwenke]

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 choose for things, and how many.  
But that should give you an idea.  I changed basically nothing to do this 
other than picking my pins carefully.
You'll likely never hit the stepping limit before your physical hardware 
can no longer cope.

On Wednesday, April 17, 2019 at 7:47:17 PM UTC-4, justin White wrote:
>
> OK, that actually clears up some of my confusion. I didn't realize the 
> GPIO was that fast, there's generally some latency on GPIO then again I'm 
> really not up to snuff on the BBB. Any Idea what step rates the BBB will 
> support on GPIO? Looks like I run around 52kHz accelerations on my current 
> setup.
>
> I saw that spreadsheet before but I was a bit confused looking at it, but 
> it makes more sense now that I know the stepgens aren't really targeting 
> the PRUs. I'm still a bit sure of how the modes work because it looks like 
> the "BeBoPr Function" for example is using the analog inputs tor a 
> thermocouple but analog inputs are only available in mode 0 but GPIO on 
> header2 is only available in mode 7. I assumed that the modes were set for 
> the whole header or PRU but now I'm guessing that each pin can be mode set 
> individually?
>
> On Monday, April 15, 2019 at 6:37:55 PM UTC-4, Charles Steinkuehler wrote:
>>
>> On 4/15/2019 5:28 PM, justin White wrote: 
>> > 
>> > I started tossing around the idea of making a shield that is compatible 
>> > with both the  BBB and the DE0/DE10 nano. Seems completely feasible 
>> since 
>> > the BBB headers physically sit inside of the DExx nano headers. The 
>> concern 
>> > becomes 90% about the BBB pinout because there seems to be alot of 
>> special 
>> > considerations for the BBB based on what you're willing to give up, 
>> whereas 
>> > the nano can just be configured pretty much however necessary. 
>> > 
>> > Looking at it I was starting to get a headache trying to figure out 
>> exactly 
>> > what the constraints are in regards to the "modes" and the PRUs. From 
>> all I 
>> > could dig up it looks like I wouldn't have enough PRU I/O left over to 
>> > really do anything with. I don't so much care about losing HDMI, but 
>> I'd 
>> > actually like to keep the emmc if possible. I'm pretty verse with 
>> LinuxCNC 
>> > but the BBB thing and how it all ties into the hal PRU driver is a bit 
>> > complicated. 
>>
>> You don't really need to use PRU direct I/O for anything but encoder 
>> inputs (assuming you want to use PRU based encoders).  The performance 
>> difference between using a GPIO pin as an output for step/dir or PWM 
>> is negligible vs. using the PRU direct outputs. 
>>
>> > Is there any info on the machinekit images for the standard pin 
>> configs? 
>> > Ideally I'd like to get 4 step/direction, 1 ABZ encoder, and at least a 
>> > couple of PRU inputs/and outputs the rest I can just use the slower 
>> GPIO. 
>> > I'd like to get ahold of a pin config that is verified to work so I 
>> know 
>> > what I'm working with 
>>
>> There are lots of choices.  :)  I have a number of board pinouts 
>> listed in spreadsheet form which you may find helpful: 
>>
>>
>> https://github.com/cdsteinkuehler/beaglebone-black-pinmux/blob/hal_pru_generic/pinmux.ods
>>  
>>
>> -- 
>> Charles Steinkuehler 
>> cha...@steinkuehler.net 
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: Machinekit on BBB; not all configurations load

[Daren Schwenke]

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 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 file browser, and then edit that file to 
> point to where it actually is.
>
>
> On Thursday, April 4, 2019 at 9:48:33 AM UTC-4, Sardar Vayghannezgad wrote:
>>
>> I don't like to come across as one not making the tiniest background 
>> attempt at all, but I just don't know how to change the path. :|
>>
>> [image: Mailtrack] 
>> <https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5&;>
>>  Sender 
>> notified by 
>> Mailtrack 
>> <https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5&;>
>>  04/04/19, 
>> 4:43:54 PM 
>>
>> On Thu, Apr 4, 2019 at 4:31 PM Bas de Bruijn  
>> wrote:
>>
>>> Have you changed the path to setup.bridge.sh as Daren pointed out?
>>>
>>> On 4 Apr 2019, at 15:24, Sardar Vayghannezgad  wrote:
>>>
>>> I read online that starting as ssh -Y us...@beaglebone.local may help. 
>>> I am getting this if I start that way:
>>> ln: cannot remove '/tmp/linuxcnc.print': Operation not permitted
>>> ln: cannot remove '/tmp/linuxcnc.debug': Operation not permitted
>>>
>>>
>>>
>>> On Wednesday, April 3, 2019 at 11:19:08 PM UTC+3, Sardar Vayghannezgad 
>>> wrote:
>>>>
>>>> Once I start machinekit on my element14 BBB, the configuration window 
>>>> pops up with an array of configurations. But it looks like my favorite one 
>>>> won't load. I get the following:
>>>>
>>>>
>>>> machinekit@beaglebone:~$ machinekit
>>>> MACHINEKIT - 0.1
>>>> Machine configuration directory is 
>>>> '/home/machinekit/machinekit/configs/ARM.BeagleBone.PocketNC-1'
>>>> Machine configuration file is 'PocketNC.ini'
>>>> Starting Machinekit...
>>>> rtapi_msgd command:  /usr/libexec/linuxcnc/rtapi_msgd --instance=0 --
>>>> rtmsglevel=1 --usrmsglevel=1 --halsize=524288
>>>> rtapi_app command:  /usr/libexec/linuxcnc/rtapi_app_rt-preempt --
>>>> instance=0
>>>> io started
>>>> halcmd loadusr io started
>>>> PocketNC.hal:10: execv(/home/machinekit/machinekit-dev/configs/ARM/
>>>> BeagleBone/PocketNC/setup.bridge.sh): No such file or directory
>>>> E: 19-04-03 19:38:58 dangling 'DEALER' socket created at hal/utils/
>>>> halcmd_rtapiapp.cc:284
>>>> PocketNC.hal:10: program 
>>>> '/home/machinekit/machinekit-dev/configs/ARM/BeagleBone/PocketNC/
>>>> setup.bridge.sh' failed, returned 1
>>>> Shutting down and cleaning up Machinekit...
>>>> Cleanup done
>>>> Machinekit terminated with an error.  For simple cases more information
>>>> can be found in the following files:
>>>> /home/machinekit/linuxcnc_debug.txt
>>>> /home/machinekit/linuxcnc_print.txt
>>>>
>>>>
>>>> For other cases get more meaningfull information by restarting after
>>>> export DEBUG=5
>>>>
>>>>
>>>> and look at the output of:
>>>> /var/log/linuxcnc.log
>>>> dmesg
>>>>
>>>>
>>>> When looking for errors, specifically look for libraries that fail to 
>>>> load
>>>> by looking for lines with 'insmod failed' as per example below.
>>>>
>>>>
>>>> insmod failed, returned -1:
>>>> do_load_cmd: dlopen: nonexistant-component.so: cannot open shared 
>>>> object file:
>>>> No such file or directory
>>>>
>>>>
>>>> For getting help, please have a look here: www.machinekit.io/docs/
>>>> getting-help/
>>>>
>>>> I have tried my best to figure this out using the tips in the message 
>>>> above, but couldn't do much. I ran this command 
>>>> <https://forum.linuxcnc.org/media/kunena/attachments/1315/lcnc_dependancies.txt>
>>>>  
>>>> s

Re: [Machinekit] Re: Machinekit on BBB; not all configurations load

[Daren Schwenke]

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 file browser, and then edit that file to 
point to where it actually is.


On Thursday, April 4, 2019 at 9:48:33 AM UTC-4, Sardar Vayghannezgad wrote:
>
> I don't like to come across as one not making the tiniest background 
> attempt at all, but I just don't know how to change the path. :|
>
> [image: Mailtrack] 
> 
>  Sender 
> notified by 
> Mailtrack 
> 
>  04/04/19, 
> 4:43:54 PM 
>
> On Thu, Apr 4, 2019 at 4:31 PM Bas de Bruijn  > wrote:
>
>> Have you changed the path to setup.bridge.sh as Daren pointed out?
>>
>> On 4 Apr 2019, at 15:24, Sardar Vayghannezgad > > wrote:
>>
>> I read online that starting as ssh -Y us...@beaglebone.local 
>>  may help. I am getting this if I start that way:
>> ln: cannot remove '/tmp/linuxcnc.print': Operation not permitted
>> ln: cannot remove '/tmp/linuxcnc.debug': Operation not permitted
>>
>>
>>
>> On Wednesday, April 3, 2019 at 11:19:08 PM UTC+3, Sardar Vayghannezgad 
>> wrote:
>>>
>>> Once I start machinekit on my element14 BBB, the configuration window 
>>> pops up with an array of configurations. But it looks like my favorite one 
>>> won't load. I get the following:
>>>
>>>
>>> machinekit@beaglebone:~$ machinekit
>>> MACHINEKIT - 0.1
>>> Machine configuration directory is 
>>> '/home/machinekit/machinekit/configs/ARM.BeagleBone.PocketNC-1'
>>> Machine configuration file is 'PocketNC.ini'
>>> Starting Machinekit...
>>> rtapi_msgd command:  /usr/libexec/linuxcnc/rtapi_msgd --instance=0 --
>>> rtmsglevel=1 --usrmsglevel=1 --halsize=524288
>>> rtapi_app command:  /usr/libexec/linuxcnc/rtapi_app_rt-preempt --
>>> instance=0
>>> io started
>>> halcmd loadusr io started
>>> PocketNC.hal:10: execv(/home/machinekit/machinekit-dev/configs/ARM/
>>> BeagleBone/PocketNC/setup.bridge.sh): No such file or directory
>>> E: 19-04-03 19:38:58 dangling 'DEALER' socket created at hal/utils/
>>> halcmd_rtapiapp.cc:284
>>> PocketNC.hal:10: program 
>>> '/home/machinekit/machinekit-dev/configs/ARM/BeagleBone/PocketNC/
>>> setup.bridge.sh' failed, returned 1
>>> Shutting down and cleaning up Machinekit...
>>> Cleanup done
>>> Machinekit terminated with an error.  For simple cases more information
>>> can be found in the following files:
>>> /home/machinekit/linuxcnc_debug.txt
>>> /home/machinekit/linuxcnc_print.txt
>>>
>>>
>>> For other cases get more meaningfull information by restarting after
>>> export DEBUG=5
>>>
>>>
>>> and look at the output of:
>>> /var/log/linuxcnc.log
>>> dmesg
>>>
>>>
>>> When looking for errors, specifically look for libraries that fail to 
>>> load
>>> by looking for lines with 'insmod failed' as per example below.
>>>
>>>
>>> insmod failed, returned -1:
>>> do_load_cmd: dlopen: nonexistant-component.so: cannot open shared object 
>>> file:
>>> No such file or directory
>>>
>>>
>>> For getting help, please have a look here: www.machinekit.io/docs/
>>> getting-help/
>>>
>>> I have tried my best to figure this out using the tips in the message 
>>> above, but couldn't do much. I ran this command 
>>> 
>>>  
>>> suggested here 
>>> 
>>>  by 
>>> someone called cncbasher, but didn't help with my case. Likewise, I have 
>>> taken a look here 
>>> and 
>>> there . On the latter, 
>>> step 9 suggests editing something, but I have no inkling how to access that 
>>> or *nano *what. This latter link seems something, can anyone please 
>>> help me edit those lines?
>>>
>>> Thanks.
>>>
>>> -- 
>> 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 machi...@googlegroups.com .
>> Visit this group at https://groups.google.com/group/machinekit.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>

-- 
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+unsubscr...@googlegroups.com.
Visit this group 

[Machinekit] Re: Machinekit on BBB; not all configurations load

[Daren Schwenke]

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/BeagleBone/PocketNC/*setup.
bridge.sh): No such file or directory

On Wednesday, April 3, 2019 at 4:19:08 PM UTC-4, Sardar Vayghannezgad wrote:
>
> Once I start machinekit on my element14 BBB, the configuration window pops 
> up with an array of configurations. But it looks like my favorite one won't 
> load. I get the following:
>
>
> machinekit@beaglebone:~$ machinekit
> MACHINEKIT - 0.1
> Machine configuration directory is 
> '/home/machinekit/machinekit/configs/ARM.BeagleBone.PocketNC-1'
> Machine configuration file is 'PocketNC.ini'
> Starting Machinekit...
> rtapi_msgd command:  /usr/libexec/linuxcnc/rtapi_msgd --instance=0 --
> rtmsglevel=1 --usrmsglevel=1 --halsize=524288
> rtapi_app command:  /usr/libexec/linuxcnc/rtapi_app_rt-preempt --instance=
> 0
> io started
> halcmd loadusr io started
> PocketNC.hal:10: execv(/home/machinekit/machinekit-dev/configs/ARM/
> BeagleBone/PocketNC/setup.bridge.sh): No such file or directory
> E: 19-04-03 19:38:58 dangling 'DEALER' socket created at hal/utils/
> halcmd_rtapiapp.cc:284
> PocketNC.hal:10: program 
> '/home/machinekit/machinekit-dev/configs/ARM/BeagleBone/PocketNC/
> setup.bridge.sh' failed, returned 1
> Shutting down and cleaning up Machinekit...
> Cleanup done
> Machinekit terminated with an error.  For simple cases more information
> can be found in the following files:
> /home/machinekit/linuxcnc_debug.txt
> /home/machinekit/linuxcnc_print.txt
>
>
> For other cases get more meaningfull information by restarting after
> export DEBUG=5
>
>
> and look at the output of:
> /var/log/linuxcnc.log
> dmesg
>
>
> When looking for errors, specifically look for libraries that fail to load
> by looking for lines with 'insmod failed' as per example below.
>
>
> insmod failed, returned -1:
> do_load_cmd: dlopen: nonexistant-component.so: cannot open shared object 
> file:
> No such file or directory
>
>
> For getting help, please have a look here: www.machinekit.io/docs/getting-
> help/
>
> I have tried my best to figure this out using the tips in the message 
> above, but couldn't do much. I ran this command 
> 
>  
> suggested here 
>  
> by 
> someone called cncbasher, but didn't help with my case. Likewise, I have 
> taken a look here 
> and there 
> . On the latter, step 9 
> suggests editing something, but I have no inkling how to access that or *nano 
> *what. This latter link seems something, can anyone please help me edit 
> those lines?
>
> Thanks.
>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Nvidia Jetson Nano

[Daren Schwenke]

That is the backup plan, yes.  I got a pocketbeagle waiting to fill that 
slot if needed.  Hoping it's not.  :)

On Wednesday, March 20, 2019 at 6:51:11 AM UTC-4, ce...@tuta.io wrote:
>
> Theoretically, if you want to use it mainly for the vision and machine 
> learning part, you 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 is 
>> pretty unlikely.
>> Arrow shows 16 weeks.  Sparkfun doesn't have a date.  SeedStudio shows 
>> Apr 12th!
>> Here's hoping...
>> Anyone figured out what monumental tasks would have to take place to run 
>> on Ubuntu 18.04/LTS 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 slot onboard. 
>>> Ok... a lot excited..
>>>
>>>
>>> https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-nano/
>>>
>>> This would be *absolutely perfect* for running OpenCV with the P1 
>>> <https://hackaday.io/project/45404>.
>>>
>>> Now the question becomes... how would one go about getting Machinekit 
>>> running on this?
>>> I know it has 40 pins of gpio and onboard ethernet.
>>> I will design a daughterboard for it.
>>>
>>> Anyone got one already to try it out?  
>>> Supposedly it runs a variant of Ubuntu 18.04 LTS with LTS kernel 4.9.
>>>
>>>
>>>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Nvidia Jetson Nano

[Daren Schwenke]

I guess unless some of you work for Nvidia, someone having one already is 
pretty unlikely.
Arrow shows 16 weeks.  Sparkfun doesn't have a date.  SeedStudio shows Apr 
12th!
Here's hoping...
Anyone figured out what monumental tasks would have to take place to run on 
Ubuntu 18.04/LTS 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 slot onboard. 
> Ok... a lot excited..
>
>
> https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-nano/
>
> This would be *absolutely perfect* for running OpenCV with the P1 
> <https://hackaday.io/project/45404>.
>
> Now the question becomes... how would one go about getting Machinekit 
> running on this?
> I know it has 40 pins of gpio and onboard ethernet.
> I will design a daughterboard for it.
>
> Anyone got one already to try it out?  
> Supposedly it runs a variant of Ubuntu 18.04 LTS with LTS kernel 4.9.
>
>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Nvidia Jetson Nano

[Daren Schwenke]

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/

This would be *absolutely perfect* for running OpenCV with the P1 
.

Now the question becomes... how would one go about getting Machinekit 
running on this?
I know it has 40 pins of gpio and onboard ethernet.
I will design a daughterboard for it.

Anyone got one already to try it out?  
Supposedly it runs a variant of Ubuntu 18.04 LTS with LTS kernel 4.9.


-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Additional axis outside kinematics?

[Daren Schwenke]

Ha... well that would make a difference now wouldn't it.
I'm just a tad lazy in that I don't recall how I built out the environment 
when I compiled my 'I'm at a negative Z' version of tripodkins (which 
doesn't seem to work normally).  
The existing .so I had compiled 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 > 
> wrote:
>
> I'm not sure what that would tell me here, since I'm using tripodkins.  
> I know the additional joints move appropriately when directed to.  It's 
> just that since they are not part of tripodkins, the ABC are not output.
>
>
> Hmm, well, I know that lineardeltakins work with an A Axis, 
> https://github.com/machinekit/machinekit/blob/master/src/emc/kinematics/lineardeltakins-common.h#L89
>
> https://github.com/machinekit/machinekit/blob/master/src/emc/kinematics/lineardeltakins-common.h#L130
>
> So i took a look at the source to see how this would have to work for 
> tripodkins.
> These 3 lines seem to be the problem:
>
> https://github.com/machinekit/machinekit/blob/master/src/emc/kinematics/tripodkins.c#L170
>
>
> I think I'll just setup an M code to feed joint position, assuming that 
> will work.  I just liked the idea of having the 'motion complete' signal of 
> the command returning (after dwell).  
> As it stands with using the M code, I'll have to add the delay myself or 
> add something to wait for the position, at which point modifying tripodkins 
> would 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 01:04, Daren Schwenke  wrote:
>>
>> So am I correct in saying that adding the extra axis to trivkins would 
>> solve the issue also though?
>>
>>
>> I’d try out these kind first:
>>
>> https://github.com/machinekit/machinekit/blob/master/src/emc/kinematics/XYZACkins.c
>>
>> Add the 5th axis but just don’t use it. See of it works.
>>
> -- 
> 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 .
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Additional axis outside kinematics?

[Daren Schwenke]

I'm not sure what that would tell me here, since I'm using tripodkins.  
I know the additional joints move appropriately when directed to.  It's 
just that since they are not part of tripodkins, the ABC are not output.

I think I'll just setup an M code to feed joint position, assuming that 
will work.  I just liked the idea of having the 'motion complete' signal of 
the command returning (after dwell).  
As it stands with using the M code, I'll have to add the delay myself or 
add something to wait for the position, at which point modifying tripodkins 
would 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 01:04, Daren Schwenke > 
> wrote:
>
> So am I correct in saying that adding the extra axis to trivkins would 
> solve the issue also though?
>
>
> I’d try out these kind first:
>
> https://github.com/machinekit/machinekit/blob/master/src/emc/kinematics/XYZACkins.c
>
> Add the 5th axis but just don’t use it. See of it works.
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Additional axis outside kinematics?

[Daren Schwenke]

I think I'll go the M-code route as I know how to do that.  Just means I 
need to re-compile openpnp though (and instruct everyone else to do the 
same), and so I was trying to avoid that bit.
Then again, if I had my way, I'd be using machinetalk and not linuxcncrsh 
also, but time 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 tripodkins doesn't have an A axis normally.  I 
> suppose I could just add ABC as a trivkins 1:1 translation and solve the 
> problem in the source, but I was wondering if there was another way beyond 
> M 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  wrote:
>>
>> No, just respond to G0 A.  It would be better if it wasn't 
>> coordinated actually.
>> I will not be moving both X Y Z and A in the same command right now.
>> For now it will be just G1 X Y Z 
>>  
>> then G1 A 
>> 
>> Eventually I would like to be able to G1 X Y Z, and then now wait for it 
>> to finish and do 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)
>>
>>
>> In your original question you said: 
>>
>> > But It doesn't work though for G0 A0, G1 A180, etc... 
>>
>>
>> What exactly does not work?
>>
>>
>> If you don’t mind an extra step you could set an “analog output” (its a 
>> Hal pin being set by the g-code command. That hal pin you can wire up to 
>> other components) in hal with M67 for example. So a script to change 
>> (sed) “G1 A” to “M67 E0 Q”.
>>
>> As long as the original G-code file is consistent then that might be the 
>> fastest result.
>>
>> Specify the number of analog I/O (end of the line “aio”)
>>
>> https://github.com/luminize/machinekit/blob/experimental-wire/configs/ARM/BeagleBone/BeBoPr-Bridge/wire-extruding/lineardelta-wire-extr.hal#L29
>>
>>
>> https://github.com/luminize/machinekit/blob/experimental-wire/configs/ARM/BeagleBone/BeBoPr-Bridge/wire-extruding/lineardelta-wire-extr.hal#L265
>>
>>
>> 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  wrote: 
>>> > 
>>> > 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 position via setting 
>>> feedrate/max angular velocity. 
>>> > 
>>> > After homing, world mode works fine for X, Y, Z 
>>> > But It doesn't work though for G0 A0, G1 A180, etc... 
>>> > My ini has: 
>>> > 
>>> > AXES = 4 
>>> > COORDINATES = X Y Z A 
>>> > 
>>> > I'm obviously missing something important here. 
>>>
>>> Does your 4th Axis need to be coordinated (motion) with the other 3? 
>>>
>> -- 
>> 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.
>> Visit this group at https://groups.google.com/group/machinekit.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Additional axis outside kinematics?

[Daren Schwenke]

G0 X10, moves to X10 as an MDI command.  G0 A180, does nothing.
I imagine this is because tripodkins doesn't have an A axis normally.  I 
suppose I could just add ABC as a trivkins 1:1 translation and solve the 
problem in the source, but I was wondering if there was another way beyond 
M 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 > 
> wrote:
>
> No, just respond to G0 A.  It would be better if it wasn't 
> coordinated actually.
> I will not be moving both X Y Z and A in the same command right now.
> For now it will be just G1 X Y Z 
>  
> then G1 A 
> 
> Eventually I would like to be able to G1 X Y Z, and then now wait for it 
> to finish and do 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)
>
>
> In your original question you said: 
>
> > But It doesn't work though for G0 A0, G1 A180, etc... 
>
>
> What exactly does not work?
>
>
> If you don’t mind an extra step you could set an “analog output” (its a 
> Hal pin being set by the g-code command. That hal pin you can wire up to 
> other components) in hal with M67 for example. So a script to change 
> (sed) “G1 A” to “M67 E0 Q”.
>
> As long as the original G-code file is consistent then that might be the 
> fastest result.
>
> Specify the number of analog I/O (end of the line “aio”)
>
> https://github.com/luminize/machinekit/blob/experimental-wire/configs/ARM/BeagleBone/BeBoPr-Bridge/wire-extruding/lineardelta-wire-extr.hal#L29
>
>
> https://github.com/luminize/machinekit/blob/experimental-wire/configs/ARM/BeagleBone/BeBoPr-Bridge/wire-extruding/lineardelta-wire-extr.hal#L265
>
>
> 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  wrote: 
>> > 
>> > 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 position via setting 
>> feedrate/max angular velocity. 
>> > 
>> > After homing, world mode works fine for X, Y, Z 
>> > But It doesn't work though for G0 A0, G1 A180, etc... 
>> > My ini has: 
>> > 
>> > AXES = 4 
>> > COORDINATES = X Y Z A 
>> > 
>> > I'm obviously missing something important here. 
>>
>> Does your 4th Axis need to be coordinated (motion) with the other 3? 
>>
> -- 
> 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 .
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Additional axis outside kinematics?

[Daren Schwenke]

No, just respond to G0 A.  It would be better if it wasn't 
coordinated actually.
I will not be moving both X Y Z and A in the same command right now.
For now it will be just G1 X Y Z 
 
then G1 A 

Eventually I would like to be able to G1 X Y Z, and then now wait for it to 
finish and do 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  > wrote: 
> > 
> > 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 position via setting feedrate/max 
> angular velocity. 
> > 
> > After homing, world mode works fine for X, Y, Z 
> > But It doesn't work though for G0 A0, G1 A180, etc... 
> > My ini has: 
> > 
> > AXES = 4 
> > COORDINATES = X Y Z A 
> > 
> > I'm obviously missing something important here. 
>
> Does your 4th Axis need to be coordinated (motion) with the other 3? 
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Additional axis outside kinematics?

[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 position via setting feedrate/max 
angular velocity.

After homing, world mode works fine for X, Y, Z
But It doesn't work though for G0 A0, G1 A180, etc...
My ini has:

AXES = 4
COORDINATES = X Y Z A

I'm obviously missing something important here.

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: RPI high rate GPIO via DMA transfers

[Daren Schwenke]

This is not just DMA fire and forget, the trick here as I understand it is 
he's interleaving (dummy?) transfers using the hardware PWM.  
This has the effect of pacing the individual DMA transfers from the buffer 
out to the pins at a reliable rate.
So, the queue has a reliable timebase, which is independent of the CPU, 
with future timestamps for banging the pins at that future time.

Doing this he was able to get the following performance numbers, with each 
frame being a pin flip (I think), while doing a 1mb/sec network transfer to 
add some contention/load using the same buss.
250k frames per second with max 3us of jitter 
500k frames per second with -3us to +30us of jitter.
800k frames per second max, with lots of jitter.

Beyond my ability to properly implement this, but probably well within most 
of yours.  
He documented it exceptionally well.  Please take a look.

On Sunday, 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/dma-gpio.c
>
> Having DMA handle the GPIO writes removes the CPU from the equation, and 
> his approach of interleaving writes to PWM to provide control of the data 
> transfer rate looks promising, to my under-informed self anyway.
> I think I recall this being discussed before..  Did anyone ever go further 
> with this?
>
> Would it be feasible to feed that from Machinekit?  Reliable high data 
> rate GPIO on the PI could result.
>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] RPI high rate GPIO via DMA transfers

[Daren Schwenke]

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 approach of interleaving writes to PWM to provide control of the data 
transfer rate looks promising, to my under-informed self anyway.
I think I recall this being discussed before..  Did anyone ever go further 
with this?

Would it be feasible to feed that from Machinekit?  Reliable high data rate 
GPIO on the PI could result.

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: RPI gipo help

[Daren Schwenke]

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 
> is my work sheet for what I am trying to achieve
>
> BOBSIGNAL GIPOIN or OUT   RPI PINBINARY
>
> P2 =XPUL= GIPO2  =   OUT  =   3=1
> P3 =XDIR = GIPO3  =   OUT  =   5=1
> P4 =YPUL= GIPO4  =   OUT  =   7=1
> P5 =YDIR = GIPO5  =   OUT  =  29   =1
> P6 =UPUL= GIPO6  =   OUT  =  31   =1
> P7 =UDIR = GIPO7  =   OUT  =  26=1
> P8 =VPUL= GIP08  =   OUT   =  24=1
> P9 =VDIR= GIPO9  =   OUT   =  21=1
> P10=   ESTOP = GIPO10 =   IN =  19=0
> P11=X AXIS LIMIT= GIPO11 =   IN=  23=0
> P12=Y AXIS LIMIT= GIPO12 =   IN=  32=0
> P13=U AXIS LIMIT= GIPO13 =   IN=  33=0
> P14=ENABLE= GIPO14 = OUT  =   8=1
> P15=V AXIS LIMIT= GIPO15 =   IN=  10=0
> P16=BPUL= GIPO16 =OUT=  36=1
> P17=  BDIR/RELAY= GIPO17 =OUT   =  11=1
> P1 =PWM  = GIPO18 =OUT   =  12=1
> GND=   PC GROUND=   ~  =~=   9=~
> PCGND= PC GROUND=   ~=~   =  14=~
> PC5V=  PC 5 VOLT=   ~=~=   2=~
> PC5V=  PC 5 VOLT=   ~   =~ =   4=~
> --
> loadrt hal_gpio dir=0x??
> 1 means output
> 0 means input
>
> you can exclude pins that you will not use
>
> loadrt hal_gpio dir=0x exclude=0x???
> 1 means don't use this pin
> 0 means use this pin
>
> or you can directly write binary numbers in loading hal_gpio comp
> 
>
> #rpi2_gpios[] = {2, 3, 4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15, 16, 
> 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27 };
> #rpi2_pins[] =  {3, 5, 7, 29, 31, 26, 24, 21, 19, 23, 32, 33,  8, 10, 36, 
> 11, 12, 35, 38, 40, 15, 16, 18, 22, 37, 13 };
>
>  dir=0x  1  1  1   1   1   1   1   1   0   0   0   0   1   0   1   
> 1   1   0   0   0   0   0   0   0   0   0  
>  exclude=0  0  0   0   0   0   0   0   0   0   0   0   0   0   0   
> 0   0   1   1   1   1   1   1   1   1   
> 1
> 
> #commandline
> echo 'ibase=2;A;101110' | bc
> 10
> 66858496
>
> echo 'ibase=2;A;01' | bc
> 10
> 511
> --
> #For my BOB
> loadrt hal_gpio dir=0x101110 
> exclude=0x01
> or
> loadrt hal_gpio dir=66858496 exclude=511
>
> --
>
> To get pins to show as all outputs I use:
> loadrt hal_gipo
>
> I am running Raspbian Jessie this is a new install of OS the output for 
> dmesg is as follows
>
> pi@raspberrypi:~ $ machinekit
> MACHINEKIT - 0.1
> Machine configuration directory is '/home/pi/machinekit/configs/my-foam'
> Machine configuration file is 'my-foam.ini'
> Starting Machinekit...
> rtapi_msgd command:  /usr/libexec/linuxcnc/rtapi_msgd --instance=0 
> --rtmsglevel=1 --usrmsglevel=1 --halsize=524288
> rtapi_app command:  /usr/libexec/linuxcnc/rtapi_app_rt-preempt --instance=0
> io started
> halcmd loadusr io started
> standard_pinout.hal:25: Pin 'hal_gpio.pin-03-out' does not exist
> Shutting down and cleaning up Machinekit...
> Cleanup done
> Machinekit terminated with an error.  You can find more information in the 
> log:
> /home/pi/linuxcnc_debug.txt
> and
> /home/pi/linuxcnc_print.txt
> as well as in the output of the shell command 'dmesg' and in the terminal
> pi@raspberrypi:~ $ dmesg
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Linux version 4.14.43-rt31-rc1-v7+ (pi@raspberrypi) (gcc 
> version 4.9.2 (Raspbian 4.9.2-10+deb8u1)) #1 SMP PREEMPT RT Mon Jun 11 
> 01:27:42 EDT 2018
> [0.00] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), 
> cr=10c5383d
> [0.00] CPU: div instructions available: patching division code
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [0.00] OF: fdt: Machine model: Raspberry Pi 3 Model B Rev 1.2
> [0.00] Memory policy: Data cache writealloc
> [0.00] cma: Reserved 8 MiB at 0x3a80
> [0.00] On node 0 totalpages: 241664
> [0.00] free_area_init_node: node 0, pgdat 80c898c0, node_mem_map 
> b9faa000
> [0.00]   Normal zone: 2124 pages used for memmap
> [   

[Machinekit] Re: NGCWriter is now in Cura Plugin Repository

[Daren Schwenke]

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... 
>
> The plugin generates Machinekit + Velocity Extrusion compatible ngc 
> GCode. 
>
> -- 
> Alexander 
>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Gcode from remote source

[Daren Schwenke]

Someone has already done this, but it's kinda old and not the best way.  
OpenPNP doesn't work by transferring files btw... it's a streams interface 
similar to spoon feeding a dumb 3D printer...as the next command depends on 
the output of previous ones.

Alexander and I have previously discussed a better integration strategy but 
I have not gotten around to implementing any of it.
I had also planned to use Machinekit for this: 
https://hackaday.io/project/45404-arcus-3d-p1-pnp-for-3d-printers
So you are a little early to the party, but it will get going soon.


On Friday, April 6, 2018 at 5:02:41 AM UTC-4, Marius Liebenberg wrote:
>
> I would like to use MK on PocketBeagle to drive n solder paste applicator. 
> The commands are sent to the controller from OpenPnp via Gcode or custom 
> messages. I might have to write a custom component to connect to OpenPnp
>
> 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.
>> The latter is what is used for Machineface and Cetus.  I use Machineface 
>> for running my machine from my tablet.  
>> File transfers are built in then.
>>
>> On Thursday, April 5, 2018 at 10:09:53 AM UTC-4, Marius Liebenberg wrote:
>>>
>>> Hi
>>> I am planning on using a PocketBeagle for a project that will require 
>>> some Gcode to be sent to the controller via USB. What mechanism is provided 
>>> in MK to do this if any?
>>>
>>>
>>>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Gcode from remote source

[Daren Schwenke]

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 built in then.

On Thursday, April 5, 2018 at 10:09:53 AM UTC-4, Marius Liebenberg wrote:
>
> Hi
> I am planning on using a PocketBeagle for a project that will require some 
> Gcode to be sent to the controller via USB. What mechanism is provided in 
> MK to do this if any?
>
>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: mach3 interface board 5 axis

[Daren Schwenke]

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 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 chips from ran at 3.3v.
>
> On Monday, February 26, 2018 at 4:30:25 PM UTC-5, Andrij Senyk wrote:
>>
>> Hello,
>>
>> I have this one mach3 interface board 5 axis
>>
>> https://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=2ahUKEwi25KzywsTZAhXKliwKHXBgAK0QjRx6BAgAEAY&url=https%3A%2F%2Fwww.aliexpress.com%2Fitem%2FCNC-5-Axis-With-Optocoupler-Adapter-Stepper-Motor-Driver-MACH3-Interface-Board%2F1975186212.html&psig=AOvVaw2ExyVfNS9tou9jF77cLINW&ust=1519766863377451
>>
>> Its possible to connect to BBB without capes? That board have optocoupler.
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: mach3 interface board 5 axis

[Daren Schwenke]

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 chips from ran at 3.3v.

On Monday, February 26, 2018 at 4:30:25 PM UTC-5, Andrij Senyk wrote:
>
> Hello,
>
> I have this one mach3 interface board 5 axis
>
> https://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=2ahUKEwi25KzywsTZAhXKliwKHXBgAK0QjRx6BAgAEAY&url=https%3A%2F%2Fwww.aliexpress.com%2Fitem%2FCNC-5-Axis-With-Optocoupler-Adapter-Stepper-Motor-Driver-MACH3-Interface-Board%2F1975186212.html&psig=AOvVaw2ExyVfNS9tou9jF77cLINW&ust=1519766863377451
>
> Its possible to connect to BBB without capes? That board have optocoupler.
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Can MK read g-code from serial port?

[Daren Schwenke]

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 you have access to a couple layers below the simple TTY if you 
want it, so things are generally setup a little differently and it works 
better in the end.

On Monday, February 26, 2018 at 1:29:29 PM UTC-5, Chris Albertson wrote:

> Is there an easy way to get MK to read g-code lines one at a time from a 
> serial port?  That means to read a code, then execute it right aways that 
> wait for another g-code.
>
> The reason I ask is I was thinking the best way to make a hand help 
> pendent or controller is to have the controller send g-code.   It I won't 
> to jog and axis or do just about anything it can be sent over an 2 wire 
> connection.
>
> The controller I want to make will have a physical rotary encoder with 100 
> division and some push buttons and an LCD screen.  But I can envision doing 
> this also on an Android tablet.  The jog wheel and DRO are on screen. 
>  g-code seems the natural method of interface.
>
> Marlin, the software that runs on most 3D printers does this.  It reads 
> g-code from a USB port, building a hand held controller for Marlin is 
> simple, just send g-codes.   I'd like to do the same with MK.  And use the 
> same hand controller for both
>
>
> -- 
>
> Chris Albertson
> Redondo Beach, California
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Slow to start machinekit installed BBG (Linux beaglebone 4.14.16-ti-rt-r30 #1 SMP PREEMPT RT)

[Daren Schwenke]

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.

On Thursday, February 8, 2018 at 6:40:05 PM UTC-5, bigwexi wrote:
>
> Hi,
>
> My BeagleBone Green boots fast with ordinary debian image but gets hung up 
> (temporarily) with the latest machinekit image:
>
> $ uname -a 
> Linux beaglebone 4.14.16-ti-rt-r30 #1 SMP PREEMPT RT Fri Feb 2 01:57:30 
> UTC 2018
> armv7l GNU/Linux
>
> Any thoughts?
>
> Thanks, Enoch.
>
>
> Starting kernel ... 
>
> [0.002144] timer_probe: no matching timers found 
> [0.687891] dmi: Firmware registration failed. 
> [1.563486] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc 
> handle 
> [1.999097] omap_voltage_late_init: Voltage driver support not added 
>
>
>
>
> [FAILED] Failed to start Load Kernel Modules. 
> See 'systemctl status systemd-modules-load.service' for details. 
>
>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: BiggleBone Red from element 14 and Machinekit with furaday cape

[Daren Schwenke]

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, 2018 at 9:28:03 AM UTC-5, Moi Toi wrote:
>
> Hi
>
> The problem is i have the same issue with official release from elinux
>
> i don't understand other topic.
>
> Thanks for reply
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: BiggleBone Red from element 14 and Machinekit with furaday cape

[Daren Schwenke]

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 these changes.
I don't have a system up to remind me of the changes required right now, 
but search this forum and you should find them.

It may be easier to just use the machinekit image and remove or disable the 
startup of X.
Unless it is installed to the eMMC or the eMMC is wiped, you could still 
have the same issue though as files in multiple locations still affect this 
even when you are booting from flash.

On Saturday, January 27, 2018 at 7:45:54 AM UTC-5, Moi Toi wrote:
>
> Hi
>
> Many thanks for reply
>
> I try to understand how to merge your code to run.py but for now i do not 
> understand lol, i'm newbee with linux and python.
>
> That i understand is need to make something like your code do line 48 to 
> 61 when call "launcher.load_bbio_file('furaday_stepgen.bbio')" basically 
> need to add some delay before or after calling bbio ?
>
> Can you post your complet furaday config files ?
>
> I have attached config files provided by author.
>
> Thanks at all
>
>
>
>
> Le samedi 27 janvier 2018 00:36:37 UTC+1, Moi Toi a écrit :
>>
>> Hi all
>>
>> I try to start machinekit with fresh debian instal after many test i 
>> can't have machinekit starting, i have allways same error
>>
>>  i try to start machinekit with furaday cape files
>> actually with a debian release provided and tested by furaday author on 
>> beaglebone black
>> debian release is made without x11 so we try to execute machinekit 
>> remotely with client (but i have same issue with lxde)
>> for start program i need to execute a python script with the command 
>> ./run.py
>> and the error is
>> ./run.py
>> loading furaday_stepgen.bbio... cape-universal already loaded
>> Loading cape-bone-iio overlay
>> bash: line 0: echo: write error: No such file or directory
>> Error loading device tree overlay file: cape-bone-iio
>>
>>
>> Tha author try to help me without success so if you have any suggestion 
>> this is greatly appreciated !
>>
>>
>> Many thanks, best regards
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: BB-blue BB-enhanced : machinekit and stepper compatibility ?

[Daren Schwenke]

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 functionality as you 
will have to disable one of the devices, or in the best case if one of the 
overlapping pins are not required, just that one pin.

The leadshine stepper driver 

 
requires 7-16mA to drive it.  The Beaglebone should not be asked to drive 
pins above 4mA.  
You will need a cape or at the very least a logic level converter chip to 
drive that reliably.

On Sunday, January 28, 2018 at 5:43:43 AM UTC-5, Moi Toi wrote:
>
> Hi
>
> I have too many problem with industrial version from element14 so i check 
> for other choice.
>
>
> It is possible with Beaglebone-blue to control motor stepper driver like 
> leadshine dm556 ?
>
> Also for this use, machinekit can work fine with this board ?
>
>
> Is Beaglebone enhanced work fine with machinekit and standard cape ?
>
>
> Best regards.
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: CRAMPS Stepper board problem not sure

[Daren Schwenke]

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 down at that point.
Were you moving the head directly away from one tower and in between the 
other two at the time?  That would cause a following error as the forward 
and reverse kinematics functions fail to agree then.

>
> What setting would correct this?
>
> Thanks gary
>
> On Friday, January 26, 2018 at 2:40:23 PM UTC-5, gary wrote:
>
>> I had my cramps wired and configured but had problems with the mcodes so 
>> disconnected it
>> and put back my bebopr board and figured out what i was doing wrong..
>>
>> Now i put back the cramps and reconnected it but i am having stepper 
>> motor problems
>> as soon as i plug the board in to 12v the motors lockup and not when i 
>>  hit the power or estop buttons in machinekit
>>
>> i can't get any motor movement no homing nothing, before i 
>> disconnected the cramps, the motors would only lock when i hit the power 
>> estop buttons
>> in machinekit gui screen.
>>
>> i didn't change any thing with the wiring or connectors all is the same 
>> as before i disconnected it
>>
>> I get power to the stepper drives adjustment screws and can adjust them ok
>>
>> didn't change any jumpers on the board..
>>
>> thanks for any suggestions
>> Gary
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: BBB and new cramps board delta homing problems

[Daren Schwenke]

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 setting up Velocity extrusion configs when i was working with 
> the BeBoPr++ was close to having it working but hit a point i couldn't get 
> past guess it was over my head skill level...
>
> Gary
>
> On Saturday, January 6, 2018 at 8:42:16 PM UTC-5, gary wrote:
>
>> I just connected a BBB and Cramps board to my delta printer, but i have 
>> been having homing problem
>> I have optic switches installed if i go into the hal configuration when 
>> machinekit it booted, and then to the show  window with xmax ymax and zmax 
>> displayed  then when axis's are off the switches there red, and when i 
>> trigger the switches they turn yellow
>> So i assume the switches are working and being read by the software.
>>
>> But when i do home all the motors they move up to the switches in the 
>> correct direction but never stop just keeps running into the optic 
>> end stops and i have to power down..
>>
>> any suggestions?
>>
>> Thanks gary
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: BBB and new cramps board delta homing problems

[Daren Schwenke]

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 
> net e0.temp.set => pid.0.command
> to this
> net e0.temp.set motion.analog-out-01=> pid.0.command
> to get it to work with the m104 halcmd sets e0,temp.set macro
> or something close its been a while and really not totally sure how i did 
> it way back when i started..
>
> but didn't seen to work with the cramps board
>
> I am getting a different error with the macro now, shell script unsigned 
> int 
>
> Not being a programmer its a little tough figuring all this out..
> I hate to give up on it now seeing its close to the last thing i need to 
> get running, I spent a lot of time getting all the axis's calibrated and 
> extruder.
>
Those numbers will transfer nicely.  Just make sure to keep them. 

> but if i can't get the macros working it's not going to work, and i will 
> have to switch to a different controller again..
>
> Thanks gary
>
> I think you started this the hard way.  :)  
Probably good for learning, but not as good for just getting things working.
Velocity extrusion configs would likely be easier to adapt, but they are 
also generally designed to work with machinetalk for a remote interface and 
use the newer pythonic configuration style. 

> On Saturday, January 6, 2018 at 8:42:16 PM UTC-5, gary wrote:
>
>> I just connected a BBB and Cramps board to my delta printer, but i have 
>> been having homing problem
>> I have optic switches installed if i go into the hal configuration when 
>> machinekit it booted, and then to the show  window with xmax ymax and zmax 
>> displayed  then when axis's are off the switches there red, and when i 
>> trigger the switches they turn yellow
>> So i assume the switches are working and being read by the software.
>>
>> But when i do home all the motors they move up to the switches in the 
>> correct direction but never stop just keeps running into the optic 
>> end stops and i have to power down..
>>
>> any suggestions?
>>
>> Thanks gary
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: BBB and new cramps board delta homing problems

[Daren Schwenke]

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/e2052ae8a8e982ce8a7bdb0a3afd0f36dde12aa3/arcus-3d-c1.ini#L73

However, that config also uses velocity extrusion, tripodkins, and a custom 
pin map for the Beaglebone (not CRAMPS, and not really BeBoPr either)..
But you may be able to garner something out of it.

On Wednesday, January 17, 2018 at 7:53:28 PM UTC-5, gary wrote:
>
> I assume no one is using m104 or m109, and don't have any suggestions..
>
> if i do a halcmd sets e0.temp.set 150 it will set the temp and it will 
> rise up to 150 and hold within a degree or so.. so i know the hot end is 
> working..
>
> in a very old version of machinekit i did a m104 and used the
>  #!/bin/sh
>  halcmd sets e0.temp.set #P
> exit 0  and it worked
>
> but now it seems if you don't have the o<104> you get the error o word 
> missing 
> and when i use the command in a sub with o<104> i get the error unknown a  
>
> Any thoughts.
>
> On Saturday, January 6, 2018 at 8:42:16 PM UTC-5, gary wrote:
>
>> I just connected a BBB and Cramps board to my delta printer, but i have 
>> been having homing problem
>> I have optic switches installed if i go into the hal configuration when 
>> machinekit it booted, and then to the show  window with xmax ymax and zmax 
>> displayed  then when axis's are off the switches there red, and when i 
>> trigger the switches they turn yellow
>> So i assume the switches are working and being read by the software.
>>
>> But when i do home all the motors they move up to the switches in the 
>> correct direction but never stop just keeps running into the optic 
>> end stops and i have to power down..
>>
>> any suggestions?
>>
>> Thanks gary
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: BBB and new cramps board delta homing problems

[Daren Schwenke]

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 never had as good of results with trying 
to do it that way.
Once you got the corners set to be all the same you are 80% done anyway.  
Just changing it bit by bit seems to work the best.

>
> I have the 3 corners set so there is slight drag on paper, now the center 
> is 0.5 above 0.0.
>
> Thanks gary  
>
> On Saturday, January 6, 2018 at 8:42:16 PM UTC-5, gary wrote:
>
>> I just connected a BBB and Cramps board to my delta printer, but i have 
>> been having homing problem
>> I have optic switches installed if i go into the hal configuration when 
>> machinekit it booted, and then to the show  window with xmax ymax and zmax 
>> displayed  then when axis's are off the switches there red, and when i 
>> trigger the switches they turn yellow
>> So i assume the switches are working and being read by the software.
>>
>> But when i do home all the motors they move up to the switches in the 
>> correct direction but never stop just keeps running into the optic 
>> end stops and i have to power down..
>>
>> any suggestions?
>>
>> Thanks gary
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: BBB and new cramps board delta homing problems

[Daren Schwenke]

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 the radius to figure the distance i 
> need to change it after all corners are done?
>
> I have the 3 corners set so there is slight drag on paper, now the center 
> is 0.5 above 0.0.
>
> Thanks gary  
>
> On Saturday, January 6, 2018 at 8:42:16 PM UTC-5, gary wrote:
>
>> I just connected a BBB and Cramps board to my delta printer, but i have 
>> been having homing problem
>> I have optic switches installed if i go into the hal configuration when 
>> machinekit it booted, and then to the show  window with xmax ymax and zmax 
>> displayed  then when axis's are off the switches there red, and when i 
>> trigger the switches they turn yellow
>> So i assume the switches are working and being read by the software.
>>
>> But when i do home all the motors they move up to the switches in the 
>> correct direction but never stop just keeps running into the optic 
>> end stops and i have to power down..
>>
>> any suggestions?
>>
>> Thanks gary
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: BBB and new cramps board delta homing problems

[Daren Schwenke]

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 
> calibrating the corners and center setting position to 0 or to the max for 
> each axis,,
> anyone have the correct commands so i don't have to keep changing the 
> config at least till i have them all figured out.
>
You can set offsets per axis for calibrating without shutting down, and 
then when you are done, transfer them to offets from home.  
About half way down, look for "Use of debug pins in kinematics" here:
http://www.machinekit.io/docs/setting-up/lineardelta-FDM-printer/
 

>
> Thanks gary
>
> On Saturday, January 6, 2018 at 8:42:16 PM UTC-5, gary wrote:
>
>> I just connected a BBB and Cramps board to my delta printer, but i have 
>> been having homing problem
>> I have optic switches installed if i go into the hal configuration when 
>> machinekit it booted, and then to the show  window with xmax ymax and zmax 
>> displayed  then when axis's are off the switches there red, and when i 
>> trigger the switches they turn yellow
>> So i assume the switches are working and being read by the software.
>>
>> But when i do home all the motors they move up to the switches in the 
>> correct direction but never stop just keeps running into the optic 
>> end stops and i have to power down..
>>
>> any suggestions?
>>
>> Thanks gary
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: BBB and new cramps board delta homing problems

[Daren Schwenke]

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" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: beaglebone black lcd cape + machinekit working together

[Daren Schwenke]

Very possible you are stepping on some of the CRAMPS pins with your lcd 
cape.  Yes.
Provided you don't step on something important, you can just comment those 
pins out everywhere in your bbio and other files, and move on for now.
Reference for the pins: 
https://github.com/cdsteinkuehler/bobc_hardware/blob/CRAMPS-v2.2.1/CRAMPS/CRAMPS.pdf?raw=true

P8_08 looks like the X min endstop so that's a good candidate for 
commenting out.

On Sunday, December 31, 2017 at 5:31:16 AM UTC-5, Cyrus wrote:
>
> Hi,
>
> I had already used these instructions to setup machinekit on the BBB with 
> debian stretch. I had to modify them as the instructions were for a non-gui 
> based setup.
> I have since realised that only some of the configurations have been 
> updated to use the .bbio file structure rather than the setup.sh. This is 
> why I was still trying to use setup.sh with the new kernel (as that was the 
> default in the cramps config after following the tutorial, so I thought it 
> was still used). I have now replaced the setup.sh with a .bbio file, and 
> updated the hal file to reference it. But I am still getting some errors, 
> possibly because I am using an lcd cape rather than hdmi. I think the lcd 
> cape may be conflicting with the universal overlay. 
>
> Error: 
> P8_08 pinmux file not found.
> Warnings: gpio not exported, cannot set directional value
> Cannot write pinmux file: /sys/devices/platform/ocp/ocp*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 Sunday, December 31, 2017 at 8:58:23 AM UTC, Daren Schwenke wrote:
>>
>> 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 machinekit image with kernel 3.8.13, the 
>>> backlight works, but nothing else (and I have read there may be a bug in 
>>> 3.8 to do with lcd capes). I can login via ssh, and it seems otherwise ok. 
>>> I then tried using the 4.4.91-ti-rt-r141 kernel (on debian stretch), 
>>> where the screen works fine, but I get errors when opening machinekit. I 
>>> have found many posts hinting at how to fix these errors, but I found it 
>>> hard to identify exactly what to do to fix them. 
>>>
>>> Error 1: 
>>> grep: /sys/devices/bone_capemgr.*/slots: no such file or directory
>>> Solution: I think I need to comment out 
>>> the SLOTS=/sys/devices/bone_capemgr.*/slots line in setup.sh as the capes 
>>> are managed differently in this later kernel so that file no longer exists.
>>> However, the SLOTS variable is mentioned in code below this line and I 
>>> think this gives another error.
>>>
>>> Error 2: 
>>> sudo: no askpass program specified, try setting SUDO_ASKPASS
>>> Error loading device tree overlay file: BB-LCNC-BEBOPR
>>> I then tried commenting out the whole section referring to SLOTS in the 
>>> setup.sh, but the next section of code gives errors. 
>>>
>>> Error 3:
>>> Analog input files not found in /sys/devices/ocp.*/helper.*
>>> I think this is something to do with the files moving to another 
>>> directory (iio?), but I'm not sure what to change here.
>>>
>>> I have tried all sorts of things from many page, and am at a loss for 
>>> how to get it working.
>>>
>>> Could anyone help either with getting the lcd touchscreen cape working 
>>> on 3.8.x or getting machinekit working on 4.4.x?
>>>
>>> Please let me know any output/ other details that would help to answer 
>>> the question.
>>>
>>> Thank you
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: beaglebone black lcd cape + machinekit working together

[Daren Schwenke]

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 machinekit image with kernel 3.8.13, the 
> backlight works, but nothing else (and I have read there may be a bug in 
> 3.8 to do with lcd capes). I can login via ssh, and it seems otherwise ok. 
> I then tried using the 4.4.91-ti-rt-r141 kernel (on debian stretch), where 
> the screen works fine, but I get errors when opening machinekit. I have 
> found many posts hinting at how to fix these errors, but I found it hard to 
> identify exactly what to do to fix them. 
>
> Error 1: 
> grep: /sys/devices/bone_capemgr.*/slots: no such file or directory
> Solution: I think I need to comment out 
> the SLOTS=/sys/devices/bone_capemgr.*/slots line in setup.sh as the capes 
> are managed differently in this later kernel so that file no longer exists.
> However, the SLOTS variable is mentioned in code below this line and I 
> think this gives another error.
>
> Error 2: 
> sudo: no askpass program specified, try setting SUDO_ASKPASS
> Error loading device tree overlay file: BB-LCNC-BEBOPR
> I then tried commenting out the whole section referring to SLOTS in the 
> setup.sh, but the next section of code gives errors. 
>
> Error 3:
> Analog input files not found in /sys/devices/ocp.*/helper.*
> I think this is something to do with the files moving to another directory 
> (iio?), but I'm not sure what to change here.
>
> I have tried all sorts of things from many page, and am at a loss for how 
> to get it working.
>
> Could anyone help either with getting the lcd touchscreen cape working on 
> 3.8.x or getting machinekit working on 4.4.x?
>
> Please let me know any output/ other details that would help to answer the 
> question.
>
> Thank you
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Machinekit + Debian Stretch on the BeagleBone Black

[Daren Schwenke]

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 understand.  Thanks very much 
> indeed Alexander ! 
>
> A small noob question here though - can you skip the step of flashing to 
> the EMMC and just set everything up to run on the SD card ? Or will it 
> cause a tear in the fabric of space and time ?
>
> Cheers,
> Lewis
>
>
> On Tuesday, December 5, 2017 at 4:51:57 PM UTC-4, Alexander Rössler wrote:
>>
>> I just published a write-up on how to create a Machinekit image with 
>> Debian Stretch for the BeagleBone Black: 
>>
>> https://machinekoder.com/machinekit-debian-stretch-beaglebone-black/ 
>>
>> I hope you find it useful. 
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Machinekit + Debian Stretch on the BeagleBone Black

[Daren Schwenke]

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, Alexander Rössler wrote:
>
> I just published a write-up on how to create a Machinekit image with 
> Debian Stretch for the BeagleBone Black: 
>
> https://machinekoder.com/machinekit-debian-stretch-beaglebone-black/ 
>
> I hope you find it useful. 
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Inverted tripodkins

[Daren Schwenke]

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 resulting position Z position is still 
> positive, and kinematics is still not inverted.
> If you are like me, you probably didn't even know there was a HOME under 
> TRAJ, cause it's ignored for trivial kinematics, and not used for many 
> others.
> I followed the value though, and it does still end up getting used:
>
> https://github.com/machinekit/machinekit/blob/314246595127ddc2dc08bb0f8a9e8606260e1679/src/emc/ini/initraj.cc#L230
>
> Setting the [AXIS] HOME positions negative always results in immediate 
> following errors.  I suppose negative length arms doesn't make any sense.
>
> Flipping one or more of the tripodkins.Bx,Cx or Cy values ends up 
> inverting some axis, but not Z.
>
> If no-one has any ideas, I'll just make a new kinematics module which is 
> always inverted.  Seems like a waste though.
>
Did this, it works now.  
This taught me how far off I really was on some of my parameters.  Way 
off...
Maybe far enough off to cause tripodkins to not invert on it's own.   
Perhaps.

>
> 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/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 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 towards the 
>>> bed causes the steppers go slower as they are further from the bed.  For 
>>> the same vertical rate, I believe the opposite should be happening.
>>>
>>> Best I saw online, anywhere for reference was this: 
>>> https://psha.org.ru/irc/%23emc/2006-07-09.html
>>> I implemented that and it works, but of course it ends up not inverted.
>>>
>>> https://github.com/Arcus-3d/Arcus-3D-C1-BeBoPr/commit/c70258aeaa05a42f8b93c55bf4b650db19091e4c
>>>
>>> I see a flag in the code for being inverted, which* looks like it's 
>>> triggered by negative Z* from the other kins.
>>>
>>>
>>>  <https://groups.google.com/forum/goog_563650889>
>>>
>>> https://github.com/machinekit/machinekit/blob/314246595127ddc2dc08bb0f8a9e8606260e1679/src/emc/kinematics/tripodkins.c#L167
>>>
>>>
>>>
>>>
>>> So I've tried changing the signs of various things for a solid day in my 
>>> ini in an attempt to get it inverted, but haven't had any luck yet.
>>> Some result in joint following errors, some result in negative axis 
>>> values, but none seem to invert the kinematics.
>>>
>>> Short of re-compiling to manually flip it in the source, some guidance 
>>> would be appreciated.
>>>
>>>
>>>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Inverted tripodkins

[Daren Schwenke]

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 resulting position Z position is still 
positive, and kinematics is still not inverted.
If you are like me, you probably didn't even know there was a HOME under 
TRAJ, cause it's ignored for trivial kinematics, and not used for many 
others.
I followed the value though, and it does still end up getting used:
https://github.com/machinekit/machinekit/blob/314246595127ddc2dc08bb0f8a9e8606260e1679/src/emc/ini/initraj.cc#L230

Setting the [AXIS] HOME positions negative always results in immediate 
following errors.  I suppose negative length arms doesn't make any sense.

Flipping one or more of the tripodkins.Bx,Cx or Cy values ends up inverting 
some axis, but not Z.

If no-one has 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/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 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 towards the 
>> bed causes the steppers go slower as they are further from the bed.  For 
>> the same vertical rate, I believe the opposite should be happening.
>>
>> Best I saw online, anywhere for reference was this: 
>> https://psha.org.ru/irc/%23emc/2006-07-09.html
>> I implemented that and it works, but of course it ends up not inverted.
>>
>> https://github.com/Arcus-3d/Arcus-3D-C1-BeBoPr/commit/c70258aeaa05a42f8b93c55bf4b650db19091e4c
>>
>> I see a flag in the code for being inverted, which* looks like it's 
>> triggered by negative Z* from the other kins.
>>
>>
>>  <https://groups.google.com/forum/goog_563650889>
>>
>> https://github.com/machinekit/machinekit/blob/314246595127ddc2dc08bb0f8a9e8606260e1679/src/emc/kinematics/tripodkins.c#L167
>>
>>
>>
>>
>> So I've tried changing the signs of various things for a solid day in my 
>> ini in an attempt to get it inverted, but haven't had any luck yet.
>> Some result in joint following errors, some result in negative axis 
>> values, but none seem to invert the kinematics.
>>
>> Short of re-compiling to manually flip it in the source, some guidance 
>> would be appreciated.
>>
>>
>>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: PRU/stepgen bug? keeps generating pulses once position-cmd reached

[Daren Schwenke]

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 the Machinekit image from 
> https://rcn-ee.com/rootfs/bb.org/testing/2017-11-02/machinekit/
>
> When I move the axis from the manual control interface, the move got 
> executed successfully and as expected but right after it completes and 
> reaches the expected position, stepgen keeps generating some random signal 
> on step (and dir) pin and my stepper motor move doing some weird noise and 
> missing steps because velocity is not controlled properly (random signal at 
> random frequency).
>
> From the HAL meter&scope I can see that:
>
>- after the move complete: stepgen.00.position-cmd == 
>stepgen.00.position-fb and stay stable
>- stepgen.00.test1 stabilizes at the end the deceleration/move and 
>then gets crazy (see HAL scope screeshot)
>- stepgen.00.test2 reaches the end of position expected value and 
>oscillate around p and p+1 (p being the expected position). From what I 
>understand from the source code 
>
> ,
>  
>this is the internal PRU position value that is used to calculate/generate 
>step/dir outputs.
>- stepgen.00.dbg_err_at_match oscillates between something like -1e-07 
>and 6e-08 (very small values)
>- stepgen.00.dbg_pos_minus_prev_cmd oscillates between -1.15e-07 and 
>3.68e-08 (very small values)
>- stepgen.00.dbg_s_to_match oscillates between 1.1e-07 and 6.7e-07 
>(very small values)
>- stepgen.00.dbg_step_rate oscillates between -8, 1, 2 and 4
>
>
> My HAL for this axis look like:
>
> # axis enable chain
> newsig emcmot.00.enable bit
> sets emcmot.00.enable FALSE
>
> net emcmot.00.enable <= axis.0.amp-enable-out
> net emcmot.00.enable => hpg.stepgen.00.enable
>
> # position command and feedback
> net emcmot.00.pos-cmd <= axis.0.motor-pos-cmd
> net emcmot.00.pos-cmd => hpg.stepgen.00.position-cmd
>
> net motor.00.pos-fb <= hpg.stepgen.00.position-fb
> net motor.00.pos-fb => axis.0.motor-pos-fb
>
> # timing parameters
> setp hpg.stepgen.00.dirsetup200
> setp hpg.stepgen.00.dirhold 200
> setp hpg.stepgen.00.steplen 1000
> setp hpg.stepgen.00.stepspace   1000
>
> setp hpg.stepgen.00.position-scale  -100
>
> setp hpg.stepgen.00.maxvel  240.0
> setp hpg.stepgen.00.maxaccel90.0
>
> # P8.15 GPIO47
> setp hpg.stepgen.00.steppin 0x4F
> # P8.14 GPIO26
> setp hpg.stepgen.00.dirpin  0x3A
>
> and relevant parts from INI file:
>
> DRIVER=hal_pru_generic
> CONFIG=pru=1 num_stepgens=2 pru_period=1
> PRUBIN=xenomai/pru_generic.bin
>
>
> This issue happens even for quite low steps frequency: ~1500 step/s in the 
> HAL scope screenshot so I think it is something that the PRU can easily 
> handle especially that in this current example I only have 2stepgens 
> running on the PRU and nothing else.
>
>
> It seems to me some kind of overflow issue but I still don't understand 
> why stepgen keep generating pulses when stepgen.00.position-cmd and 
> stepgen.00.position-fb do not change and are equals..
>
> I obviously need to undertand and fix that if I don't what the crash the 
> axis of my CNC machine because of this software issue.
>
>
> Is there some max/min values to consider for velocity/acceleration when 
> writting the HAL file?
>
>
> Does anyone has any path/idea to suggest me to continue investigations?
>
> Thanks by advance,
>
> /Damien
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Inverted tripodkins

[Daren Schwenke]

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 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 towards the 
> bed causes the steppers go slower as they are further from the bed.  For 
> the same vertical rate, I believe the opposite should be happening.
>
> Best I saw online, anywhere for reference was this: 
> https://psha.org.ru/irc/%23emc/2006-07-09.html
> I implemented that and it works, but of course it ends up not inverted.
>
> https://github.com/Arcus-3d/Arcus-3D-C1-BeBoPr/commit/c70258aeaa05a42f8b93c55bf4b650db19091e4c
>
> I see a flag in the code for being inverted, which* looks like it's 
> triggered by negative Z* from the other kins.
>
>
>  <https://groups.google.com/forum/goog_563650889>
>
> https://github.com/machinekit/machinekit/blob/314246595127ddc2dc08bb0f8a9e8606260e1679/src/emc/kinematics/tripodkins.c#L167
>
>
>
>
> So I've tried changing the signs of various things for a solid day in my 
> ini in an attempt to get it inverted, but haven't had any luck yet.
> Some result in joint following errors, some result in negative axis 
> values, but none seem to invert the kinematics.
>
> Short of re-compiling to manually flip it in the source, some guidance 
> would be appreciated.
>
>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Inverted tripodkins

[Daren Schwenke]

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 towards the 
bed causes the steppers go slower as they are further from the bed.  For 
the same vertical rate, I believe the opposite should be happening.

Best I saw online, anywhere for reference was this: 
https://psha.org.ru/irc/%23emc/2006-07-09.html
I implemented that and it works, but of course it ends up not inverted.
https://github.com/Arcus-3d/Arcus-3D-C1-BeBoPr/commit/c70258aeaa05a42f8b93c55bf4b650db19091e4c

I see a flag in the code for being inverted, which* looks like it's 
triggered by negative Z* from the other kins.


 

https://github.com/machinekit/machinekit/blob/314246595127ddc2dc08bb0f8a9e8606260e1679/src/emc/kinematics/tripodkins.c#L167




So I've tried changing the signs of various things for a solid day in my 
ini in an attempt to get it inverted, but haven't had any luck yet.
Some result in joint following errors, some result in negative axis values, 
but none seem to invert the kinematics.

Short of re-compiling to manually flip it in the source, some guidance 
would be appreciated.


-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Cramps wiring 5 Reference switches to one input?

[Daren Schwenke]

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 
show the correct state while you have them parallel, it will work... for a 
while at least.
What will happen is a single phototransistor may be required to sink/source 
the current required to light all of the LED's.  This current is probably 
above it's maximum rating so it will fail eventually.
You can properly isolate them from each other with a couple diodes and 
still parallel them, but I'll need to know the circuit they use to give you 
the diode direction.
I'll also need to know if you are using them with the gate normally 
blocked, or open.

On Friday, November 10, 2017 at 9:17:33 AM UTC-5, Sag ich Dir nich wrote:
>
> Hello,
>
> i have optical switches like these: 
> https://www.roboter-bausatz.de/624/3er-set-optischer-endschalter-mit-kabelsatz
>
> Am Freitag, 10. November 2017 09:31:52 UTC+1 schrieb Alexander Rössler:
>>
>> Depends on your circuit and you switches. 
>>
>> If they just short through to ground it should be pretty safe. However, 
>> if you switches either have GND or VCC on the output you might risk a 
>> short circuit. 
>>
>> Which kind of switches do you use? 
>>
>> Sag ich Dir nich writes: 
>>
>> > Hello, 
>> > 
>> > i want to know what could possibly happen if i wire all switches to one 
>> > input (what could happen if all 5 were signaling?). Atm i have two 
>> wired to 
>> > one input and it is working but i dont want to risk damaging something 
>> when 
>> > wiring all switches to one input. 
>>
>>
>> -- 
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Cramps wiring 5 Reference switches to one input?

[Daren Schwenke]

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 at 10:54:58 AM UTC-5, Sag ich Dir nich wrote:
>
> Hello, 
>
> i want to know what could possibly happen if i wire all switches to one 
> input (what could happen if all 5 were signaling?). Atm i have two wired to 
> one input and it is working but i dont want to risk damaging something when 
> wiring all switches to one input.
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Cramps wiring 5 Reference switches to one input?

[Daren Schwenke]

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:58 AM UTC-5, Sag ich Dir nich wrote:
>
> Hello, 
>
> i want to know what could possibly happen if i wire all switches to one 
> input (what could happen if all 5 were signaling?). Atm i have two wired to 
> one input and it is working but i dont want to risk damaging something when 
> wiring all switches to one input.
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

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 started over with Debian Stretch, 4.4 ti rt kernel, and hacked down 
> the 
> > Fabrikator-Mini-CRAMPS config until it didn't step on anything. 
> > *I now get both PWM and step/dir from hal_pru_generic.*   
> > 
> > This still doesn't tell me if it was the pins I used or the config.   
> > Going to swap the pins I used into the CRAMPS config and find out. 
>
> Great news!  At least now you know the PRU is working! 
>
> Let us know if you find out what makes the config not work at all, I'm 
> sure someone else is going to run into this problem. 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

I started over with Debian Stretch, 4.4 ti rt kernel, and hacked down the 
Fabrikator-Mini-CRAMPS config until it didn't step on anything.
*I now get both PWM and step/dir from hal_pru_generic.*  

This still doesn't tell me if it was the pins I used or the config.  
Going to swap the pins 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 not sure what's 
>> going wrong.  I don't have a BBGW to test with, but I think some other 
>> folks have worked with this board and didn't run into any unusual 
>> problems. 
>>
>> Let us know how things go with Jessie.  Using Jessie + a 4.x kernel 
>> should be pretty straight-forward. 
>>
> Not well.  Exactly the same result.  
> So it's either something specific with having the BBGW with wifi 
> enabled/the pins I picked, 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 <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 1:21:40 PM UTC-5, Daren Schwenke 
>> wrote: 
>> >>>> On Sunday, November 5, 2017 at 12:29:42 PM UTC-5, Charles 
>> Steinkuehler 
>> >>>> wrote: 
>> >>>> 
>> >>>>> ...and the memory maps should point to the PRU and the chunk of 
>> SDRAM 
>> >>>>> allocated by the uio driver: 
>> >>>>> 
>> >>>>> $ for FILE in /sys/class/uio/uio0/maps/map*/[as]* ; do echo "$FILE: 
>> >>>>> $(cat $FILE)" ; done 
>> >>>>> /sys/class/uio/uio0/maps/map0/addr: 0x4a30 
>> >>>>> /sys/class/uio/uio0/maps/map0/size: 0x8 
>> >>>>> /sys/class/uio/uio0/maps/map1/addr: 0x9f78 
>> >>>>> /sys/class/uio/uio0/maps/map1/size: 0x4 
>> >>>>> 
>> >>>>>  debian@beaglebone:~$ for FILE in 
>> /sys/class/uio/uio0/maps/map*/[as]* 
>> >> ; 
>> >>>> do echo "$FILE: 
>> >>>>> $(cat $FILE)" ; done 
>> >>>> /sys/class/uio/uio0/maps/map0/addr: 
>> >>>> 0x4a30 
>> >>>> /sys/class/uio/uio0/maps/map0/size: 
>> >>>> 0x0008 
>> >>>> /sys/class/uio/uio0/maps/map1/addr: 
>> >>>> 0x9c94 
>> >>>> /sys/class/uio/uio0/maps/map1/size: 
>> >>>> 0x0004 
>> >>>> debian@beaglebone:~$ 
>> >>>> Hmm.  Do the leading zero's here matter? 
>> >> 
>> >> The leading zeros don't matter. 
>> >> 
>> >>>>> If any of the above doesn't match, that's probably why things are 
>> >>>>> going wrong. 
>> >>>> 
>> >>>> Um.. the second memory address *is* actually different. Matter? 
>> >> 
>> >> The first memory map (0x4a30) is the PRU.  The second memory map 
>> >> is SDRAM mapped by the UIO driver, and is probably at a different 
>> >> address each boot (or at least it's not unexpected it would be at a 
>> >> different address between major kernel versions). 
>> >> 
>> >>>> In any case, thank you for your expert help Charles.   
>> >>>> I've been stuck at this point for 3 days. 
>> >> 
>> >> I'm wondering if you actually _have_ a PRU (some of the CPU variants 
>> >> do not).  Which flavor 'bone are you using? 
>> >> 
>> >> Can you post the full part number of the TI processor (or Octavo SiP)? 
>> >> 
>> >> -- 
>> >> Charles Steinkuehler 
>> >> cha...@steinkuehler.net  
>> >> 
>> > 
>>
>>
>> -- 
>> Charles Steinkuehler 
>> cha...@steinkuehler.net 
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

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 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 wrong.  I don't have a BBGW to test with, but I think some other 
> >>> folks have worked with this board and didn't run into any unusual 
> >>> problems. 
> > 
> > I did find other instances of people using the BBGW, but in all cases 
> they 
> > had disabled or didn't have a kernel suitable for enabling the wifi so 
> that 
> > they could use the regular capes. 
> > None of the regular capes will work with the BBGW wifi enabled as the 
> pins 
> > it uses steps on all of them somewhere. 
> > To have wifi enabled requires > 3.8 kernel and using the rt-preempt. 
>
> You could make 3.8 work on the bbgw (with wifi), it's just not 
> something i was going to waste any time on.. 
>
> you'd also have to back port "gpio-hogs": 
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am335x-bonegreen-wireless.dts?h=v4.14-rc8#n116
>  
>
> Otherwise, wifi will only work on 2nd boot, and then sometimes not at 
> all..  As the wl18xx likes to enter a special test mode with that pin 
> floating.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>
Yeah.  I tried to go down the 3.8 path like 6 months back, but I lacked the 
experience to make it work and didn't feel it worthy to bother people about 
it.
Now that I could start with the kernel/realtime sorted, the rest I did have 
some experience with so I thought I'd give it a go again.
I just need more methodology and less winging it and hoping for the best.

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

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 wrong.  I don't have a BBGW to test with, but I think some other 
>> folks have worked with this board and didn't run into any unusual 
>> problems. 
>>
> I did find other instances of people using the BBGW, but in all cases they 
had disabled or didn't have a kernel suitable for enabling the wifi so that 
they could use the regular capes.
None of the regular capes will work with the BBGW wifi enabled as the pins 
it uses steps on all of them somewhere.
To have wifi enabled requires > 3.8 kernel and using the rt-preempt.

So unfortunately I think that puts this project in the realm of no, it 
hasn't been done like that before and a whole lot of variables to account 
for at once.
Still gonna try to make it work.


>> Let us know how things go with Jessie.  Using Jessie + a 4.x kernel 
>> should be pretty straight-forward. 
>>
> Not well.  Exactly the same result.  
> So it's either something specific with having the BBGW with wifi 
> enabled/the pins I picked, 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 <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 1:21:40 PM UTC-5, Daren Schwenke 
>> wrote: 
>> >>>> On Sunday, November 5, 2017 at 12:29:42 PM UTC-5, Charles 
>> Steinkuehler 
>> >>>> wrote: 
>> >>>> 
>> >>>>> ...and the memory maps should point to the PRU and the chunk of 
>> SDRAM 
>> >>>>> allocated by the uio driver: 
>> >>>>> 
>> >>>>> $ for FILE in /sys/class/uio/uio0/maps/map*/[as]* ; do echo "$FILE: 
>> >>>>> $(cat $FILE)" ; done 
>> >>>>> /sys/class/uio/uio0/maps/map0/addr: 0x4a30 
>> >>>>> /sys/class/uio/uio0/maps/map0/size: 0x8 
>> >>>>> /sys/class/uio/uio0/maps/map1/addr: 0x9f78 
>> >>>>> /sys/class/uio/uio0/maps/map1/size: 0x4 
>> >>>>> 
>> >>>>>  debian@beaglebone:~$ for FILE in 
>> /sys/class/uio/uio0/maps/map*/[as]* 
>> >> ; 
>> >>>> do echo "$FILE: 
>> >>>>> $(cat $FILE)" ; done 
>> >>>> /sys/class/uio/uio0/maps/map0/addr: 
>> >>>> 0x4a30 
>> >>>> /sys/class/uio/uio0/maps/map0/size: 
>> >>>> 0x0008 
>> >>>> /sys/class/uio/uio0/maps/map1/addr: 
>> >>>> 0x9c94 
>> >>>> /sys/class/uio/uio0/maps/map1/size: 
>> >>>> 0x0004 
>> >>>> debian@beaglebone:~$ 
>> >>>> Hmm.  Do the leading zero's here matter? 
>> >> 
>> >> The leading zeros don't matter. 
>> >> 
>> >>>>> If any of the above doesn't match, that's probably why things are 
>> >>>>> going wrong. 
>> >>>> 
>> >>>> Um.. the second memory address *is* actually different. Matter? 
>> >> 
>> >> The first memory map (0x4a30) is the PRU.  The second memory map 
>> >> is SDRAM mapped by the UIO driver, and is probably at a different 
>> >> address each boot (or at least it's not unexpected it would be at a 
>> >> different address between major kernel versions). 
>> >> 
>> >>>> In any case, thank you for your expert help Charles.   
>> >>>> I've been stuck at this point for 3 days. 
>> >> 
>> >> I'm wondering if you actually _have_ a PRU (some of the CPU variants 
>> >> do not).  Which flavor 'bone are you using? 
>> >> 
>> >> Can you post the full part number of the TI processor (or Octavo SiP)? 
>> >> 
>> >> -- 
>> >> Charles Steinkuehler 
>> >> cha...@steinkuehler.net  
>> >> 
>> > 
>>
>>
>> -- 
>> Charles Steinkuehler 
>> cha...@steinkuehler.net 
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

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 wrong.  I don't have a BBGW to test with, but I think some other 
> folks have worked with this board and didn't run into any unusual 
> problems. 
>
> Let us know how things go with Jessie.  Using Jessie + a 4.x kernel 
> should be pretty straight-forward. 
>
Not well.  Exactly the same result.  
So it's either something specific with having the BBGW with wifi 
enabled/the pins I picked, 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 <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 1:21:40 PM UTC-5, Daren Schwenke wrote: 
> >>>> On Sunday, November 5, 2017 at 12:29:42 PM UTC-5, Charles 
> Steinkuehler 
> >>>> wrote: 
> >>>> 
> >>>>> ...and the memory maps should point to the PRU and the chunk of 
> SDRAM 
> >>>>> allocated by the uio driver: 
> >>>>> 
> >>>>> $ for FILE in /sys/class/uio/uio0/maps/map*/[as]* ; do echo "$FILE: 
> >>>>> $(cat $FILE)" ; done 
> >>>>> /sys/class/uio/uio0/maps/map0/addr: 0x4a30 
> >>>>> /sys/class/uio/uio0/maps/map0/size: 0x8 
> >>>>> /sys/class/uio/uio0/maps/map1/addr: 0x9f78 
> >>>>> /sys/class/uio/uio0/maps/map1/size: 0x4 
> >>>>> 
> >>>>>  debian@beaglebone:~$ for FILE in 
> /sys/class/uio/uio0/maps/map*/[as]* 
> >> ; 
> >>>> do echo "$FILE: 
> >>>>> $(cat $FILE)" ; done 
> >>>> /sys/class/uio/uio0/maps/map0/addr: 
> >>>> 0x4a30 
> >>>> /sys/class/uio/uio0/maps/map0/size: 
> >>>> 0x0008 
> >>>> /sys/class/uio/uio0/maps/map1/addr: 
> >>>> 0x9c94 
> >>>> /sys/class/uio/uio0/maps/map1/size: 
> >>>> 0x0004 
> >>>> debian@beaglebone:~$ 
> >>>> Hmm.  Do the leading zero's here matter? 
> >> 
> >> The leading zeros don't matter. 
> >> 
> >>>>> If any of the above doesn't match, that's probably why things are 
> >>>>> going wrong. 
> >>>> 
> >>>> Um.. the second memory address *is* actually different. Matter? 
> >> 
> >> The first memory map (0x4a30) is the PRU.  The second memory map 
> >> is SDRAM mapped by the UIO driver, and is probably at a different 
> >> address each boot (or at least it's not unexpected it would be at a 
> >> different address between major kernel versions). 
> >> 
> >>>> In any case, thank you for your expert help Charles.   
> >>>> I've been stuck at this point for 3 days. 
> >> 
> >> I'm wondering if you actually _have_ a PRU (some of the CPU variants 
> >> do not).  Which flavor 'bone are you using? 
> >> 
> >> Can you post the full part number of the TI processor (or Octavo SiP)? 
> >> 
> >> -- 
> >> Charles Steinkuehler 
> >> cha...@steinkuehler.net  
> >> 
> > 
>
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

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 to model 
> after, here are the pins consumed by the onboard wifi/bluetooth chip:
> That and the BBGW has no HDMI chip, so using the LCD pins instead made a 
> lot of sense.
>
> P8_11 WL_SDIO_D1 QEB2B
> P8_12 WL_SDIO_D0 QEB2A
> P8_14 WL_EN BAT_LED_4
> P8_15 WL_SDIO_D3 PRU_ENC_A
> P8_16 WL_SDIO_D2 PRU_ENC_B
> P8_17 WL_IRQ BATT_LED_1
> P8_18 WL_SDIO_CLK BATT_LED_2
> P8_26 WL_Level_Shifter_OE BATT_LED_3
> P9_12 BT_EN MDIR_1A
> P9_28 BT_AUD_IN SPI1_CS0
> P9_29 BT_AUD_FSYNC SPI1_D0
> P9_30 BT_AUD_OUT SPI1_D1
> P9_31 BT_AUD_CLK SPI1_SCLK
> P9_41 WL_SLOW_CLK MOT_STBY
>
>
> On 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:
>>>
>>> On 11/5/2017 5:04 PM, Daren Schwenke wrote: 
>>> > 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: 
>>> >> 
>>> >>> ...and the memory maps should point to the PRU and the chunk of 
>>> SDRAM 
>>> >>> allocated by the uio driver: 
>>> >>> 
>>> >>> $ for FILE in /sys/class/uio/uio0/maps/map*/[as]* ; do echo "$FILE: 
>>> >>> $(cat $FILE)" ; done 
>>> >>> /sys/class/uio/uio0/maps/map0/addr: 0x4a30 
>>> >>> /sys/class/uio/uio0/maps/map0/size: 0x8 
>>> >>> /sys/class/uio/uio0/maps/map1/addr: 0x9f78 
>>> >>> /sys/class/uio/uio0/maps/map1/size: 0x4 
>>> >>> 
>>> >>>  debian@beaglebone:~$ for FILE in 
>>> /sys/class/uio/uio0/maps/map*/[as]* ; 
>>> >> do echo "$FILE: 
>>> >>> $(cat $FILE)" ; done 
>>> >> /sys/class/uio/uio0/maps/map0/addr: 
>>> >> 0x4a30 
>>> >> /sys/class/uio/uio0/maps/map0/size: 
>>> >> 0x0008 
>>> >> /sys/class/uio/uio0/maps/map1/addr: 
>>> >> 0x9c94 
>>> >> /sys/class/uio/uio0/maps/map1/size: 
>>> >> 0x0004 
>>> >> debian@beaglebone:~$ 
>>> >> Hmm.  Do the leading zero's here matter? 
>>>
>>> The leading zeros don't matter. 
>>>
>>> >>> If any of the above doesn't match, that's probably why things are 
>>> >>> going wrong. 
>>> >> 
>>> >> Um.. the second memory address *is* actually different. Matter? 
>>>
>>> The first memory map (0x4a30) is the PRU.  The second memory map 
>>> is SDRAM mapped by the UIO driver, and is probably at a different 
>>> address each boot (or at least it's not unexpected it would be at a 
>>> different address between major kernel versions). 
>>>
>>> >> In any case, thank you for your expert help Charles.   
>>> >> I've been stuck at this point for 3 days. 
>>>
>>> I'm wondering if you actually _have_ a PRU (some of the CPU variants 
>>> do not).  Which flavor 'bone are you using? 
>>>
>>> Can you post the full part number of the TI processor (or Octavo SiP)? 
>>>
>>> -- 
>>> Charles Steinkuehler 
>>> cha...@steinkuehler.net 
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

In case you are wondering why I picked such an ancient cape to model after, 
here are the pins consumed by the onboard wifi/bluetooth chip:
That and the BBGW has no HDMI chip, so using the LCD pins instead made a 
lot of sense.

P8_11 WL_SDIO_D1 QEB2B
P8_12 WL_SDIO_D0 QEB2A
P8_14 WL_EN BAT_LED_4
P8_15 WL_SDIO_D3 PRU_ENC_A
P8_16 WL_SDIO_D2 PRU_ENC_B
P8_17 WL_IRQ BATT_LED_1
P8_18 WL_SDIO_CLK BATT_LED_2
P8_26 WL_Level_Shifter_OE BATT_LED_3
P9_12 BT_EN MDIR_1A
P9_28 BT_AUD_IN SPI1_CS0
P9_29 BT_AUD_FSYNC SPI1_D0
P9_30 BT_AUD_OUT SPI1_D1
P9_31 BT_AUD_CLK SPI1_SCLK
P9_41 WL_SLOW_CLK MOT_STBY


On 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:
>>
>> On 11/5/2017 5:04 PM, Daren Schwenke wrote: 
>> > 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: 
>> >> 
>> >>> ...and the memory maps should point to the PRU and the chunk of SDRAM 
>> >>> allocated by the uio driver: 
>> >>> 
>> >>> $ for FILE in /sys/class/uio/uio0/maps/map*/[as]* ; do echo "$FILE: 
>> >>> $(cat $FILE)" ; done 
>> >>> /sys/class/uio/uio0/maps/map0/addr: 0x4a30 
>> >>> /sys/class/uio/uio0/maps/map0/size: 0x8 
>> >>> /sys/class/uio/uio0/maps/map1/addr: 0x9f78 
>> >>> /sys/class/uio/uio0/maps/map1/size: 0x4 
>> >>> 
>> >>>  debian@beaglebone:~$ for FILE in /sys/class/uio/uio0/maps/map*/[as]* 
>> ; 
>> >> do echo "$FILE: 
>> >>> $(cat $FILE)" ; done 
>> >> /sys/class/uio/uio0/maps/map0/addr: 
>> >> 0x4a30 
>> >> /sys/class/uio/uio0/maps/map0/size: 
>> >> 0x0008 
>> >> /sys/class/uio/uio0/maps/map1/addr: 
>> >> 0x9c94 
>> >> /sys/class/uio/uio0/maps/map1/size: 
>> >> 0x0004 
>> >> debian@beaglebone:~$ 
>> >> Hmm.  Do the leading zero's here matter? 
>>
>> The leading zeros don't matter. 
>>
>> >>> If any of the above doesn't match, that's probably why things are 
>> >>> going wrong. 
>> >> 
>> >> Um.. the second memory address *is* actually different. Matter? 
>>
>> The first memory map (0x4a30) is the PRU.  The second memory map 
>> is SDRAM mapped by the UIO driver, and is probably at a different 
>> address each boot (or at least it's not unexpected it would be at a 
>> different address between major kernel versions). 
>>
>> >> In any case, thank you for your expert help Charles.   
>> >> I've been stuck at this point for 3 days. 
>>
>> I'm wondering if you actually _have_ a PRU (some of the CPU variants 
>> do not).  Which flavor 'bone are you using? 
>>
>> Can you post the full part number of the TI processor (or Octavo SiP)? 
>>
>> -- 
>> Charles Steinkuehler 
>> cha...@steinkuehler.net 
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

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 1:21:40 PM UTC-5, Daren Schwenke wrote: 
> >> On Sunday, November 5, 2017 at 12:29:42 PM UTC-5, Charles Steinkuehler 
> >> wrote: 
> >> 
> >>> ...and the memory maps should point to the PRU and the chunk of SDRAM 
> >>> allocated by the uio driver: 
> >>> 
> >>> $ for FILE in /sys/class/uio/uio0/maps/map*/[as]* ; do echo "$FILE: 
> >>> $(cat $FILE)" ; done 
> >>> /sys/class/uio/uio0/maps/map0/addr: 0x4a30 
> >>> /sys/class/uio/uio0/maps/map0/size: 0x8 
> >>> /sys/class/uio/uio0/maps/map1/addr: 0x9f78 
> >>> /sys/class/uio/uio0/maps/map1/size: 0x4 
> >>> 
> >>>  debian@beaglebone:~$ for FILE in /sys/class/uio/uio0/maps/map*/[as]* 
> ; 
> >> do echo "$FILE: 
> >>> $(cat $FILE)" ; done 
> >> /sys/class/uio/uio0/maps/map0/addr: 
> >> 0x4a30 
> >> /sys/class/uio/uio0/maps/map0/size: 
> >> 0x0008 
> >> /sys/class/uio/uio0/maps/map1/addr: 
> >> 0x9c94 
> >> /sys/class/uio/uio0/maps/map1/size: 
> >> 0x0004 
> >> debian@beaglebone:~$ 
> >> Hmm.  Do the leading zero's here matter? 
>
> The leading zeros don't matter. 
>
> >>> If any of the above doesn't match, that's probably why things are 
> >>> going wrong. 
> >> 
> >> Um.. the second memory address *is* actually different. Matter? 
>
> The first memory map (0x4a30) is the PRU.  The second memory map 
> is SDRAM mapped by the UIO driver, and is probably at a different 
> address each boot (or at least it's not unexpected it would be at a 
> different address between major kernel versions). 
>
> >> In any case, thank you for your expert help Charles.   
> >> I've been stuck at this point for 3 days. 
>
> I'm wondering if you actually _have_ a PRU (some of the CPU variants 
> do not).  Which flavor 'bone are you using? 
>
> Can you post the full part number of the TI processor (or Octavo SiP)? 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

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 UTC-5, Daren Schwenke wrote: 
>> >> On Sunday, November 5, 2017 at 7:51:02 AM UTC-5, Charles Steinkuehler 
>> >> wrote: 
>> >> 
>> >>> If that works, make sure you're using a kernel 
>> >>> that has the uio driver for the PRU enabled (and not the remote-proc 
>> >>> 
>> >> and Yes.   
>> >> ###PRUSS OPTIONS 
>> >> ###pru_rproc (4.4.x-ti kernel) 
>> >> #uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo 
>> >> ###pru_uio (4.4.x-ti & mainline/bone kernel) 
>> >> uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo 
>> >> The other one now commented was installed by default. 
>> >> 
>> >> driver).  IIRC, Robert Nelson has both flavors available, but I'm not 
>> >>> sure what gets installed by default on the newer images. 
>> >>> 
>> >> I also tried using the mainline bone rt kernel, but that one won't 
>> boot on 
>> > the BBGW when flashed.  Sits at 4 LED's on forever. 
>> > Everything else seems to work fine on 
>> > debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ uname -r 
>> > 4.4.91-ti-rt-r136 
>> > Just not hal_pru_generic actually flipping pins. 
>> > I'm pretty confused. 
>>
>> Since the issue is with the PRU, let's make sure the UIO files 
>> Machinekit is expecting are really present.  There should be eight 
>> device in /dev: 
>>
>> $ ls -l /dev/uio* 
>> crw-rw 1 root users 245, 0 Oct 17 10:32 /dev/uio0 
>> crw-rw 1 root users 245, 1 Oct 17 10:32 /dev/uio1 
>> crw-rw 1 root users 245, 2 Oct 17 10:32 /dev/uio2 
>> crw-rw 1 root users 245, 3 Oct 17 10:32 /dev/uio3 
>> crw-rw 1 root users 245, 4 Oct 17 10:32 /dev/uio4 
>> crw-rw 1 root users 245, 5 Oct 17 10:32 /dev/uio5 
>> crw-rw 1 root users 245, 6 Oct 17 10:32 /dev/uio6 
>> crw-rw 1 root users 245, 7 Oct 17 10:32 /dev/uio7 
>>
>> Check.
> debian@beaglebone:~$ ls -l /dev/uio*
> crw-rw 1 root users 244, 0 Nov  5 16:32 /dev/uio0
> crw-rw 1 root users 244, 1 Nov  5 16:32 /dev/uio1
> crw-rw 1 root users 244, 2 Nov  5 16:32 /dev/uio2
> crw-rw 1 root users 244, 3 Nov  5 16:32 /dev/uio3
> crw-rw 1 root users 244, 4 Nov  5 16:32 /dev/uio4
> crw-rw 1 root users 244, 5 Nov  5 16:32 /dev/uio5
> crw-rw 1 root users 244, 6 Nov  5 16:32 /dev/uio6
> crw-rw 1 root users 244, 7 Nov  5 16:32 /dev/uio7
> debian@beaglebone:~$
>
> ...the uio devices should be named for the eight pruss events: 
>>
>> $ cat /sys/class/uio/uio*/name 
>> pruss_evt0 
>> pruss_evt1 
>> pruss_evt2 
>> pruss_evt3 
>> pruss_evt4 
>> pruss_evt5 
>> pruss_evt6 
>> pruss_evt7 
>>
>> Check. 
> debian@beaglebone:~$ cat /sys/class/uio/uio*/name
> pruss_evt0
> pruss_evt1
> pruss_evt2
> pruss_evt3
> pruss_evt4
> pruss_evt5
> pruss_evt6
> pruss_evt7
> debian@beaglebone:~$ 
>
>> ...and the memory maps should point to the PRU and the chunk of SDRAM 
>> allocated by the uio driver: 
>>
>> $ for FILE in /sys/class/uio/uio0/maps/map*/[as]* ; do echo "$FILE: 
>> $(cat $FILE)" ; done 
>> /sys/class/uio/uio0/maps/map0/addr: 0x4a30 
>> /sys/class/uio/uio0/maps/map0/size: 0x8 
>> /sys/class/uio/uio0/maps/map1/addr: 0x9f78 
>> /sys/class/uio/uio0/maps/map1/size: 0x4 
>>
>>  debian@beaglebone:~$ for FILE in /sys/class/uio/uio0/maps/map*/[as]* ; 
> do echo "$FILE: 
> > $(cat $FILE)" ; done
> /sys/class/uio/uio0/maps/map0/addr: 
> 0x4a30
> /sys/class/uio/uio0/maps/map0/size: 
> 0x0008
> /sys/class/uio/uio0/maps/map1/addr: 
> 0x9c94
> /sys/class/uio/uio0/maps/map1/size: 
> 0x0004
> debian@beaglebone:~$ 
> Hmm.  Do the leading zero's here matter? 
>
>> If any of the above doesn't match, that's probably why things are 
>> going wrong. 
>>
>
> Um.. the second memory address *is* actually different. Matter?

> In any case, thank you for your expert help Charles.  
> I've been stuck at this point for 3 days.
>
> -- 
>> Charles Steinkuehler 
>> cha...@steinkuehler.net 
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

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 UTC-5, Daren Schwenke wrote: 
>> >> On Sunday, November 5, 2017 at 7:51:02 AM UTC-5, Charles Steinkuehler 
>> >> wrote: 
>> >> 
>> >>> If that works, make sure you're using a kernel 
>> >>> that has the uio driver for the PRU enabled (and not the remote-proc 
>> >>> 
>> >> and Yes.   
>> >> ###PRUSS OPTIONS 
>> >> ###pru_rproc (4.4.x-ti kernel) 
>> >> #uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo 
>> >> ###pru_uio (4.4.x-ti & mainline/bone kernel) 
>> >> uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo 
>> >> The other one now commented was installed by default. 
>> >> 
>> >> driver).  IIRC, Robert Nelson has both flavors available, but I'm not 
>> >>> sure what gets installed by default on the newer images. 
>> >>> 
>> >> I also tried using the mainline bone rt kernel, but that one won't 
>> boot on 
>> > the BBGW when flashed.  Sits at 4 LED's on forever. 
>> > Everything else seems to work fine on 
>> > debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ uname -r 
>> > 4.4.91-ti-rt-r136 
>> > Just not hal_pru_generic actually flipping pins. 
>> > I'm pretty confused. 
>>
>> Since the issue is with the PRU, let's make sure the UIO files 
>> Machinekit is expecting are really present.  There should be eight 
>> device in /dev: 
>>
>> $ ls -l /dev/uio* 
>> crw-rw 1 root users 245, 0 Oct 17 10:32 /dev/uio0 
>> crw-rw 1 root users 245, 1 Oct 17 10:32 /dev/uio1 
>> crw-rw 1 root users 245, 2 Oct 17 10:32 /dev/uio2 
>> crw-rw 1 root users 245, 3 Oct 17 10:32 /dev/uio3 
>> crw-rw 1 root users 245, 4 Oct 17 10:32 /dev/uio4 
>> crw-rw 1 root users 245, 5 Oct 17 10:32 /dev/uio5 
>> crw-rw 1 root users 245, 6 Oct 17 10:32 /dev/uio6 
>> crw-rw 1 root users 245, 7 Oct 17 10:32 /dev/uio7 
>>
>> Check.
> debian@beaglebone:~$ ls -l /dev/uio*
> crw-rw 1 root users 244, 0 Nov  5 16:32 /dev/uio0
> crw-rw 1 root users 244, 1 Nov  5 16:32 /dev/uio1
> crw-rw 1 root users 244, 2 Nov  5 16:32 /dev/uio2
> crw-rw 1 root users 244, 3 Nov  5 16:32 /dev/uio3
> crw-rw 1 root users 244, 4 Nov  5 16:32 /dev/uio4
> crw-rw 1 root users 244, 5 Nov  5 16:32 /dev/uio5
> crw-rw 1 root users 244, 6 Nov  5 16:32 /dev/uio6
> crw-rw 1 root users 244, 7 Nov  5 16:32 /dev/uio7
> debian@beaglebone:~$
>
> ...the uio devices should be named for the eight pruss events: 
>>
>> $ cat /sys/class/uio/uio*/name 
>> pruss_evt0 
>> pruss_evt1 
>> pruss_evt2 
>> pruss_evt3 
>> pruss_evt4 
>> pruss_evt5 
>> pruss_evt6 
>> pruss_evt7 
>>
>> Check. 
> debian@beaglebone:~$ cat /sys/class/uio/uio*/name
> pruss_evt0
> pruss_evt1
> pruss_evt2
> pruss_evt3
> pruss_evt4
> pruss_evt5
> pruss_evt6
> pruss_evt7
> debian@beaglebone:~$ 
>
>> ...and the memory maps should point to the PRU and the chunk of SDRAM 
>> allocated by the uio driver: 
>>
>> $ for FILE in /sys/class/uio/uio0/maps/map*/[as]* ; do echo "$FILE: 
>> $(cat $FILE)" ; done 
>> /sys/class/uio/uio0/maps/map0/addr: 0x4a30 
>> /sys/class/uio/uio0/maps/map0/size: 0x8 
>> /sys/class/uio/uio0/maps/map1/addr: 0x9f78 
>> /sys/class/uio/uio0/maps/map1/size: 0x4 
>>
>>  debian@beaglebone:~$ for FILE in /sys/class/uio/uio0/maps/map*/[as]* ; 
> do echo "$FILE: 
> > $(cat $FILE)" ; done
> /sys/class/uio/uio0/maps/map0/addr: 
> 0x4a30
> /sys/class/uio/uio0/maps/map0/size: 
> 0x0008
> /sys/class/uio/uio0/maps/map1/addr: 
> 0x9c94
> /sys/class/uio/uio0/maps/map1/size: 
> 0x0004
> debian@beaglebone:~$ 
> Hmm.  Do the leading zero's here matter? 
>
>> If any of the above doesn't match, that's probably why things are 
>> going wrong. 
>>
>
> In any case, thank you for your expert help Charles.  
> I've been stuck at this point for 3 days.
>
> -- 
>> Charles Steinkuehler 
>> cha...@steinkuehler.net 
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

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 Steinkuehler 
> >> wrote: 
> >> 
> >>> If that works, make sure you're using a kernel 
> >>> that has the uio driver for the PRU enabled (and not the remote-proc 
> >>> 
> >> and Yes.   
> >> ###PRUSS OPTIONS 
> >> ###pru_rproc (4.4.x-ti kernel) 
> >> #uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo 
> >> ###pru_uio (4.4.x-ti & mainline/bone kernel) 
> >> uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo 
> >> The other one now commented was installed by default. 
> >> 
> >> driver).  IIRC, Robert Nelson has both flavors available, but I'm not 
> >>> sure what gets installed by default on the newer images. 
> >>> 
> >> I also tried using the mainline bone rt kernel, but that one won't boot 
> on 
> > the BBGW when flashed.  Sits at 4 LED's on forever. 
> > Everything else seems to work fine on 
> > debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ uname -r 
> > 4.4.91-ti-rt-r136 
> > Just not hal_pru_generic actually flipping pins. 
> > I'm pretty confused. 
>
> Since the issue is with the PRU, let's make sure the UIO files 
> Machinekit is expecting are really present.  There should be eight 
> device in /dev: 
>
> $ ls -l /dev/uio* 
> crw-rw 1 root users 245, 0 Oct 17 10:32 /dev/uio0 
> crw-rw 1 root users 245, 1 Oct 17 10:32 /dev/uio1 
> crw-rw 1 root users 245, 2 Oct 17 10:32 /dev/uio2 
> crw-rw 1 root users 245, 3 Oct 17 10:32 /dev/uio3 
> crw-rw 1 root users 245, 4 Oct 17 10:32 /dev/uio4 
> crw-rw 1 root users 245, 5 Oct 17 10:32 /dev/uio5 
> crw-rw 1 root users 245, 6 Oct 17 10:32 /dev/uio6 
> crw-rw 1 root users 245, 7 Oct 17 10:32 /dev/uio7 
>
> Check.
debian@beaglebone:~$ ls -l /dev/uio*
crw-rw 1 root users 244, 0 Nov  5 16:32 /dev/uio0
crw-rw 1 root users 244, 1 Nov  5 16:32 /dev/uio1
crw-rw 1 root users 244, 2 Nov  5 16:32 /dev/uio2
crw-rw 1 root users 244, 3 Nov  5 16:32 /dev/uio3
crw-rw 1 root users 244, 4 Nov  5 16:32 /dev/uio4
crw-rw 1 root users 244, 5 Nov  5 16:32 /dev/uio5
crw-rw 1 root users 244, 6 Nov  5 16:32 /dev/uio6
crw-rw 1 root users 244, 7 Nov  5 16:32 /dev/uio7
debian@beaglebone:~$

...the uio devices should be named for the eight pruss events: 
>
> $ cat /sys/class/uio/uio*/name 
> pruss_evt0 
> pruss_evt1 
> pruss_evt2 
> pruss_evt3 
> pruss_evt4 
> pruss_evt5 
> pruss_evt6 
> pruss_evt7 
>
> Check. 
debian@beaglebone:~$ cat /sys/class/uio/uio*/name
pruss_evt0
pruss_evt1
pruss_evt2
pruss_evt3
pruss_evt4
pruss_evt5
pruss_evt6
pruss_evt7
debian@beaglebone:~$ 

> ...and the memory maps should point to the PRU and the chunk of SDRAM 
> allocated by the uio driver: 
>
> $ for FILE in /sys/class/uio/uio0/maps/map*/[as]* ; do echo "$FILE: 
> $(cat $FILE)" ; done 
> /sys/class/uio/uio0/maps/map0/addr: 0x4a30 
> /sys/class/uio/uio0/maps/map0/size: 0x8 
> /sys/class/uio/uio0/maps/map1/addr: 0x9f78 
> /sys/class/uio/uio0/maps/map1/size: 0x4 
>
>  debian@beaglebone:~$ for FILE in /sys/class/uio/uio0/maps/map*/[as]* ; do 
echo "$FILE: 
> $(cat $FILE)" ; done
/sys/class/uio/uio0/maps/map0/addr: 
0x4a30
/sys/class/uio/uio0/maps/map0/size: 
0x0008
/sys/class/uio/uio0/maps/map1/addr: 
0x9c94
/sys/class/uio/uio0/maps/map1/size: 
0x0004
debian@beaglebone:~$ 
Hmm.  Do the leading zero's here matter? 

> If any of the above doesn't match, that's probably why things are 
> going wrong. 
>

In any case, thank you for your expert help Charles.  
I've been stuck at this point for 3 days.

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

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

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 work fine with hal_bb_gpio, and not 
>> with 
>> > hal_pru_generic.   
>> > 
>> > The estop hardware loop output goes high when I press the virtual 
>> estop, 
>> > which feeds back into my estop input and it enables, and my LED 
>> verifies 
>> > that. 
>> > Which of course sends my machine-power on p810 high as it's tied to 
>> > emcmot-0-enable, and my LED verifies that. 
>> > 
>> > And the halcmd show says I should have PWM at a given level with 
>> everything 
>> > enabled and such... and no output. 
>>
>> If hal_bb_gpio is working but PRU controlled pins are not, there's 
>> likely something wrong with hal_pru_generic. 
>>
>> First make sure the PRU I/O pins are in gpio mode and working as 
>> expected.  
>
>  Yes:  
> https://github.com/Arcus-3d/Arcus-3D-C1-BeBoPr/blob/master/bebopr_cape.bbio
>  
>
> You should be able to make them twiddle using the 
>>
> config-pin command.  
>
> Yes.  
> debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ config-pin 843 hi
> debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ config-pin 843 lo
>
> results in my LED turning on, then off.
>
>> If that works, make sure you're using a kernel 
>> that has the uio driver for the PRU enabled (and not the remote-proc 
>>
> and Yes.   
> ###PRUSS OPTIONS
> ###pru_rproc (4.4.x-ti kernel)
> #uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo
> ###pru_uio (4.4.x-ti & mainline/bone kernel)
> uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
> The other one now commented was installed by default.
>
> driver).  IIRC, Robert Nelson has both flavors available, but I'm not 
>> sure what gets installed by default on the newer images. 
>>
> I also tried using the mainline bone rt kernel, but that one won't boot on 
the BBGW when flashed.  Sits at 4 LED's on forever.
Everything else seems to work fine on
debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ uname -r
4.4.91-ti-rt-r136
Just not hal_pru_generic actually flipping pins.
I'm pretty confused.

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

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

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 hardware loop output goes high when I press the virtual estop, 
> > which feeds back into my estop input and it enables, and my LED verifies 
> > that. 
> > Which of course sends my machine-power on p810 high as it's tied to 
> > emcmot-0-enable, and my LED verifies that. 
> > 
> > And the halcmd show says I should have PWM at a given level with 
> everything 
> > enabled and such... and no output. 
>
> If hal_bb_gpio is working but PRU controlled pins are not, there's 
> likely something wrong with hal_pru_generic. 
>
> First make sure the PRU I/O pins are in gpio mode and working as 
> expected.  

 Yes: 
 https://github.com/Arcus-3d/Arcus-3D-C1-BeBoPr/blob/master/bebopr_cape.bbio 

You should be able to make them twiddle using the 
>
config-pin command.  

Yes.  
debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ config-pin 843 hi
debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ config-pin 843 lo

results in my LED turning on, then off.

> If that works, make sure you're using a kernel 
> that has the uio driver for the PRU enabled (and not the remote-proc 
>
and Yes.   
###PRUSS OPTIONS
###pru_rproc (4.4.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo
###pru_uio (4.4.x-ti & mainline/bone kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
The other one now commented was installed by default.

driver).  IIRC, Robert Nelson has both flavors available, but I'm not 
> sure what gets installed by default on the newer images. 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

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 the confusing part.  Things work fine with hal_bb_gpio, and not 
> with hal_pru_generic.  
>
> The estop hardware loop output goes high when I press the virtual estop, 
> which feeds back into my estop input and it enables, and my LED verifies 
> that.
> Which of course sends my machine-power on p810 high as it's tied to 
> emcmot-0-enable, and my LED verifies that.
>
> And the halcmd show says I should have PWM at a given level with 
> everything enabled and such... and no output.
>
>
> On Sunday, November 5, 2017 at 7:22:30 AM UTC-5, Charles Steinkuehler 
> wrote:
>>
>> I'm not sure what's wrong, but since it sounds like absolutely nothing 
>> is happening, I suggest verifying some of the basics: Make sure you 
>> can twiddle I/O pins via config-pin and halcmd: 
>>
>> Since you're using a 4.x kernel, I don't think the overlay lines in 
>> your bebopr_cape.bbio file will do anything.  Make sure you have the 
>> universal cape loaded via u-boot overlays and test twiddling an I/O 
>> pin using the config-pin command. 
>>
>> If that works, try loading just the HAL part of your configuration 
>> manually (I think you can just run the arcus_3d_c1.py and bebopr.py 
>> files).  If that doesn't work, you can just make a simple test HAL 
>> file to load the hal_bb_gpio driver and create a servo thread. 
>>
>> Make sure you start the threads (halcmd start) and see if twiddling 
>> the I/O pins (ie: bb_gpio.p8.out-07 & friends) 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, so I moved one pin so all 
>> the 
>> > stepgens now sit on PRU 1, and changed to PRU=1. 
>> > No change.   
>> > The board is sitting on my desk with nothing other than a jumper 
>> closing my 
>> > estop loop from P807 to P809.  That toggles appropriately when powering 
>> the 
>> > machine. 
>> > I'm down to testing with just an LED+resistor at <4ma draw and I get 
>> > nothing from any of the hal_pru_generic output pins, and no errors I 
>> can 
>> > see. 
>> > Here is a pastebin of my /var/log/linuxcnc.log from a single 
>> startup,estop 
>> > off, and shutdown.  I had to trim some of the shutdown from 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: 
>> >>> 
>> >>> 
>> 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 switching to rt kernel the /opt/scripts/tools way: 
>> >>> root@beaglebone:~# cd /opt/scripts/tools/ 
>> >>> root@beaglebone:/opt/scripts/tools# git pull 
>> >>> Already up-to-date. 
>> >>> root@beaglebone:/opt/scripts/tools# ./update_kernel.sh 
>> --ti-rt-channel 
>> >>> --lts-4_4 
>> >>> 
>> >>> Added machinekit repo, installed machinekit-rt-preempt 
>> >>> hal_pru_generic is of course there, so is the .so file 
>> >>> 
>> >> debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ ls -al 
>> >> /usr/lib/linuxcnc/rt-preempt/pru_generic.bin 
>> >> lrwxrwxrwx 1 root root 40 Nov  3 06:17 
>> >> /usr/lib/linuxcnc/rt-preempt/pru_generic.bin -> 
>> >> /usr/lib/linuxcnc/prubin/pru_generic.bin 
>> >> debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ ls -al 
>> >> /usr/lib/linuxcnc/prubin/pru_generic.bin 
>> >> -rw-r--r-- 1 root root 848 Nov  2 16:31 
>> >> /usr/lib/linuxcnc/prubin/pru_generic.bin 
>> >> debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ ls -al 
>> >> /usr/lib/linuxcnc/rt-preempt/hal_pru* 
>> >> -rw-r--r-- 1 root root 18704 Nov  2 16:31 
>> >> /usr/lib/linuxcnc/r

Re: [Machinekit] Re: hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

That's the confusing part.  Things work fine with hal_bb_gpio, and not with 
hal_pru_generic.  

The estop hardware loop output goes high when I press the virtual estop, 
which feeds back into my estop input and it enables, and my LED verifies 
that.
Which of course sends my machine-power on p810 high as it's tied to 
emcmot-0-enable, and my LED verifies that.

And the halcmd show says I should have PWM at a given level with everything 
enabled and such... and no output.


On Sunday, November 5, 2017 at 7:22:30 AM UTC-5, Charles Steinkuehler wrote:
>
> I'm not sure what's wrong, but since it sounds like absolutely nothing 
> is happening, I suggest verifying some of the basics: Make sure you 
> can twiddle I/O pins via config-pin and halcmd: 
>
> Since you're using a 4.x kernel, I don't think the overlay lines in 
> your bebopr_cape.bbio file will do anything.  Make sure you have the 
> universal cape loaded via u-boot overlays and test twiddling an I/O 
> pin using the config-pin command. 
>
> If that works, try loading just the HAL part of your configuration 
> manually (I think you can just run the arcus_3d_c1.py and bebopr.py 
> files).  If that doesn't work, you can just make a simple test HAL 
> file to load the hal_bb_gpio driver and create a servo thread. 
>
> Make sure you start the threads (halcmd start) and see if twiddling 
> the I/O pins (ie: bb_gpio.p8.out-07 & friends) 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, so I moved one pin so all 
> the 
> > stepgens now sit on PRU 1, and changed to PRU=1. 
> > No change.   
> > The board is sitting on my desk with nothing other than a jumper closing 
> my 
> > estop loop from P807 to P809.  That toggles appropriately when powering 
> the 
> > machine. 
> > I'm down to testing with just an LED+resistor at <4ma draw and I get 
> > nothing from any of the hal_pru_generic output pins, and no errors I can 
> > see. 
> > Here is a pastebin of my /var/log/linuxcnc.log from a single 
> startup,estop 
> > off, and shutdown.  I had to trim some of the shutdown from 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: 
> >>> 
> >>> 
> 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 switching to rt kernel the /opt/scripts/tools way: 
> >>> root@beaglebone:~# cd /opt/scripts/tools/ 
> >>> root@beaglebone:/opt/scripts/tools# git pull 
> >>> Already up-to-date. 
> >>> root@beaglebone:/opt/scripts/tools# ./update_kernel.sh --ti-rt-channel 
> >>> --lts-4_4 
> >>> 
> >>> Added machinekit repo, installed machinekit-rt-preempt 
> >>> hal_pru_generic is of course there, so is the .so file 
> >>> 
> >> debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ ls -al 
> >> /usr/lib/linuxcnc/rt-preempt/pru_generic.bin 
> >> lrwxrwxrwx 1 root root 40 Nov  3 06:17 
> >> /usr/lib/linuxcnc/rt-preempt/pru_generic.bin -> 
> >> /usr/lib/linuxcnc/prubin/pru_generic.bin 
> >> debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ ls -al 
> >> /usr/lib/linuxcnc/prubin/pru_generic.bin 
> >> -rw-r--r-- 1 root root 848 Nov  2 16:31 
> >> /usr/lib/linuxcnc/prubin/pru_generic.bin 
> >> debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ ls -al 
> >> /usr/lib/linuxcnc/rt-preempt/hal_pru* 
> >> -rw-r--r-- 1 root root 18704 Nov  2 16:31 
> >> /usr/lib/linuxcnc/rt-preempt/hal_prudebug.so 
> >> -rw-r--r-- 1 root root 52360 Nov  2 16:31 
> >> /usr/lib/linuxcnc/rt-preempt/hal_pru_generic.so 
> >> -rw-r--r-- 1 root root 19008 Nov  2 16:31 
> >> /usr/lib/linuxcnc/rt-preempt/hal_pru.so 
> >> debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ 
> >> 
> >>   
> >> 
> >>> 
> >>> 
> >>> On Saturday, November 4, 2017 at 7:00:23 PM UTC-4, Daren Schwenke 
> wrote: 
> >>>> 
> >>>> BBGW with a 'mostly' BeBoPr cape.  Hand wired, very basic, with some 
> >>>> pins moved so they didn't step on

[Machinekit] Re: hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

I noticed most of my pins were tied to PRU 1, so I moved one pin so all the 
stepgens now sit on PRU 1, and changed to PRU=1.
No change.  
The board is sitting on my desk with nothing other than a jumper closing my 
estop loop from P807 to P809.  That toggles appropriately when powering the 
machine.
I'm down to testing with just an LED+resistor at <4ma draw and I get 
nothing from any of the hal_pru_generic output pins, and no errors I can 
see.
Here is a pastebin of my /var/log/linuxcnc.log from a single startup,estop 
off, and shutdown.  I had to trim some of the shutdown from 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:
>>
>> 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 switching to rt kernel the /opt/scripts/tools way:
>> root@beaglebone:~# cd /opt/scripts/tools/
>> root@beaglebone:/opt/scripts/tools# git pull
>> Already up-to-date.
>> root@beaglebone:/opt/scripts/tools# ./update_kernel.sh --ti-rt-channel 
>> --lts-4_4
>>
>> Added machinekit repo, installed machinekit-rt-preempt
>> hal_pru_generic is of course there, so is the .so file
>>
> debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ ls -al 
> /usr/lib/linuxcnc/rt-preempt/pru_generic.bin
> lrwxrwxrwx 1 root root 40 Nov  3 06:17 
> /usr/lib/linuxcnc/rt-preempt/pru_generic.bin -> 
> /usr/lib/linuxcnc/prubin/pru_generic.bin
> debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ ls -al 
> /usr/lib/linuxcnc/prubin/pru_generic.bin
> -rw-r--r-- 1 root root 848 Nov  2 16:31 
> /usr/lib/linuxcnc/prubin/pru_generic.bin
> debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ ls -al 
> /usr/lib/linuxcnc/rt-preempt/hal_pru*
> -rw-r--r-- 1 root root 18704 Nov  2 16:31 
> /usr/lib/linuxcnc/rt-preempt/hal_prudebug.so
> -rw-r--r-- 1 root root 52360 Nov  2 16:31 
> /usr/lib/linuxcnc/rt-preempt/hal_pru_generic.so
> -rw-r--r-- 1 root root 19008 Nov  2 16:31 
> /usr/lib/linuxcnc/rt-preempt/hal_pru.so
> debian@beaglebone:~/Arcus-3D-C1-BeBoPr$
>
>  
>
>>
>>
>> On Saturday, November 4, 2017 at 7:00:23 PM UTC-4, 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 works, triggering estop and machine power correctly.
>>> halcmd shows it should be outputting PWM.
>>>576bit   IN   TRUE  hpg.pwmgen.00.out.02.enable 
>>> --l-  <== f0-pwm-enable
>>>576u32   IN 0x034D  hpg.pwmgen.00.out.02.pin 
>>> --l-
>>>576float IN  1  hpg.pwmgen.00.out.02.scale   
>>> 0.10 --l-
>>>576float IN  0.6980393  hpg.pwmgen.00.out.02.value   
>>> 0.10 --l-  <== f0-pwm
>>>
>>>
>>>
>>> Starting with PWM, cause that was easy to measure with my improvised 
>>> ghetto soundcard oscilloscope.
>>> Verified... pins, not flipping.
>>>
>>> Relevant lines from /boot/uEnv.txt
>>> debian@beaglebone:~$ egrep -v "^#|^\s*$" /boot/uEnv.txt 
>>> uname_r=4.4.91-ti-rt-r136
>>> enable_uboot_overlays=1
>>> uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
>>> enable_uboot_cape_universal=1
>>> cmdline=coherent_pool=1M net.ifnames=0 quiet
>>> debian@beaglebone:~$
>>>
>>> Any ideas?
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

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 switching to rt kernel the /opt/scripts/tools way:
> root@beaglebone:~# cd /opt/scripts/tools/
> root@beaglebone:/opt/scripts/tools# git pull
> Already up-to-date.
> root@beaglebone:/opt/scripts/tools# ./update_kernel.sh --ti-rt-channel 
> --lts-4_4
>
> Added machinekit repo, installed machinekit-rt-preempt
> hal_pru_generic is of course there, so is the .so file
>
debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ ls -al 
/usr/lib/linuxcnc/rt-preempt/pru_generic.bin
lrwxrwxrwx 1 root root 40 Nov  3 06:17 
/usr/lib/linuxcnc/rt-preempt/pru_generic.bin -> 
/usr/lib/linuxcnc/prubin/pru_generic.bin
debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ ls -al 
/usr/lib/linuxcnc/prubin/pru_generic.bin
-rw-r--r-- 1 root root 848 Nov  2 16:31 
/usr/lib/linuxcnc/prubin/pru_generic.bin
debian@beaglebone:~/Arcus-3D-C1-BeBoPr$ ls -al 
/usr/lib/linuxcnc/rt-preempt/hal_pru*
-rw-r--r-- 1 root root 18704 Nov  2 16:31 
/usr/lib/linuxcnc/rt-preempt/hal_prudebug.so
-rw-r--r-- 1 root root 52360 Nov  2 16:31 
/usr/lib/linuxcnc/rt-preempt/hal_pru_generic.so
-rw-r--r-- 1 root root 19008 Nov  2 16:31 
/usr/lib/linuxcnc/rt-preempt/hal_pru.so
debian@beaglebone:~/Arcus-3D-C1-BeBoPr$

 

>
>
> On Saturday, November 4, 2017 at 7:00:23 PM UTC-4, 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 works, triggering estop and machine power correctly.
>> halcmd shows it should be outputting PWM.
>>576bit   IN   TRUE  hpg.pwmgen.00.out.02.enable   
>>   --l-  <== f0-pwm-enable
>>576u32   IN 0x034D  hpg.pwmgen.00.out.02.pin 
>> --l-
>>576float IN  1  hpg.pwmgen.00.out.02.scale   
>> 0.10 --l-
>>576float IN  0.6980393  hpg.pwmgen.00.out.02.value   
>> 0.10 --l-  <== f0-pwm
>>
>>
>>
>> Starting with PWM, cause that was easy to measure with my improvised 
>> ghetto soundcard oscilloscope.
>> Verified... pins, not flipping.
>>
>> Relevant lines from /boot/uEnv.txt
>> debian@beaglebone:~$ egrep -v "^#|^\s*$" /boot/uEnv.txt 
>> uname_r=4.4.91-ti-rt-r136
>> enable_uboot_overlays=1
>> uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
>> enable_uboot_cape_universal=1
>> cmdline=coherent_pool=1M net.ifnames=0 quiet
>> debian@beaglebone:~$
>>
>> Any ideas?
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

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 switching to rt kernel the /opt/scripts/tools way:
root@beaglebone:~# cd /opt/scripts/tools/
root@beaglebone:/opt/scripts/tools# git pull
Already up-to-date.
root@beaglebone:/opt/scripts/tools# ./update_kernel.sh --ti-rt-channel 
--lts-4_4

Added machinekit repo, installed machinekit-rt-preempt
hal_pru_generic is of course there, so is the .so file


On Saturday, November 4, 2017 at 7:00:23 PM UTC-4, 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 works, triggering estop and machine power correctly.
> halcmd shows it should be outputting PWM.
>576bit   IN   TRUE  hpg.pwmgen.00.out.02.enable   
>   --l-  <== f0-pwm-enable
>576u32   IN 0x034D  hpg.pwmgen.00.out.02.pin   
>   --l-
>576float IN  1  hpg.pwmgen.00.out.02.scale 
>   0.10 --l-
>576float IN  0.6980393  hpg.pwmgen.00.out.02.value 
>   0.10 --l-  <== f0-pwm
>
>
>
> Starting with PWM, cause that was easy to measure with my improvised 
> ghetto soundcard oscilloscope.
> Verified... pins, not flipping.
>
> Relevant lines from /boot/uEnv.txt
> debian@beaglebone:~$ egrep -v "^#|^\s*$" /boot/uEnv.txt 
> uname_r=4.4.91-ti-rt-r136
> enable_uboot_overlays=1
> uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
> enable_uboot_cape_universal=1
> cmdline=coherent_pool=1M net.ifnames=0 quiet
> debian@beaglebone:~$
>
> Any ideas?
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] hal_pru_generic not making steps/pwm, Debian Stretch 4.4.91-ti-rt kernel, BBGW

[Daren Schwenke]

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 outputting PWM.
   576bit   IN   TRUE  hpg.pwmgen.00.out.02.enable 
--l-  <== f0-pwm-enable
   576u32   IN 0x034D  hpg.pwmgen.00.out.02.pin 
--l-
   576float IN  1  hpg.pwmgen.00.out.02.scale   
0.10 --l-
   576float IN  0.6980393  hpg.pwmgen.00.out.02.value   
0.10 --l-  <== f0-pwm



Starting with PWM, cause that was easy to measure with my improvised ghetto 
soundcard oscilloscope.
Verified... pins, not flipping.

Relevant lines from /boot/uEnv.txt
debian@beaglebone:~$ egrep -v "^#|^\s*$" /boot/uEnv.txt 
uname_r=4.4.91-ti-rt-r136
enable_uboot_overlays=1
uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
enable_uboot_cape_universal=1
cmdline=coherent_pool=1M net.ifnames=0 quiet
debian@beaglebone:~$

Any ideas?

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: Goldibox

[Daren Schwenke]

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://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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: Goldibox

[Daren Schwenke]

For simple PWM control you can get away with using just a logic level power 
MOSFET 
<http://www.moodle2.tfe.umu.se/pluginfile.php/45884/mod_resource/content/1/Infineon-2N06L07-datasheet.pdf>
 
and two resistors for a total cost of less than $1 and no heatsink.  For a 
real hack you can even eliminate the resistors.  :)
But to build it yourself with current reversing, the component count goes 
up to at least 6 and uses more expensive P channel MOSFETs.  At that point 
you are better off with an IC but 4A will cost you more
Alternately you could just use an RC brushed motor ESC..  A 3S (3 cell lipo 
= 12.6v rating) one *with reversing* should run you about $10 and then you 
only need one PWM output to control everything.  I've never had an issue 
driving one of these directly from a beaglebone.

On Wednesday, November 1, 2017 at 1:50:13 PM UTC-4, John Morris wrote:
>
> [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: 
> > 
> > When switching peltiers between heat/cool mode you can get some 
> > really high currents. 
> > 
> > 
> > I don't know much about it.  This one is rated 48W/12V, so I used a 
> > cheapo L298N module, 2 channels at 2A/channel, wired together.  (I'm 
> > not sure if that's allowed, but it seems to work.)  Do you mean 
> > higher current than 4A? 
> > 
> > 
> > The L298N uses internal bipolar transistors.  The device drops some 
> > volts and burns up a lot of energy in the process.   I would go with any 
> > MOSFET based h-bridge rather then the L298.  The298 has been obsolete 
> > for years. Ad will require a big heat sink and I think a fan.A 
> > modern device will not require a heat sink and not get hot. 
>
> I picked that one because they're available cheap on a PCB with extra 
> circuitry marketed to the Arduino folks.  It does come with a heatsink, 
> and it's near the Peltier fan in my box. 
>
> I'm not married to the thing, though.  If there's another solution 
> that's better and not much harder, let me know.  There's a 
> VNH2SP30-based (datasheet [1]) "Monster Moto Shield", 30A MOSFET, for 
> example. 
>
> [1]: http://www.st.com/resource/en/datasheet/cd00043711.pdf 
>
> > I don't understand the use of Machine Kit for this.  Everyone else 
> > builds these using a $1 micro controller.  It is actually MUCH easier. 
> > This is the perfect project o use one of these $3 STM32 boards   
> >   Perhaps this is just an exercise? 
>
> The value IMO is in the demonstration of a full integration from 
> electronics to remote GUI, and in the overall simplicity for learners. 
> Maybe it's the lesson that comes after Alex's AND-Demo. 
>
> I know enough about microcontrollers to know the basic control functions 
> could easily be done on an STM32 board, and there's probably enough 
> memory to do some logging, too.  I'd believe if you said there's a good 
> way to build a network-connected remote interface and (maybe even 
> cross-platform) GUI, and $3 is a fantastic price point (the BB WiFi 
> adapter cost more than that).  You're right, the value of this project 
> can't be judged by the efficiency of using Machinekit on a Beagle for a 
> thermostat.  I still hope there's value in the lesson, and anyway, like 
> that guy in True Grit using a horse pistol to shoot rats, it's fun. 
>
> Actually, this is really my first GUI ever, and my own eyes were 
> certainly opened.  With haltalk and QtQuickVCP, the whole GUI took zero 
> lines of code outside the remote comp's ~dozen python lines to create 
> pins.  Really amazing stuff. 
>
> John 
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: Goldibox

[Daren Schwenke]

Just hook up your power full on in one direction and let it equalize so the 
junction is at temperature.
Then reverse the power leads and measure the current.  
It will probably exceed your 48W/4A rating until the junction temperature 
differential swings the other way.

If you are using a motor driver chip, it will probably limit the max output 
current for you.
I don't know if the L298N has a mosfet output stage.  It probably does.  If 
your input timing is good, then running two in parallel should work fine.

Just wanted you to be aware of the possibility of you browning out your 
supply 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 really 
> > high currents. 
>
> I don't know much about it.  This one is rated 48W/12V, so I used a 
> cheapo L298N module, 2 channels at 2A/channel, wired together.  (I'm not 
> sure if that's allowed, but it seems to work.)  Do you mean higher 
> current than 4A? 
>
> > 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. 
>
> I still need to stick PID comps in there.  Right now, it's a dumb 
> switch, which is why the curve in the time series chart is so bad. 
>
> By "current feedback", do you mean monitor current through the Peltier? 
> How do I limit the PWM?  Sorry, you're going to have to spell it out for 
> me.  I'm pretty bad at electronics. 
>
> > On Wednesday, November 1, 2017 at 11:04:36 AM UTC-4, Daren Schwenke 
> wrote: 
> > 
> > Neat idea, and perfect name.  :) 
>
> Thanks! 
>
> John 
>
>
>
> > 
> > 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 thermostat, and as the 
> name 
> > implies, the Goldibox will keep its contents not too hot, not 
> > too cold, 
> > but just right. 
> > 
> > The last major piece I'd like to do is improve the GUI, but I'll 
> > need 
> > some help.  First, take a look at this mock-up of a fancy 
> > thermostat 
> > [2], which combines quite a few controls and gauges into one. 
> >   If this 
> > isn't a very difficult thing to program using either QML or C++ 
> > code, 
> > I'd do it.  Second, below the thermostat, I'd like to add a 
> small 
> > version of the time-series graph (see [1]).  This is generated 
> > on the 
> > Goldibox, and would need to be fetched by the remote GUI. 
> > 
> > Other than that, it needs a PID control and a few cleanups 
> > before it's 
> > done, and then I'd like to show it off to the Machinekit and 
> > (Pocket)Beagle communities.  It seems like the project could be 
> > interesting because it integrates the (brand-new) PocketBeagle, 
> > electronics, Machinekit and QtQuickVCP, and as such represents a 
> > demo of 
> > the complete chain from hardware to phone app.  At the same 
> > time, it's 
> > still fairly simple, with complexity just a step above Alex's 
> > AND-Demo. 
> > Of course it's all open source, and I tried to make it easy for 
> > anyone 
> > to try out the simulator in Docker by running just a few 
> > commands (but 
> > expect a few minor hiccups ATM if you do). 
> > 
> > I'd highly appreciate help with the GUI, and I welcome your 
> > comments 
> > about the project. 
> > 
> > [1]: https://github.com/zultron/goldibox 
> > <https://github.com/zultron/goldibox> 
> > [2]: 
> > 
> https://docs.google.com/drawings/d/1ixn3tSA8_OyTdZ1lz5k4MWjTZ9rEFJM9or3oYW8NuUA/edit?usp=sharing
>  
> > <
> https://docs.google.com/drawings/d/1ixn3tSA8_OyTdZ1lz5k4MWjTZ9rEFJM9or3oYW8NuUA/edit?usp=sharing>
>  
>
> > 
> > 
> >  John 
> > 
> > -- 
> > website: http://www.machinekit.io blog: http://bl

[Machinekit] Re: Goldibox

[Daren Schwenke]

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 wrote:
>
> 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 thermostat, and as the name 
>> implies, the Goldibox will keep its contents not too hot, not too cold, 
>> but just right. 
>>
>> The last major piece I'd like to do is improve the GUI, but I'll need 
>> some help.  First, take a look at this mock-up of a fancy thermostat 
>> [2], which combines quite a few controls and gauges into one.  If this 
>> isn't a very difficult thing to program using either QML or C++ code, 
>> I'd do it.  Second, below the thermostat, I'd like to add a small 
>> version of the time-series graph (see [1]).  This is generated on the 
>> Goldibox, and would need to be fetched by the remote GUI. 
>>
>> Other than that, it needs a PID control and a few cleanups before it's 
>> done, and then I'd like to show it off to the Machinekit and 
>> (Pocket)Beagle communities.  It seems like the project could be 
>> interesting because it integrates the (brand-new) PocketBeagle, 
>> electronics, Machinekit and QtQuickVCP, and as such represents a demo of 
>> the complete chain from hardware to phone app.  At the same time, it's 
>> still fairly simple, with complexity just a step above Alex's AND-Demo. 
>> Of course it's all open source, and I tried to make it easy for anyone 
>> to try out the simulator in Docker by running just a few commands (but 
>> expect a few minor hiccups ATM if you do). 
>>
>> I'd highly appreciate help with the GUI, and I welcome your comments 
>> about the project. 
>>
>> [1]: https://github.com/zultron/goldibox 
>> [2]: 
>>
>> https://docs.google.com/drawings/d/1ixn3tSA8_OyTdZ1lz5k4MWjTZ9rEFJM9or3oYW8NuUA/edit?usp=sharing
>>  
>>
>> John 
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Goldibox

[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 thermostat, and as the name 
> implies, the Goldibox will keep its contents not too hot, not too cold, 
> but just right. 
>
> The last major piece I'd like to do is improve the GUI, but I'll need 
> some help.  First, take a look at this mock-up of a fancy thermostat 
> [2], which combines quite a few controls and gauges into one.  If this 
> isn't a very difficult thing to program using either QML or C++ code, 
> I'd do it.  Second, below the thermostat, I'd like to add a small 
> version of the time-series graph (see [1]).  This is generated on the 
> Goldibox, and would need to be fetched by the remote GUI. 
>
> Other than that, it needs a PID control and a few cleanups before it's 
> done, and then I'd like to show it off to the Machinekit and 
> (Pocket)Beagle communities.  It seems like the project could be 
> interesting because it integrates the (brand-new) PocketBeagle, 
> electronics, Machinekit and QtQuickVCP, and as such represents a demo of 
> the complete chain from hardware to phone app.  At the same time, it's 
> still fairly simple, with complexity just a step above Alex's AND-Demo. 
> Of course it's all open source, and I tried to make it easy for anyone 
> to try out the simulator in Docker by running just a few commands (but 
> expect a few minor hiccups ATM if you do). 
>
> I'd highly appreciate help with the GUI, and I welcome your comments 
> about the project. 
>
> [1]: https://github.com/zultron/goldibox 
> [2]: 
>
> https://docs.google.com/drawings/d/1ixn3tSA8_OyTdZ1lz5k4MWjTZ9rEFJM9or3oYW8NuUA/edit?usp=sharing
>  
>
> John 
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: Arcus3D-C1 Open source tripodkins cable printer.

[Daren Schwenke]

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 cash ran out 
while tooling up.

But this one is totally open source, I can work on it basically for free, 
and it gets/keeps the name out there while we get the above sorted out.

On Monday, October 16, 2017 at 3:09:47 PM UTC-4, Marco Negrini wrote:
>
> Nice printer!
>
> Can I ask you a question about the Arcus-3d-M2, here?
> I remember reading that you were trying to make the extruder as an open 
> source project, how is it going? 
>
> I would really like to use it for its speed!
>
> Regards,
> Marco Negrini
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Arcus3D-C1 Open source tripodkins cable printer.

[Daren Schwenke]

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 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: 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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Arcus3D-C1 Open source tripodkins cable printer.

[Daren Schwenke]

If someone wants to help with combining the newer pythonic machinetalk 
configs with tripodkins, I'll give you equal billing on the hackaday 
page...  :)
The OpenSCAD source is there for the hardware with all the tolerances 
tweaked already, so you can print your own.

On Saturday, October 7, 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/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
>>
>>  I use a compression spring on the rod pushing on the mounting point for 
> the three.
>
>> That's nice to see! You use a spring to keep tension on the threads? 
>> Looking forward to your progress. Should be a very lightweight effector!
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Arcus3D-C1 Open source tripodkins cable printer.

[Daren Schwenke]

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 like it will 
> work now, so soon.
>
> https://hackaday.io/project/26938-arcus-3d-c1-cable-printer
>
> https://youtu.be/KQ19fT4BQQU
>
>  I use a compression spring on the rod pushing on the mounting point for 
the three.

> That's nice to see! You use a spring to keep tension on the threads? 
> Looking forward to your progress. Should be a very lightweight effector!
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Arcus3D-C1 Open source tripodkins cable printer.

[Daren Schwenke]

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: 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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: Machinekit at the Milwaukee Maker Fair.

[Daren Schwenke]

Damage from Irma: About 2 cubic yards of tree branches around the yard and 
everything was dirty.  The wind pushed water through the windows which were 
not covered/sealed in minor amounts.  That was about it.  We did get lucky 
that it broke inland and the winds that got us were coming from across 
land.  
Cleanup from the preparations was/is more labor intensive than the 
hurricane itself.  The ice blocks for the fridge are still melting in the 
sink 4 days later.  We never lost power.

On Thursday, September 14, 2017 at 7:43:02 AM UTC-4, Tom M wrote:
>
> Oh boy.. see you around the next event.  (Did you take any damage from 
> Irma?)
> I'm trying to get switched over to Charles probotix solution on my MPCNC.  
> I'm currently running gantrykins and I keep forgetting to switch between 
> world and joint when I'm homing.  I wind up inadvertently racking 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.
>
>
>
> On Sep 14, 2017 2:47 AM, "Daren Schwenke"  > wrote:
>
>> 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 subdirectory to override it like in 
>> the Rostock config I borrowed from machinekoder) the delta_r or rod length 
>> is ignored.  So 0,0,0 was below the bed.  I slowly approached it, but the 
>> interface didn't register my stop command until it was too late... so I got 
>> to watch it slowly destroy my bed.  :)
>> My fault for removing the physical estop button for aesthetic reasons..
>>
>> Prime is screwy due to Irma so parts wouldn't get here in time for me to 
>> fabricate them, and I can't find a suitable polished ceramic tile locally.
>> So... I'm not going.
>>
>> On Sunday, September 10, 2017 at 9:35:37 PM UTC-4, Tom M wrote:
>>>
>>>
>>> Hey Guy's,
>>>
>>> If anyone is going to be at the Milwaukee Maker Faire feel free to stop 
>>> by and say hi.
>>>
>>> https://milwaukee.makerfaire.com/maker/entry/275/
>>>
>>> Daren Schewenke is going to be there as well.
>>> https://milwaukee.makerfaire.com/maker/entry/277/
>>>
>>> Tom
>>>
>> -- 
>> website: http://www.machinekit.io blog: http://blog.machinekit.io 
>> github: https://github.com/machinekit
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Machinekit" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/machinekit/Z84ZyZTkfe4/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> machinekit+...@googlegroups.com .
>> Visit this group at https://groups.google.com/group/machinekit.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: Machinekit at the Milwaukee Maker Fair.

[Daren Schwenke]

Mine was working well, but without retraction.
Retraction had way too much pre-charge and it wasn't linear with what I set 
retraction to.
Rather than figure that out as I had some other minor annoyances, I opted 
to go for the latest and greatest and put my extra stuff into that.
In prior iterations I had a microswitch on the head tied to estop.  Not 
this one.  Crash, bang, done.

On Thursday, September 14, 2017 at 7:43:02 AM UTC-4, Tom M wrote:
>
> Oh boy.. see you around the next event.  (Did you take any damage from 
> Irma?)
> I'm trying to get switched over to Charles probotix solution on my MPCNC.  
> I'm currently running gantrykins and I keep forgetting to switch between 
> world and joint when I'm homing.  I wind up inadvertently racking 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.
>
>
>
> On Sep 14, 2017 2:47 AM, "Daren Schwenke"  > wrote:
>
>> 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 subdirectory to override it like in 
>> the Rostock config I borrowed from machinekoder) the delta_r or rod length 
>> is ignored.  So 0,0,0 was below the bed.  I slowly approached it, but the 
>> interface didn't register my stop command until it was too late... so I got 
>> to watch it slowly destroy my bed.  :)
>> My fault for removing the physical estop button for aesthetic reasons..
>>
>> Prime is screwy due to Irma so parts wouldn't get here in time for me to 
>> fabricate them, and I can't find a suitable polished ceramic tile locally.
>> So... I'm not going.
>>
>> On Sunday, September 10, 2017 at 9:35:37 PM UTC-4, Tom M wrote:
>>>
>>>
>>> Hey Guy's,
>>>
>>> If anyone is going to be at the Milwaukee Maker Faire feel free to stop 
>>> by and say hi.
>>>
>>> https://milwaukee.makerfaire.com/maker/entry/275/
>>>
>>> Daren Schewenke is going to be there as well.
>>> https://milwaukee.makerfaire.com/maker/entry/277/
>>>
>>> Tom
>>>
>> -- 
>> website: http://www.machinekit.io blog: http://blog.machinekit.io 
>> github: https://github.com/machinekit
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Machinekit" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/machinekit/Z84ZyZTkfe4/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> machinekit+...@googlegroups.com .
>> Visit this group at https://groups.google.com/group/machinekit.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Machinekit at the Milwaukee Maker Fair.

[Daren Schwenke]

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 subdirectory to override it like in 
the Rostock config I borrowed from machinekoder) the delta_r or rod length 
is ignored.  So 0,0,0 was below the bed.  I slowly approached it, but the 
interface didn't register my stop command until it was too late... so I got 
to watch it slowly destroy my bed.  :)
My fault for removing the physical estop button for aesthetic reasons..

Prime is screwy due to Irma so parts wouldn't get here in time for me to 
fabricate them, and I can't find a suitable polished ceramic tile locally.
So... I'm not going.

On Sunday, September 10, 2017 at 9:35:37 PM UTC-4, Tom M wrote:
>
>
> Hey Guy's,
>
> If anyone is going to be at the Milwaukee Maker Faire feel free to stop by 
> and say hi.
>
> https://milwaukee.makerfaire.com/maker/entry/275/
>
> Daren Schewenke is going to be there as well.
> https://milwaukee.makerfaire.com/maker/entry/277/
>
> Tom
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: hal_temp_bbb locked up, now.

[Daren Schwenke]

:42:10 ...
 kernel:[59891.328352] ff60: df557580 df521600  000b2c08 0003 
  c00fa5fd

Message from syslogd@beaglebone at Feb  8 20:42:10 ...
 kernel:[59891.338443] ff80:    b6efb5e0 0003 
000b2c08 0004 c000cb48

Message from syslogd@beaglebone at Feb  8 20:42:10 ...
 kernel:[59891.348350] ffa0: df63e000 c000c941 b6efb5e0 0003 0001 
000b2c08 0003 

Message from syslogd@beaglebone at Feb  8 20:42:10 ...
 kernel:[59891.358532] ffc0: b6efb5e0 0003 000b2c08 0004 be97ca6c 
000ad06c 000b3459 000b3458

Message from syslogd@beaglebone at Feb  8 20:42:10 ...
 kernel:[59891.368532] ffe0: 0003 be97c9f0 b6e668f1 b6ea26bc 4010 
0001  

Message from syslogd@beaglebone at Feb  8 20:42:10 ...
 kernel:[59891.677626] Code: 4604 b108 f8d0 41c8 (7ee3) 2b01 
machinekit@beaglebone:/sys/devices/bone_capemgr.9$ ls
baseboard  driver  modalias  power  slot-4  slot-5  slot-6  slot-7  slot-8 
 slots  subsystem  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 
> > /sys/devices/ocp.3/44e0d000.tscadc/tiadc/iio:device0/in_voltage4_raw 
> > -rw-r--r-- 1 root root 4096 Feb  8 04:07 
> > /sys/devices/ocp.3/44e0d000.tscadc/tiadc/iio:device0/in_voltage4_raw 
> > machinekit@beaglebone:~/git/Arcus-3D-M2$ cat 
> > /sys/devices/ocp.3/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 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. 
> >> 
> > 
>
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: hal_temp_bbb locked up, now.

[Daren Schwenke]

I don't know what else to grab here, and I need the machine back soon.

machinekit@beaglebone:/sys/bus/iio/devices/iio:device0$ lsmod
Module  Size  Used by
xeno_can_c_can  9479  0 
xeno_can   19360  1 xeno_can_c_can
c_can_platform  4293  0 
uio_pruss   4058  1 
c_can   7764  1 c_can_platform
can_dev 8361  1 c_can
g_ether24066  0 
libcomposite   15032  1 g_ether
cpufreq_userspace   2013  0 
omap_rng4054  0 

machinekit@beaglebone:/sys/bus/iio/devices/iio:device0$ ls
dev  in_voltage0_raw  in_voltage1_raw  in_voltage2_raw  in_voltage3_raw 
 in_voltage4_raw  in_voltage5_raw  in_voltage6_raw  in_voltage7_raw  name 
 power  subsystem  uevent
machinekit@beaglebone:/sys/bus/iio/devices/iio:device0$ cat *
249:0
cat: in_voltage0_raw: Resource temporarily unavailable
cat: in_voltage1_raw: Resource temporarily unavailable
cat: in_voltage2_raw: Resource temporarily unavailable
cat: in_voltage3_raw: Resource temporarily unavailable
cat: in_voltage4_raw: Resource temporarily unavailable
cat: in_voltage5_raw: Resource temporarily unavailable
cat: in_voltage6_raw: Resource temporarily unavailable
cat: in_voltage7_raw: Resource temporarily unavailable
tiadc
cat: power: Is a directory
cat: subsystem: Is a directory
MAJOR=249
MINOR=0
DEVNAME=iio:device0
DEVTYPE=iio_device
machinekit@beaglebone:/sys/bus/iio/devices/iio:device0$

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 updates.
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: BBB and Axis gui

[Daren Schwenke]

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-preempt kernel works now, but it consumes more CPU than 
xenomai did.  I have not tested running Axis or if hardware acceleration 
works yet.

You could ditch Axis altogether and run Cetus, which is a remote interface 
if that suits you.
It runs on your PC instead and talks back to machinekit via services.  As a 
plus you can connect/disconnect at will and the machine will run 'headless' 
while you are disconnected.



On Tuesday, September 5, 2017 at 4:51:21 PM UTC-4, Harley Engholm wrote:
>
> Is there a gui for a 3 axis cnc setup that uses less memory than Axis? And 
> if so, will this affect response and accuracy?
> Harley
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: hal_temp_bbb locked up, now.

[Daren Schwenke]

machinekit@beaglebone:~/git/Arcus-3D-M2$ ls -al 
/sys/devices/ocp.3/44e0d000.tscadc/tiadc/iio:device0/in_voltage4_raw
-rw-r--r-- 1 root root 4096 Feb  8 04:07 
/sys/devices/ocp.3/44e0d000.tscadc/tiadc/iio:device0/in_voltage4_raw
machinekit@beaglebone:~/git/Arcus-3D-M2$ cat 
/sys/devices/ocp.3/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 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 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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: hal_temp_bbb locked up, now.

[Daren Schwenke]

Grabbed an strace, looks like the device went away.
Anything else I should grab here?

Process 1823 attached - interrupt to quit
read(12, 0xb6fd, 4096)  = -1 EAGAIN (Resource temporarily 
unavailable)
select(0, NULL, NULL, NULL, {0, 5}) = 0 (Timeout)
open("/sys/devices/ocp.3/44e0d000.tscadc/tiadc/iio:device0/in_voltage4_raw", 
O_RDONLY|O_LARGEFILE) = 9
fstat64(9, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
close(12)   = 0
munmap(0xb6fd, 4096)= 0
fstat64(9, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb6fd
read(9, 0xb6fd, 4096)   = -1 EAGAIN (Resource temporarily 
unavailable)
select(0, NULL, NULL, NULL, {0, 5}) = 0 (Timeout)
open("/sys/devices/ocp.3/44e0d000.tscadc/tiadc/iio:device0/in_voltage4_raw", 
O_RDONLY|O_LARGEFILE) = 12
fstat64(12, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
close(9)= 0
munmap(0xb6fd, 4096)= 0
fstat64(12, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb6fd
read(12, 0xb6fd, 4096)  = -1 EAGAIN (Resource temporarily 
unavailable)
select(0, NULL, NULL, NULL, {0, 5}) = 0 (Timeout)
open("/sys/devices/ocp.3/44e0d000.tscadc/tiadc/iio:device0/in_voltage4_raw", 
O_RDONLY|O_LARGEFILE) = 9
fstat64(9, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
close(12)   = 0
munmap(0xb6fd, 4096)= 0
fstat64(9, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb6fd
read(9, 0xb6fd, 4096)   = -1 EAGAIN (Resource temporarily 
unavailable)
select(0, NULL, NULL, NULL, {0, 5}) = 0 (Timeout)
open("/sys/devices/ocp.3/44e0d000.tscadc/tiadc/iio:device0/in_voltage4_raw", 
O_RDONLY|O_LARGEFILE) = 12
fstat64(12, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
close(9)= 0
munmap(0xb6fd, 4096)= 0
fstat64(12, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb6fd
read(12, 0xb6fd, 4096)  = -1 EAGAIN (Resource temporarily 
unavailable)
select(0, NULL, NULL, NULL, {0, 5}) = 0 (Timeout)
open("/sys/devices/ocp.3/44e0d000.tscadc/tiadc/iio:device0/in_voltage4_raw", 
O_RDONLY|O_LARGEFILE) = 9
fstat64(9, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
close(12)   = 0
munmap(0xb6fd, 4096)= 0
fstat64(9, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb6fd
read(9, 0xb6fd, 4096)   = -1 EAGAIN (Resource temporarily 
unavailable)
select(0, NULL, NULL, NULL, {0, 5}) = 0 (Timeout)
open("/sys/devices/ocp.3/44e0d000.tscadc/tiadc/iio:device0/in_voltage4_raw", 
O_RDONLY|O_LARGEFILE) = 12
fstat64(12, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
close(9)= 0
munmap(0xb6fd, 4096)= 0
fstat64(12, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb6fd
read(12, 0xb6fd, 4096)  = -1 EAGAIN (Resource temporarily 
unavailable)
select(0, NULL, NULL, NULL, {0, 5}) = 0 (Timeout)
open("/sys/devices/ocp.3/44e0d000.tscadc/tiadc/iio:device0/in_voltage4_raw", 
O_RDONLY|O_LARGEFILE) = 9
fstat64(9, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
close(12)   = 0
munmap(0xb6fd, 4096)= 0
fstat64(9, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb6fd
read(9, 0xb6fd, 4096)   = -1 EAGAIN (Resource temporarily 
unavailable)
select(0, NULL, NULL, NULL, {0, 5}) = 0 (Timeout)
open("/sys/devices/ocp.3/44e0d000.tscadc/tiadc/iio:device0/in_voltage4_raw", 
O_RDONLY|O_LARGEFILE) = 12
fstat64(12, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
close(9)= 0
munmap(0xb6fd, 4096)= 0
fstat64(12, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -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 updates.
>

-- 
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] hal_temp_bbb locked up, now.

[Daren Schwenke]

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 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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Running 3D Printer using Machinekit + CRAMPS + BBB

[Daren Schwenke]

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, 2017 at 1:35:21 PM UTC-4, machinen wrote:
>
> Hi,
> I am in somewhat similar situation to yours and I have few questions for 
> you:
>
> Were you able to upgrade your installation? Because the ready-made image 
> for BBB is quite old and when doing update/upgrade, the Machinekit 
> package(s) is(are) being kept back and it is because dependency error. The 
> same is when installing on new clean system flash (which are newer) by the 
> how to in Machinekit docs.
>
> Are you able to shutdown/poweroff/reboot your BBB with CRAMPS? I have the 
> Element14 BBB rev. C with CRAMPS 2.2 and I cannot shut it down completely. 
> The power on LED is still on and there are two LEDs on on CRAMPS and on the 
> right side of RIJ45 connector (bank of four LEDs) there is one LED faintly 
> blinking. Otherwise the BBB is turned off (I cannot SSH to it). I have to 
> manually shut the power down. Are you experiencing the same?
>
> And given the above, hoare you able to run the fabrikator Mini CRAMPS 
> configuration out of the box? My system is screaming at me about missing 
> fdm.config. Maybe it is because old machinekit (but as I said, currently 
> the dependency is broken), the actual error is:
> halcmd loadusr io started
> Traceback (most recent call last):
>   File "fabrikator_mini.py", line 8, in 
> from fdm.config import velocity_extrusion as ve
> ImportError: No module named config
> Shutting down and cleaning up Machinekit...
>
> Thanks.
>
> On Tuesday, August 29, 2017 at 8:08:30 AM UTC+2, Pranav Pandey wrote:
>>
>> Hi Folks,
>>
>> This is my first post on this group. I am working on integrating 3d 
>> printing and CNC Milling in a single machine. I have worked with Arduino 
>> Mega before and have run the machine on the Marlin firmware.
>>
>> However I am interested in using the Machine kit platform to run my 3d 
>> printer. My background is Electrical and hence have only basic knowledge 
>> about coding. I would like to know if someone has successfully 3D Printed 
>> using the above setup. If yes, Can you please share some links or procedure 
>> for the same?
>>
>> Thanks
>> Pranav
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] M-Code errors

[Daren Schwenke]

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 2017, at 14:11, Pranav Pandey > 
>> wrote:
>>
>> It clearly states you are missing a ‘P’ argument
>>> so take a look at your g-code where M190 is used and see if it has a P 
>>> argument
>>>
>>
>> Yes, It was the first thing I did. I forgot to mention the g-code. 
>>
>> M190 S60
>>
>> This is the one generated by Cura plugin with Mach3 flavor. I want to try 
>> running this without modifying this g-code.  
>>
>>
>> No you don’t want to do that.
>>
>> You want to have the g-code file with correct output, and thus correct 
>> input for Machinekit. Did you correctly install machinekoder his cura 
>> plugin? That plugin (with cure 2.1.3) should take care of that.
>>
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: M-Code errors

[Daren Schwenke]

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 replaced by commands to 'start extruding' and 'stop extruding'. 
 How much to extrude will be dynamically calculated.

On Wednesday, August 30, 2017 at 10:24:20 AM UTC-4, Pranav Pandey wrote:
>
> 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 trajectory planner doesn't work as well with > 3 axis.  The 
>> solution to that is 'velocity extrusion'.  There is no E then, so 3 axis 
>> will do it.
>>
>
> Thanks for this !
>  
>
>> Start here:
>> http://machinekoder.com/machinekit-and-cura/ for integrating cura.  It's 
>> a plugin to directly produce the ngc files from cura which velocity 
>> extrusion uses.  
>> The reason you are getting the errors is differences in what the slicers 
>> output compared to real gcode.  They break some rules from real gcode, and 
>> add some things.
>>
>
> I tried integrating Cura plugin but am still encountering M code errors. 
> :( 
>  
>
>> Here is a config made for Machineface and velocity extrusion.
>> https://github.com/machinekoder/Fabrikator-Mini-CRAMPS
>> This has been integrated into machinekit though, so you'll find it in 
>> configs, and it's built for CRAMPS too I believe.
>>
>
> The one integrated into machinekit is not working. The CRAMPS config is 
> fine but this one and few others are not working. A long list of error file 
> pops up.
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: M-Code errors

[Daren Schwenke]

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 trajectory planner doesn't work as well with > 3 axis.  The 
solution to that is 'velocity extrusion'.  There is no E then, so 3 axis 
will do it.

Start here:
http://machinekoder.com/machinekit-and-cura/ for integrating cura.  It's a 
plugin to directly produce the ngc files from cura which velocity extrusion 
uses.  
The reason you are getting the errors is differences in what the slicers 
output compared to real gcode.  They break some rules from real gcode, and 
add some things.

Here is a config made for Machineface and velocity extrusion.
https://github.com/machinekoder/Fabrikator-Mini-CRAMPS
This has been integrated into machinekit though, so you'll find it in 
configs, and it's built for CRAMPS too I believe.

git clone Machineface into your home dir
git clone that config your home dir also.

Edit /etc/linuxcnc/machinekit.ini and set REMOTE=1
Download machinekit client somewhere.
cd into the config dir.
./run.py to test for errors.  If you get to 'interpreter', control C out of 
it.
then mklauncher . with start it up so machinekit-client can connect to it.


On Tuesday, August 29, 2017 at 11:13:44 AM UTC-4, Pranav Pandey wrote:
>
> I am using CRAMPS configuration on machine kit running on BBB. For slicing 
> I am using the Slic3r 1.2.9 release. On importing g-code from Slic3r into 
> the Axis UI I am getting errors like "Unknown M Code Mxx, Mxx.."
>
> Is there a possible solution for it?
>
> Thanks
> Pranav
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: machinekit post processor

[Daren Schwenke]

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 traces the letters and will cut full depth on first 
pass.  I wouldn't try it on anything harder than pine.

On Tuesday, August 15, 2017 at 8:38:04 PM UTC-4, Harley Engholm wrote:
>
> I am using Vectric Cut2d for my designs and have been using EMC2 post 
> processors for the g code creation. Everything works except that the 
> text on engravings are somewhat distorted, ie a straight line on the 
> bottom of an "L" is curved. Also circles are not complete, there is a very 
> small opening at the ends. All of the distortions seem to be the identical 
> when repeating  an engraved word, so it seems that it may be more of a code 
> issue than a mechanical issue. I am wondering if anyone else has had this 
> problem and if there is a dedicated post processor for machinekit running 
> on a BBB.
>
> Harley 
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Machinekit on the BeagleBone Green Wireless (BBGW) + CRAMPS

[Daren Schwenke]

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 machine+  20   0   21892  13808  11512 S  2.9  2.7   0:02.96 milltask 
   
1 root  20   0   24748   4568   3540 S  1.3  0.9   0:07.48 systemd 

 1207 root  20   0   15768   3852   3516 S  1.3  0.8   0:01.67 
systemd-journal 
 1775 message+  20   04868   2644   2156 S  1.3  0.5   0:01.23 
dbus-daemon 
 3841 machine+  20   04560   2080   1712 R  1.0  0.4   0:00.60 top 

4 root  -2   0   0  0  0 S  0.3  0.0   0:00.67 
ktimersoftd/0   
   10 root  20   0   0  0  0 S  0.3  0.0   0:00.83 rcuc/0   
   
 1746 root  20   0   30508   2516   1788 S  0.3  0.5   0:00.35 rsyslogd 
   

On Wednesday, September 28, 2016 at 6:10:09 AM UTC-4, Unai Antero wrote:
>
> Dear all,
>
> trying to use a SeeedStudio BeagleBone Green Wireless (+ the CRAMPS 
> board) to run machinekit, but without much success...
>
> Tried using the SD image on 
> https://rcn-ee.com/rootfs/bb.org/testing/2016-09-18/machinekit/bone-debian-8.6-machinekit-armhf-2016-09-18-4gb.img.xz
>  
> , but although it works fine on a Beagle Bone Black, the BB Green Wireless 
> refuses to boot (seems it doesn't like the 3.8 kernel...).
>
> On a second attempt, was able to start from a fresh Debian Jessie on the 
> BeagleBone Green Wireless (that uses the 4.4.9 kernel), installed 
> the 4.4.9-bone-rt-r10 kernel, and installed machinekit-rt-preempt (apt-get 
> install from packages at http://deb.machinekit.io/debian)
>
> Machinekit tries to start the CRAMPS setup, but fails as it expects things 
> to be in /sys/devices/bone_capemgr.*/slots  and on this kernel, seems 
> things are on /sys/devices/platform/bone_capemgr/slots (among other 
> changes...)
>
> Has anyone been able to run machinekit on the BeagleBone Green Wireless? 
>
> Thanks
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Machinekit on the BeagleBone Green Wireless (BBGW) + CRAMPS

[Daren Schwenke]

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 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 with no issues.
> I've only tested on the BBG thus far.  I don't forsee any issues with the 
> BBGW other than configuring it headless is confusing me as it uses 
> connmanctl.
>
> Steps:
> Download the image Robert has made for this: 
> https://rcn-ee.net/rootfs/bb.org/testing/2017-07-28/machinekit/bone-debian-8.9-machinekit-armhf-2017-07-28-4gb.img.xz
> Login as machinekit:machinekit.
> sudo apt-get update
> cd /usr/lib/linuxcnc/
> # save some files we need from xenomai
> sudo tar -cvpf xenomai.tar xenomai/pru*
> # remove it.
> sudo apt-get remove --purge machinekit-xenomai
> # install rt-preempt
> sudo apt-get install machinekit-rt-preempt
> # put the saved files back
> sudo tar -xvf xenomai.tar
> # move a couple from preempt to xenomai
> sudo cp -p rt-preempt/hal_pru* xenomai/
>
> #now edit /usr/bin/hal_temp_bbb and on line 154 change it so it reads:
> #syspath = '/sys/bus/iio/devices/iio:device0/'
>
> That's it.  Load your config and give it a try.
> I noted that the maximum command line length for loadrt has gone down and 
> I needed to split some of my loadrt entries to make them work, but due to a 
> recent patch, you can do that at least.
> I also noted that many of the example configs are out dated and explode 
> due to changes in parameters and parameter passing, but that also is not 
> related to rtapi.
>
> Thank you Charles and Robert for your substantial help.
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Machinekit on the BeagleBone Green Wireless (BBGW) + CRAMPS

[Daren Schwenke]

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 with no issues.
I've only tested on the BBG thus far.  I don't forsee any issues with the 
BBGW other than configuring it headless is confusing me as it uses 
connmanctl.

Steps:
Download the image Robert has made for this: 
https://rcn-ee.net/rootfs/bb.org/testing/2017-07-28/machinekit/bone-debian-8.9-machinekit-armhf-2017-07-28-4gb.img.xz
Login as machinekit:machinekit.
sudo apt-get update
cd /usr/lib/linuxcnc/
# save some files we need from xenomai
sudo tar -cvpf xenomai.tar xenomai/pru*
# remove it.
sudo apt-get remove --purge machinekit-xenomai
# install rt-preempt
sudo apt-get install machinekit-rt-preempt
# put the saved files back
sudo tar -xvf xenomai.tar
# move a couple from preempt to xenomai
sudo cp -p rt-preempt/hal_pru* xenomai/

#now edit /usr/bin/hal_temp_bbb and on line 154 change it so it reads:
#syspath = '/sys/bus/iio/devices/iio:device0/'

That's it.  Load your config and give it a try.
I noted that the maximum command line length for loadrt has gone down and I 
needed to split some of my loadrt entries to make them work, but due to a 
recent patch, you can do that at least.
I also noted that many of the example configs are out dated and explode due 
to changes in parameters and parameter passing, but that also is not 
related to rtapi.

Thank you Charles and Robert for your substantial help.

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: Machinekit on the BeagleBone Green Wireless (BBGW) + CRAMPS

[Daren Schwenke]

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: 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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: Machinekit on the BeagleBone Green Wireless (BBGW) + CRAMPS

[Daren Schwenke]

I'm pretty sure rtapi is not performing as expected here given we have gone
up an order of magnitude in processor usage, but running is better than not
and these targets are headless anyway.
I should be able to print something in the morning.

On Jul 29, 2017 1:12 AM, "Robert Nelson"  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 the RIP build I have.
> >> So I'm going to take this and sort the last few thingies here (by
> removing
> >> them) and test it on a real machine.
> >> Then, if it works, I'll compile a list of what had to happen.  Short
> list:
> >>
> >> Robert, your image was missing the wireless firmware files and it
> doesn't
> >> look like it was rebuilt since then.  Could you kick that off?
> >> It also seems we'll need rt-preempt and xenomai at the same time (cause
> the
> >> pru_generic bin was compiled as part of xenomai).  Not sure if the
> packages
> >> currently allow that.
> >> It would be great if machinekoder could take a look at the velocity
> >> extrusion related errors, but I have a version where I stripped out
> reset I
> >> believe so I can move forward.
> >> https://github.com/machinekit/machinekit/blob/master/src/
> hal/user_comps/hal_temp_bbb.py#L154
> >> needs to point to '/sys/bus/iio/devices/iio:device0/', then it works
> on both
> >> 3.8.13 and 4.4
> >
> > here you go:
> >
> > https://rcn-ee.net/rootfs/bb.org/testing/2017-07-28/machinekit/
>
> btw, side note..
>
> With the cpu resource not really available, would you guys be more
> happy with a very basic openbox gui, instead of the big qt5/lxde/etc..
>
> Just enough to click a "machinekit" icon..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Machinekit on the BeagleBone Green Wireless (BBGW) + CRAMPS

[Daren Schwenke]

Something new... seems there is a line length limit I never hit before in 
effect now.
Arcus-3D-M2.hal:49: Unknown command 
'ew0,mult2.ew1,mult2.ew2,mult2.ew3,mult2.ew4,mult2.ew5,mult2.m0'
That's the remainder of a long loadrt mult2 line being chopped off.  I 
split it into actually being two loadrt mult2 lines and then... 

*It starts. *

machinekit@beaglebone:~/Arcus-3D-M2$ ./run.py
loading cramps_cape.bbio... done
starting configserver... done
starting linuxcnc... MACHINEKIT - 0.1
Machine configuration directory is '/home/machinekit/Arcus-3D-M2'
Machine configuration file is 'Arcus-3D-M2.ini'
Starting Machinekit...
done
io started
halcmd loadusr io started
task pid=4589
emcTaskInit: using builtin interpreter

*RTAPI is kind of a pig though*:

  PID USER  PR  NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 
 
 4559 root  20   0   63848  59668  11600 S *45.3* 12.0   3:24.15 
rtapi:0  
 4577 machine+  20   0   14932   9112   6488 S  4.2  1.8   0:18.59 
hal_temp_bbb 
 4589 machine+  20   0   22212  13992  11688 S  3.9  2.8   0:17.85 milltask 

 4616 machine+  20   04564   2132   1764 R  1.6  0.4   0:01.26 top 
 
4 root  -2   0   0  0  0 S  1.0  0.0   0:11.60 
ktimersoftd+ 
8 root  20   0   0  0  0 S  0.3  0.0   0:02.91 
rcu_preempt  
   10 root  20   0   0  0  0 S  0.3  0.0   0:03.29 rcuc/0   

 2589 www-data  20   0  228836   3300   1916 S  0.3  0.7   0:00.72 apache2 
 
 4554 machine+  20   0   25856   5116   4672 S  0.3  1.0   0:00.48 
rtapi_msgd   
 4590 machine+  20   0   81192  30236   8412 S  0.3  6.1   0:14.51 
mkwrapper
 4596 machine+  20   0   72240  30968   8872 S  0.3  6.2   0:01.54 
mkwrapper

Compared to the xenomai version of the same machine:
  PID USER  PR  NI  VIRT  RES  SHR S  %CPU %MEMTIME+  COMMAND   

 2514 machinek  20   0 13764  12m 9704 S   6.9  2.6   0:07.05 hal_temp_bbb 
 
 2526 machinek  20   0 21012  19m  14m S   3.0  3.9   0:03.20 milltask 
 
 2542 machinek  20   0  4208 1244  884 R   1.0  0.2   0:00.81 top   

3 root  20   0 000 S   0.7  0.0   0:01.19 ksoftirqd/0   

  775 root  20   0 28740 9112 3668 S   0.3  1.8   0:05.02 Xorg 
 
 1159 machinek  20   0  5556 2216 1820 S   0.3  0.4   0:00.57 menu-cached   

 1200 machinek  20   0  8912 1404  752 S   0.3  0.3   0:00.15 sshd 
 
 2016 root  20   0 000 S   0.3  0.0   0:01.99 kworker/0:0   

 2535 machinek  20   0 54452  14m 4368 S   0.3  2.9   0:00.50 mkwrapper 

1 root  20   0  4476 2652 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 getting really close now.  I'm compiling again so I can 
> remove the dependencies outside of the RIP build I have.
> So I'm going to take this and sort the last few thingies here (by removing 
> them) and test it on a real machine.
> Then, if it works, I'll compile a list of what had to happen.  Short list:
>
> Robert, your image was missing the wireless firmware files and it doesn't 
> look like it was rebuilt since then.  Could you kick that off?
> It also seems we'll need rt-preempt and xenomai at the same time (cause 
> the pru_generic bin was compiled as part of xenomai).  Not sure if the 
> packages currently allow that.
> It would be great if machinekoder could take a look at the velocity 
> extrusion related errors, but I have a version where I stripped out reset I 
> believe so I can move forward.
>
> https://github.com/machinekit/machinekit/blob/master/src/hal/user_comps/hal_temp_bbb.py#L154
>  
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmachinekit%2Fmachinekit%2Fblob%2Fmaster%2Fsrc%2Fhal%2Fuser_comps%2Fhal_temp_bbb.py%23L154&sa=D&sntz=1&usg=AFQjCNEyVmtb9Uoxe6fmFAaRpNFV2h7gpA>
>  needs 
> to point to '/sys/bus/iio/devices/iio:device0/', then it works on both 
> 3.8.13 and 4.4
>
> On Wednesday, September 28, 2016 at 6:10:09 AM UTC-4, Unai Antero wrote:
>>
>> Dear all,
>>
>> trying to use a SeeedStudio BeagleBone Green Wireless (+ the CRAMPS 
>> board) to run machinekit, but without much success...
>>
>> Tried using the SD image on 
>> https://rcn-ee.com/rootfs/bb.org/testing/2016-09-18/machinekit/bone-debian-8.6-machinekit-armhf-2016-09-18-4gb.img.xz
>>  
>> , but although it works fine on a Beagle Bone Black, the BB Green Wireless 
>> refuses to boot (seems it doesn't like the 3.8 kernel...).
>>
>> On a second attempt, was able to start