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  NI    VIRT    RES    SHR 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   0    4564   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 %MEM    TIME+  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     0    0    0 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     0    0    0 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     0    0    0 S   0.0  0.0   0:00.00 kthreadd     
     
    5 root       0 -20     0    0    0 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 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 [email protected].
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Reply via email to