Re: [Machinekit] RT demon is not running. rtapi_app_main(rtapi): -22 Invalid argument ???

[Magnus Wiberg]

Hi! I'm trying to make the py-uio work. I'm new to device tree and have 
trouble understanding where I should put the device tree fragment. I'm 
assuming it is in the am57xx-beagle-x15-revc.dts after #include 
"am57xx-beagle-x15-common.dtsi"? And then compile with dtc, but where to 
put the device tree blob .dtb so it gets loaded at boot?

On Thursday, September 13, 2018 at 7:23:58 PM UTC+2, Robert Nelson wrote:
>
> On Thu, Sep 13, 2018 at 12:18 PM Magnus Wiberg 
> > wrote: 
> > 
> > Is uio what is used in pru_generic.bin? 
> > Shouldnt this take care of that then? 
> https://groups.google.com/forum/#!topic/beagleboard-x15/MfB-GMl0UYA 
> > 
> > Any suggestions on what I can do to get machinekit working? Or should I 
> just wipe it and start from scratch? 
>
> Oh, i totally forgot about that.. 
>
> i don't know then. ;) 
>
> Just make sure you switch to the v4.14.x-rt kernel, the "non-rt" is 
> installed by default in the x15 image 
>
> 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.

Re: [Machinekit] using hal_spi module

[mngr]

I am really sorry Schooner, I was excited about the findings...
I actually don't know which args suits my setup, I looked in the source, 
but I don't know how to find where they are used,
I tried to scroll it all, but found no place that seems to use them.
My board is a Raspberry Pi 3 model B  V 1.2 and attached you can find the 
cpuinfo output
Spi is enabled from raspi-config, and in /dev there is spidev0.0 and 
spidev0.1

Il giorno domenica 23 settembre 2018 19:35:25 UTC+2, Schooner ha scritto:
>
> OK, good there is some progress.
>
> You will probably find that whilst loaded, it may not work.
>
> That while statement is actually 
> while(!( *(spi + 0) & 0x0001)
> which is extremely specific and if something has changed or if SPI is not 
> enabled, it will hang forever.
>
> (gripe here, I have asked you 3 specific questions and you have not 
> answered any of them)
>
>
> On 23/09/18 18:01, mngr wrote:
>
> Thanks for the explanation about machinkit workings,
>
> I played with the stamps and found that it was blocking on
> while (!(BCM2835_SPICS & SPI_CS_DONE)); (Line 438)
>
> removing it halrun loads, now I will see if and what it writes. maybe I 
> will have to control the low level implementation... but now I know more 
> things.
>
> One more question, how does a hal module read the args? 
>
>
> Il giorno domenica 23 settembre 2018 17:47:44 UTC+2, Schooner ha scritto: 
>>
>> Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user hal_spi.so 
>> default iparms: ''
>> Sep 23 15:03:17 realtimepi rtapi:0: 1:rtapi_app:701:user : hal_spi 
>> initerr
>> Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user : hal_spi 
>> initdbg
>> Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user halg_xinitfv:90 
>> HAL: initializing component 'hal_spi' type=1 arg1=0 arg2=0/0x0
>>
>> Since you haven't said where these extra prints are located, their 
>> presence means nothing to me
>>
> The module is obviously loading to a point but it does not look as though 
>> the driver is getting any further than hal_init, which calls halg_xinitfv()
>> then is failing catastrophically
>>
>> You are loading with no args, are the defaults suitable for your board / 
>> setup?
>> Not that it looks that it gets that far, due the complete absence of 
>> other error or info messages
>>
>> The insmod error is completely non specific, so doesn't help, may just be 
>> picking up the last return value.
>>
>> What is the output from /proc/cpuinfo and what version etc is your Pi?
>>
>>
>>
>> On 23/09/18 16:12, mngr wrote:
>>
>> Attached.
>>
>> In the log you can see the message I added in the hal_spi rtapi_app_main.
>>
>> pi@realtimepi:~ $ halcmd loadrt hal_spi
>> :0: insmod failed, returned -1:
>> rtapi_rpc(): reply timeout
>> See /var/log/linuxcnc.log for more information.
>> pi@realtimepi:~ $ halcmd show all
>> halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-
>> dad21114744a): rtapi_rpc(): reply timeout
>>
>> E: 18-09-23 15:04:20 dangling 'DEALER' socket created at hal/utils/
>> halcmd_rtapiapp.cc:281
>>
>>
>> Il giorno domenica 23 settembre 2018 16:43:25 UTC+2, Schooner ha scritto:
>>
>>>
>>> On 23/09/18 15:16, mngr wrote:
>>>
>>>
>>>
>>> Il giorno domenica 23 settembre 2018 15:34:58 UTC+2, Schooner ha 
>>> scritto: 

 It's not about doubt
 cat /proc/cpuinfo
 will tell you whether you have BCM2835

>>>  
>>> Thanks didn't know about that! on the rpi is written 2837, bit cpuinfo 
>>> says 2835!
>>> So at least the part that writes in the SPI registers should work.
>>>
>>> I tried to add some debug message in hal_spi rtapi_app_main function, 
>>> but I don't see them anywhere, I have exported DEBUG=5, and maximized the 
>>> DEBUG value in the ini file. I am looking in /var/log/linuxcnc.log and in 
>>> the terminal output.
>>> I have tried with different msg types 
>>>
>>> rtapi_print_msg(RTAPI_MSG_ERR, ": hal_spi initerr\n");
>>> rtapi_print_msg(RTAPI_MSG_DBG, ": hal_spi initdbg\n");
>>> rtapi_print_msg(RTAPI_MSG_ALL, ": hal_spi initall\n");
>>>
>>>
>>> There are plenty of error messages in the driver already.  I did not see 
>>> any in the log however which makes me
>>> suspect it was never loaded.
>>> If insmod errors it should say why however and that was not in there 
>>> either.
>>>
>>> Instead of complicating things with loading a non working config, just 
>>> to load the driver, try this in a terminal on your Pi
>>>
>>> sudo > /var/log/linuxcnc.log (you may have to run this a root, it should 
>>> zero the log)
>>> DEBUG=5 realtime restart
>>> halcmd loadrt hal_spi
>>> halcmd show all
>>> halrun -U
>>>
>>> That should give you a short log and if it errors loading hal_spi will 
>>> be easier to trace through
>>>
>>> In addition to the log do
>>>
>>> dmesg | tail > dmesg.log 
>>>
>>> and attach that log too
>>>
>>>
>>> If you do and the driver should work, we can try to find out why it 
 isn't.

 If you don't, what the differences are from the BCM2837 

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  
OK, good there is some progress.

You will probably find that whilst loaded, it may not work.

That while statement is actually 
while(!( *(spi + 0) & 0x0001)
which is extremely specific and if something has changed or if SPI
is not enabled, it will hang forever.

(gripe here, I have asked you 3 specific questions and you have not
answered any of them)


On 23/09/18 18:01, mngr wrote:


  
Thanks for the explanation about machinkit workings,


I played with the stamps and found that it was blocking on
while (!(BCM2835_SPICS &
  SPI_CS_DONE)); (Line 438)


removing it halrun loads, now I will see if and what it
  writes. maybe I will have to control the low level
  implementation... but now I know more things.


One more question, how does a hal module read the args? 




Il giorno domenica 23 settembre 2018 17:47:44 UTC+2, Schooner ha
scritto:

   Sep 23 15:03:17
realtimepi rtapi:0: 4:rtapi_app:701:user hal_spi.so default
iparms: ''
Sep 23 15:03:17 realtimepi rtapi:0: 1:rtapi_app:701:user :
hal_spi initerr
Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user :
hal_spi initdbg
Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user
halg_xinitfv:90 HAL: initializing component 'hal_spi' type=1
arg1=0 arg2=0/0x0

Since you haven't said where these extra prints are located,
their presence means nothing to me
  


   The module is obviously
loading to a point but it does not look as though the driver
is getting any further than hal_init, which calls
halg_xinitfv()
then is failing catastrophically

You are loading with no args, are the defaults suitable for
your board / setup?
Not that it looks that it gets that far, due the complete
absence of other error or info messages

The insmod error is completely non specific, so doesn't
help, may just be picking up the last return value.

What is the output from /proc/cpuinfo and what version etc
is your Pi?



On 23/09/18 16:12, mngr wrote:


  
Attached.


In the log you can see the message I added in the
  hal_spi rtapi_app_main.



  
  pi@realtimepi:~ $ halcmd loadrt hal_spi
:0: insmod failed, returned -1:
  rtapi_rpc(): reply timeout
See /var/log/linuxcnc.log for more information.
  pi@realtimepi:~ $ halcmd show all
  halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout
  
  E: 18-09-23 15:04:20 dangling 'DEALER' socket created at hal/utils/halcmd_rtapiapp.cc:281


  
  

Il giorno domenica 23 settembre 2018 16:43:25
  UTC+2, Schooner ha scritto:

   
On 23/09/18 15:16, mngr wrote:


  

Il giorno domenica 23 settembre 2018 15:34:58
UTC+2, Schooner ha scritto:

   It's
not about doubt
cat /proc/cpuinfo
will tell you whether you have BCM2835
  

 
Thanks didn't know about that! on the rpi
  is written 2837, bit cpuinfo says 2835!
So at least the part that writes in the SPI
  registers should work.


I tried to add some debug message in
  hal_spi rtapi_app_main function, but I
don't see them anywhere, I have exported
DEBUG=5, and maximized the DEBUG value in
the ini file. I am looking in
/var/log/linuxcnc.log and in the terminal
output.
  

Re: [Machinekit] using hal_spi module

[mngr]

Thanks for the explanation about machinkit workings,

I played with the stamps and found that it was blocking on
while (!(BCM2835_SPICS & SPI_CS_DONE)); (Line 438)

removing it halrun loads, now I will see if and what it writes. maybe I 
will have to control the low level implementation... but now I know more 
things.

One more question, how does a hal module read the args? 


Il giorno domenica 23 settembre 2018 17:47:44 UTC+2, Schooner ha scritto:
>
> Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user hal_spi.so 
> default iparms: ''
> Sep 23 15:03:17 realtimepi rtapi:0: 1:rtapi_app:701:user : hal_spi 
> initerr
> Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user : hal_spi 
> initdbg
> Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user halg_xinitfv:90 
> HAL: initializing component 'hal_spi' type=1 arg1=0 arg2=0/0x0
>
> Since you haven't said where these extra prints are located, their 
> presence means nothing to me
>
The module is obviously loading to a point but it does not look as though 
> the driver is getting any further than hal_init, which calls halg_xinitfv()
> then is failing catastrophically
>
> You are loading with no args, are the defaults suitable for your board / 
> setup?
> Not that it looks that it gets that far, due the complete absence of other 
> error or info messages
>
> The insmod error is completely non specific, so doesn't help, may just be 
> picking up the last return value.
>
> What is the output from /proc/cpuinfo and what version etc is your Pi?
>
>
>
> On 23/09/18 16:12, mngr wrote:
>
> Attached.
>
> In the log you can see the message I added in the hal_spi rtapi_app_main.
>
> pi@realtimepi:~ $ halcmd loadrt hal_spi
> :0: insmod failed, returned -1:
> rtapi_rpc(): reply timeout
> See /var/log/linuxcnc.log for more information.
> pi@realtimepi:~ $ halcmd show all
> halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-
> dad21114744a): rtapi_rpc(): reply timeout
>
> E: 18-09-23 15:04:20 dangling 'DEALER' socket created at hal/utils/
> halcmd_rtapiapp.cc:281
>
>
> Il giorno domenica 23 settembre 2018 16:43:25 UTC+2, Schooner ha scritto:
>
>>
>> On 23/09/18 15:16, mngr wrote:
>>
>>
>>
>> Il giorno domenica 23 settembre 2018 15:34:58 UTC+2, Schooner ha scritto: 
>>>
>>> It's not about doubt
>>> cat /proc/cpuinfo
>>> will tell you whether you have BCM2835
>>>
>>  
>> Thanks didn't know about that! on the rpi is written 2837, bit cpuinfo 
>> says 2835!
>> So at least the part that writes in the SPI registers should work.
>>
>> I tried to add some debug message in hal_spi rtapi_app_main function, 
>> but I don't see them anywhere, I have exported DEBUG=5, and maximized the 
>> DEBUG value in the ini file. I am looking in /var/log/linuxcnc.log and in 
>> the terminal output.
>> I have tried with different msg types 
>>
>> rtapi_print_msg(RTAPI_MSG_ERR, ": hal_spi initerr\n");
>> rtapi_print_msg(RTAPI_MSG_DBG, ": hal_spi initdbg\n");
>> rtapi_print_msg(RTAPI_MSG_ALL, ": hal_spi initall\n");
>>
>>
>> There are plenty of error messages in the driver already.  I did not see 
>> any in the log however which makes me
>> suspect it was never loaded.
>> If insmod errors it should say why however and that was not in there 
>> either.
>>
>> Instead of complicating things with loading a non working config, just to 
>> load the driver, try this in a terminal on your Pi
>>
>> sudo > /var/log/linuxcnc.log (you may have to run this a root, it should 
>> zero the log)
>> DEBUG=5 realtime restart
>> halcmd loadrt hal_spi
>> halcmd show all
>> halrun -U
>>
>> That should give you a short log and if it errors loading hal_spi will be 
>> easier to trace through
>>
>> In addition to the log do
>>
>> dmesg | tail > dmesg.log 
>>
>> and attach that log too
>>
>>
>> If you do and the driver should work, we can try to find out why it isn't.
>>>
>>> If you don't, what the differences are from the BCM2837 for example, I 
>>> have no idea
>>>
>>> I am guessing you are trying to generate steps using the SPI, that is an 
>>> area outside my experience
>>> but there seems to be quite a bit about it on the RPi forums
>>>
>>
>> Actually, I tought that hal_spi is used to write something to a MCU that 
>> will control the motor generating steps.
>> I think it sends the commanded velocity and the MCU updates the PWM.
>> I am not sure of those things, though
>>
>> On 23/09/18 13:50, mngr wrote:
>>
>>
>>
>> Il giorno domenica 23 settembre 2018 13:41:42 UTC+2, Schooner ha scritto: 
>>>
>>> The log does not show what your earlier email showed, there is not 
>>> mention of an error from insmod
>>>
>>> I think you need to get right back to basics.
>>>
>>> This driver was written 5 years ago and is specific to the BCM2835 chip
>>> It can only have been meant to support Pi v1 & v2 and maybe not all of 
>>> them, as they kept changing versions and hardware,
>>> because nothing of a higher version had been released then
>>>
>>> Does this driver support your Pi?
>>>
>>

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  
Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user hal_spi.so
default iparms: ''
Sep 23 15:03:17 realtimepi rtapi:0: 1:rtapi_app:701:user : hal_spi
initerr
Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user : hal_spi
initdbg
Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user
halg_xinitfv:90 HAL: initializing component 'hal_spi' type=1 arg1=0
arg2=0/0x0

Since you haven't said where these extra prints are located, their
presence means nothing to me

The module is obviously loading to a point but it does not look as
though the driver is getting any further than hal_init, which calls
halg_xinitfv()
then is failing catastrophically

You are loading with no args, are the defaults suitable for your
board / setup?
Not that it looks that it gets that far, due the complete absence of
other error or info messages

The insmod error is completely non specific, so doesn't help, may
just be picking up the last return value.

What is the output from /proc/cpuinfo and what version etc is your
Pi?



On 23/09/18 16:12, mngr wrote:


  
Attached.


In the log you can see the message I added in the hal_spi
  rtapi_app_main.



  
  pi@realtimepi:~ $
  halcmd loadrt hal_spi
:0:
  insmod failed, returned -1:
  rtapi_rpc(): reply
  timeout
See /var/log/linuxcnc.log for more
  information.
  pi@realtimepi:~ $
  halcmd show all
  halcmd: cant connect to
  rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a):
  rtapi_rpc(): reply
  timeout
  
  E: 18-09-23 15:04:20
  dangling 'DEALER'
  socket created at hal/utils/halcmd_rtapiapp.cc:281


  
  

Il giorno domenica 23 settembre 2018 16:43:25 UTC+2,
  Schooner ha scritto:

   
On 23/09/18 15:16, mngr wrote:


  

Il giorno domenica 23 settembre 2018 15:34:58 UTC+2,
Schooner ha scritto:

   It's not about
doubt
cat /proc/cpuinfo
will tell you whether you have BCM2835
  

 
Thanks didn't know about that! on the rpi is
  written 2837, bit cpuinfo says 2835!
So at least the part that writes in the SPI
  registers should work.


I tried to add some debug message in hal_spi rtapi_app_main
function, but I don't see them anywhere, I have
exported DEBUG=5, and maximized the DEBUG value in
the ini file. I am looking in /var/log/linuxcnc.log
and in the terminal output.
I have tried with different msg types 
  

  
rtapi_print_msg(RTAPI_MSG_ERR, ": hal_spi
initerr\n");
rtapi_print_msg(RTAPI_MSG_DBG, ": hal_spi
initdbg\n");
rtapi_print_msg(RTAPI_MSG_ALL, ": hal_spi
initall\n");
  
  


There are plenty of error messages in the driver already.  I
did not see any in the log however which makes me
suspect it was never loaded.
If insmod errors it should say why however and that was not
in there either.

Instead of complicating things with loading a non working
config, just to load the driver, try this in a terminal on
your Pi

sudo > /var/log/linuxcnc.log (you may have to run this a
root, it should zero the log)
DEBUG=5 realtime restart
halcmd loadrt hal_spi
halcmd show all
halrun -U

That should give you a short log and if it errors loading
hal_spi will be easier to trace through

In addition to the log do

dmesg | tail > dmesg.log 

and attach that log too


  



   If you do and
the driver should work, we can try to find out why
it isn't.

If you don't, 

Re: [Machinekit] using hal_spi module

[mngr]

Attached.

In the log you can see the message I added in the hal_spi rtapi_app_main.

pi@realtimepi:~ $ halcmd loadrt hal_spi
:0: insmod failed, returned -1:
rtapi_rpc(): reply timeout
See /var/log/linuxcnc.log for more information.
pi@realtimepi:~ $ halcmd show all
halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-
dad21114744a): rtapi_rpc(): reply timeout

E: 18-09-23 15:04:20 dangling 'DEALER' socket created at hal/utils/
halcmd_rtapiapp.cc:281


Il giorno domenica 23 settembre 2018 16:43:25 UTC+2, Schooner ha scritto:

>
> On 23/09/18 15:16, mngr wrote:
>
>
>
> Il giorno domenica 23 settembre 2018 15:34:58 UTC+2, Schooner ha scritto: 
>>
>> It's not about doubt
>> cat /proc/cpuinfo
>> will tell you whether you have BCM2835
>>
>  
> Thanks didn't know about that! on the rpi is written 2837, bit cpuinfo 
> says 2835!
> So at least the part that writes in the SPI registers should work.
>
> I tried to add some debug message in hal_spi rtapi_app_main function, but 
> I don't see them anywhere, I have exported DEBUG=5, and maximized the DEBUG 
> value in the ini file. I am looking in /var/log/linuxcnc.log and in the 
> terminal output.
> I have tried with different msg types 
>
> rtapi_print_msg(RTAPI_MSG_ERR, ": hal_spi initerr\n");
> rtapi_print_msg(RTAPI_MSG_DBG, ": hal_spi initdbg\n");
> rtapi_print_msg(RTAPI_MSG_ALL, ": hal_spi initall\n");
>
>
> There are plenty of error messages in the driver already.  I did not see 
> any in the log however which makes me
> suspect it was never loaded.
> If insmod errors it should say why however and that was not in there 
> either.
>
> Instead of complicating things with loading a non working config, just to 
> load the driver, try this in a terminal on your Pi
>
> sudo > /var/log/linuxcnc.log (you may have to run this a root, it should 
> zero the log)
> DEBUG=5 realtime restart
> halcmd loadrt hal_spi
> halcmd show all
> halrun -U
>
> That should give you a short log and if it errors loading hal_spi will be 
> easier to trace through
>
> In addition to the log do
>
> dmesg | tail > dmesg.log 
>
> and attach that log too
>
>
> If you do and the driver should work, we can try to find out why it isn't.
>>
>> If you don't, what the differences are from the BCM2837 for example, I 
>> have no idea
>>
>> I am guessing you are trying to generate steps using the SPI, that is an 
>> area outside my experience
>> but there seems to be quite a bit about it on the RPi forums
>>
>
> Actually, I tought that hal_spi is used to write something to a MCU that 
> will control the motor generating steps.
> I think it sends the commanded velocity and the MCU updates the PWM.
> I am not sure of those things, though
>
> On 23/09/18 13:50, mngr wrote:
>
>
>
> Il giorno domenica 23 settembre 2018 13:41:42 UTC+2, Schooner ha scritto: 
>>
>> The log does not show what your earlier email showed, there is not 
>> mention of an error from insmod
>>
>> I think you need to get right back to basics.
>>
>> This driver was written 5 years ago and is specific to the BCM2835 chip
>> It can only have been meant to support Pi v1 & v2 and maybe not all of 
>> them, as they kept changing versions and hardware,
>> because nothing of a higher version had been released then
>>
>> Does this driver support your Pi?
>>
>
> In case of doubt I gave a look to wiringPi, it calls ioctl and write/reads 
> from /dev/spidev.
> Is calling that syscall from a hal driver a sane thing to do? (It is for 
> example used here 
> 
> )
>
>  
>
>> Regards DEBUG, the ini file bit was explained by the text you deleted 
>> from yours.
>> It takes a hexidecimal number up to 0x7FFF, the output is to terminal 
>> and the output is from NML messaging
>>
>> The exported DEBUG=5 is the debug setting for logging and relates to the 
>> rtapi system, not NML
>>
>
> Thanks for the explanation, Schooner
>  
>
>> On 23/09/18 11:07, mngr wrote:
>>
>>
>>
>> Il giorno venerdì 21 settembre 2018 16:44:50 UTC+2, Schooner ha scritto: 
>>>
>>> You are not running with DEBUG=5
>>>
>>
>> I edited DEBUG = 5 in ini file(in EMC section), nothing changed, then I 
>> exported DEBUG=5 in bash. what is the difference? what is the deBUG setting 
>> in the ini file for?
>>
>> Attached you can find the ini and the hal file, I edited the CRAMPS 
>> configuration, basically removing everything relative to the PRU, and 
>> adding loadrt hal_spi in CRAMPS.hal (and leaving one only axis)
>> linuxcnc_old.log is everything before adding loadrt hal_spi. 
>> linuxcnc.log is the execution with loadrt hal_spi and termila_output 
>> shows what has been written, I attached it because it talks about 
>> rtapi_rpc(): reply timeout, that is not mentioned in the log
>>
>> pi@realtimepi:~ $ uname -a
>> Linux realtimepi 4.14.66-rt40-v7 #2 SMP PREEMPT RT Mon Sep 17 21:15:46 
>> UTC 2018 armv7l GNU/Linux
>>
>>
>>  
>>
>>> Do so and your linuxcnc.log will have info 

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  

On 23/09/18 15:16, mngr wrote:


  

Il giorno domenica 23 settembre 2018 15:34:58 UTC+2, Schooner ha
scritto:

   It's not about doubt
cat /proc/cpuinfo
will tell you whether you have BCM2835
  

 
Thanks didn't know about that! on the rpi is written 2837,
  bit cpuinfo says 2835!
So at least the part that writes in the SPI registers
  should work.


I tried to add some debug message in hal_spi rtapi_app_main function, but I don't see them
anywhere, I have exported DEBUG=5, and maximized the DEBUG
value in the ini file. I am looking in /var/log/linuxcnc.log
and in the terminal output.
I have tried with different msg types 
  

  
rtapi_print_msg(RTAPI_MSG_ERR, ":
hal_spi initerr\n");
rtapi_print_msg(RTAPI_MSG_DBG, ": hal_spi initdbg\n");
rtapi_print_msg(RTAPI_MSG_ALL, ": hal_spi initall\n");
  
  


There are plenty of error messages in the driver already.  I did not
see any in the log however which makes me
suspect it was never loaded.
If insmod errors it should say why however and that was not in there
either.

Instead of complicating things with loading a non working config,
just to load the driver, try this in a terminal on your Pi

sudo > /var/log/linuxcnc.log (you may have to run this a root, it
should zero the log)
DEBUG=5 realtime restart
halcmd loadrt hal_spi
halcmd show all
halrun -U

That should give you a short log and if it errors loading hal_spi
will be easier to trace through

In addition to the log do

dmesg | tail > dmesg.log 

and attach that log too


  



   If you do and the
driver should work, we can try to find out why it isn't.

If you don't, what the differences are from the BCM2837 for
example, I have no idea

I am guessing you are trying to generate steps using the
SPI, that is an area outside my experience
but there seems to be quite a bit about it on the RPi forums
  



Actually, I tought that hal_spi is used to write something
  to a MCU that will control the motor generating steps.
I think it sends the commanded velocity and the MCU updates
  the PWM.
I am not sure of those things, though


  On 23/09/18 13:50, mngr wrote:
  
  

  
  Il giorno domenica 23 settembre 2018 13:41:42 UTC+2,
  Schooner ha scritto:
  
 The log does not
  show what your earlier email showed, there is not
  mention of an error from insmod
  
  I think you need to get right back to basics.
  
  This driver was written 5 years ago and is specific to
  the BCM2835 chip
  It can only have been meant to support Pi v1 & v2
  and maybe not all of them, as they kept changing
  versions and hardware,
  because nothing of a higher version had been released
  then
  
  Does this driver support your Pi?

  
  
  
  In case of doubt I gave a look to wiringPi, it calls
ioctl and write/reads from /dev/spidev.
  Is calling that syscall from a hal driver a sane
thing to do? (It is for example used here)
  
  
  
   
  
 Regards DEBUG,
  the ini file bit was explained by the text you deleted
  from yours.
  It takes a hexidecimal number up to 0x7FFF, the
  output is to terminal and the output is from NML
  messaging
  
  The exported DEBUG=5 is the debug setting for logging
  and relates to the rtapi system, not NML

  
  
  
  Thanks for the explanation, Schooner
  
   
  

  On 23/09/18 11:07, mngr wrote:
  
  

  
  Il giorno venerdì 21 settembre 2018 16:44:50
  UTC+2, Schooner ha scritto:
  
 You are
  not running with DEBUG=5
   

Re: [Machinekit] using hal_spi module

[mngr]

Il giorno domenica 23 settembre 2018 15:34:58 UTC+2, Schooner ha scritto:
>
> It's not about doubt
> cat /proc/cpuinfo
> will tell you whether you have BCM2835
>
 
Thanks didn't know about that! on the rpi is written 2837, bit cpuinfo says 
2835!
So at least the part that writes in the SPI registers should work.

I tried to add some debug message in hal_spi rtapi_app_main function, but I 
don't see them anywhere, I have exported DEBUG=5, and maximized the DEBUG 
value in the ini file. I am looking in /var/log/linuxcnc.log and in the 
terminal output.
I have tried with different msg types 

rtapi_print_msg(RTAPI_MSG_ERR, ": hal_spi initerr\n");
rtapi_print_msg(RTAPI_MSG_DBG, ": hal_spi initdbg\n");
rtapi_print_msg(RTAPI_MSG_ALL, ": hal_spi initall\n");

If you do and the driver should work, we can try to find out why it isn't.
>
> If you don't, what the differences are from the BCM2837 for example, I 
> have no idea
>
> I am guessing you are trying to generate steps using the SPI, that is an 
> area outside my experience
> but there seems to be quite a bit about it on the RPi forums
>

Actually, I tought that hal_spi is used to write something to a MCU that 
will control the motor generating steps.
I think it sends the commanded velocity and the MCU updates the PWM.
I am not sure of those things, though

On 23/09/18 13:50, mngr wrote:



Il giorno domenica 23 settembre 2018 13:41:42 UTC+2, Schooner ha scritto: 
>
> The log does not show what your earlier email showed, there is not mention 
> of an error from insmod
>
> I think you need to get right back to basics.
>
> This driver was written 5 years ago and is specific to the BCM2835 chip
> It can only have been meant to support Pi v1 & v2 and maybe not all of 
> them, as they kept changing versions and hardware,
> because nothing of a higher version had been released then
>
> Does this driver support your Pi?
>

In case of doubt I gave a look to wiringPi, it calls ioctl and write/reads 
from /dev/spidev.
Is calling that syscall from a hal driver a sane thing to do? (It is for 
example used here 

)

 

> Regards DEBUG, the ini file bit was explained by the text you deleted from 
> yours.
> It takes a hexidecimal number up to 0x7FFF, the output is to terminal 
> and the output is from NML messaging
>
> The exported DEBUG=5 is the debug setting for logging and relates to the 
> rtapi system, not NML
>

Thanks for the explanation, Schooner
 

> On 23/09/18 11:07, mngr wrote:
>
>
>
> Il giorno venerdì 21 settembre 2018 16:44:50 UTC+2, Schooner ha scritto: 
>>
>> You are not running with DEBUG=5
>>
>
> I edited DEBUG = 5 in ini file(in EMC section), nothing changed, then I 
> exported DEBUG=5 in bash. what is the difference? what is the deBUG setting 
> in the ini file for?
>
> Attached you can find the ini and the hal file, I edited the CRAMPS 
> configuration, basically removing everything relative to the PRU, and 
> adding loadrt hal_spi in CRAMPS.hal (and leaving one only axis)
> linuxcnc_old.log is everything before adding loadrt hal_spi. 
> linuxcnc.log is the execution with loadrt hal_spi and termila_output shows 
> what has been written, I attached it because it talks about rtapi_rpc(): 
> reply timeout, that is not mentioned in the log
>
> pi@realtimepi:~ $ uname -a
> Linux realtimepi 4.14.66-rt40-v7 #2 SMP PREEMPT RT Mon Sep 17 21:15:46 
> UTC 2018 armv7l GNU/Linux
>
>
>  
>
>> Do so and your linuxcnc.log will have info as to what failed.
>>
>> Also as I said in my last reply, it does not look as though you have a 
>> realtime kernel, irrespective of what you have named your pi.
>>
>> On 21/09/18 15:31, mngr wrote:
>>
>> Hi everyone,
>>
>> I am sorry to post another noob question here, but,
>>
>> I am trying to use the hal module hal_spi, shortly I tried with 
>> loadrt hal_spi
>> in the hal file, but 
>> CRAMPS.hal:15: insmod failed, returned -1:
>> rtapi_rpc(): reply timeout
>> See /var/log/linuxcnc.log for more information.
>>
>> in the log
>> Sep 21 14:22:09 realtimepi msgd:0: startup pid=5979 flavor=posix rtlevel=
>> 1 usrlevel=1 halsize=524288 shm=Posix cc=gcc 6.3.0 20170516  version=
>> unknown
>> Sep 21 14:22:09 realtimepi msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0.0 
>> atomics=gcc intrinsicslibwebsockets=2.0.3
>> Sep 21 14:22:09 realtimepi msgd:0: configured: sha=b87920504
>> Sep 21 14:22:09 realtimepi msgd:0: built:  Sep 18 2018 16:43:17 sha=
>> b87920504
>> Sep 21 14:22:09 realtimepi msgd:0: register_stuff: actual hostname as 
>> announced by avahi='realtimepi.local'
>> Sep 21 14:22:09 realtimepi msgd:0: zeroconf: registering: 'Log service 
>> on realtimepi.local pid 5979'
>> Sep 21 14:22:10 realtimepi rtapi:0: rtapi_msgd went away, exiting
>> Sep 21 14:22:10 realtimepi msgd:0: zeroconf: registered 'Log service on 
>> realtimepi.local pid 5979' _machinekit._tcp 0 TXT 
>> "uuid=a42c8c6b-4025-4f83-ba28-dad21114744a" 
>> 

Re: [Machinekit] using hal_spi module

[mngr]

Il giorno domenica 23 settembre 2018 13:41:42 UTC+2, Schooner ha scritto:
>
> The log does not show what your earlier email showed, there is not mention 
> of an error from insmod
>
> I think you need to get right back to basics.
>
> This driver was written 5 years ago and is specific to the BCM2835 chip
> It can only have been meant to support Pi v1 & v2 and maybe not all of 
> them, as they kept changing versions and hardware,
> because nothing of a higher version had been released then
>
> Does this driver support your Pi?
>

In case of doubt I gave a look to wiringPi, it calls ioctl and write/reads 
from /dev/spidev.
Is calling that syscall from a hal driver a sane thing to do? (It is for 
example used here 

)

 

> Regards DEBUG, the ini file bit was explained by the text you deleted from 
> yours.
> It takes a hexidecimal number up to 0x7FFF, the output is to terminal 
> and the output is from NML messaging
>
> The exported DEBUG=5 is the debug setting for logging and relates to the 
> rtapi system, not NML
>

Thanks for the explanation, Schooner
 

> On 23/09/18 11:07, mngr wrote:
>
>
>
> Il giorno venerdì 21 settembre 2018 16:44:50 UTC+2, Schooner ha scritto: 
>>
>> You are not running with DEBUG=5
>>
>
> I edited DEBUG = 5 in ini file(in EMC section), nothing changed, then I 
> exported DEBUG=5 in bash. what is the difference? what is the deBUG setting 
> in the ini file for?
>
> Attached you can find the ini and the hal file, I edited the CRAMPS 
> configuration, basically removing everything relative to the PRU, and 
> adding loadrt hal_spi in CRAMPS.hal (and leaving one only axis)
> linuxcnc_old.log is everything before adding loadrt hal_spi. 
> linuxcnc.log is the execution with loadrt hal_spi and termila_output shows 
> what has been written, I attached it because it talks about rtapi_rpc(): 
> reply timeout, that is not mentioned in the log
>
> pi@realtimepi:~ $ uname -a
> Linux realtimepi 4.14.66-rt40-v7 #2 SMP PREEMPT RT Mon Sep 17 21:15:46 
> UTC 2018 armv7l GNU/Linux
>
>
>  
>
>> Do so and your linuxcnc.log will have info as to what failed.
>>
>> Also as I said in my last reply, it does not look as though you have a 
>> realtime kernel, irrespective of what you have named your pi.
>>
>> On 21/09/18 15:31, mngr wrote:
>>
>> Hi everyone,
>>
>> I am sorry to post another noob question here, but,
>>
>> I am trying to use the hal module hal_spi, shortly I tried with 
>> loadrt hal_spi
>> in the hal file, but 
>> CRAMPS.hal:15: insmod failed, returned -1:
>> rtapi_rpc(): reply timeout
>> See /var/log/linuxcnc.log for more information.
>>
>> in the log
>> Sep 21 14:22:09 realtimepi msgd:0: startup pid=5979 flavor=posix rtlevel=
>> 1 usrlevel=1 halsize=524288 shm=Posix cc=gcc 6.3.0 20170516  version=
>> unknown
>> Sep 21 14:22:09 realtimepi msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0.0 
>> atomics=gcc intrinsicslibwebsockets=2.0.3
>> Sep 21 14:22:09 realtimepi msgd:0: configured: sha=b87920504
>> Sep 21 14:22:09 realtimepi msgd:0: built:  Sep 18 2018 16:43:17 sha=
>> b87920504
>> Sep 21 14:22:09 realtimepi msgd:0: register_stuff: actual hostname as 
>> announced by avahi='realtimepi.local'
>> Sep 21 14:22:09 realtimepi msgd:0: zeroconf: registering: 'Log service 
>> on realtimepi.local pid 5979'
>> Sep 21 14:22:10 realtimepi rtapi:0: rtapi_msgd went away, exiting
>> Sep 21 14:22:10 realtimepi msgd:0: zeroconf: registered 'Log service on 
>> realtimepi.local pid 5979' _machinekit._tcp 0 TXT 
>> "uuid=a42c8c6b-4025-4f83-ba28-dad21114744a" 
>> "instance=b9c730a2-bda9-11e8-bcc3-b827eb4bcf42" "service=log" 
>> "dsn=ipc:///tmp/0.log.a42c8c6b-4025-4f83-ba28-dad21114744a"
>>
>> I tried launching machinekit without it and adding it later using halcmd 
>> loadrt hal_spi, but with similar results
>>
>>
>> should I give it some arguments? I don't know how to understand how to 
>> write them from the code...
>> Maybe the module is old and has lost some compatibility?
>>
>> right now i am executing from
>> Linux realtimepi 4.14.69-v7+ #1141 SMP Mon Sep 10 15:26:29 BST 2018 
>> armv7l GNU/Linux
>> Debian Stretch, Machinekit compiled from source
>> maybe should I explicit the path to hal_spi?
>>
>> mngr
>> -- 
>> 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 

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  
The log does not show what your earlier email showed, there is not
mention of an error from insmod

I think you need to get right back to basics.

This driver was written 5 years ago and is specific to the BCM2835
chip
It can only have been meant to support Pi v1 & v2 and maybe not
all of them, as they kept changing versions and hardware,
because nothing of a higher version had been released then

Does this driver support your Pi?

Regards DEBUG, the ini file bit was explained by the text you
deleted from yours.
It takes a hexidecimal number up to 0x7FFF, the output is to
terminal and the output is from NML messaging

The exported DEBUG=5 is the debug setting for logging and relates to
the rtapi system, not NML

On 23/09/18 11:07, mngr wrote:


  

Il giorno venerdì 21 settembre 2018 16:44:50 UTC+2, Schooner ha
scritto:

   You are not running
with DEBUG=5
  



I edited DEBUG = 5 in ini file(in EMC section), nothing
  changed, then I exported DEBUG=5 in bash. what is the
  difference? what is the deBUG setting in the ini file for?


Attached you can find the ini and the hal file, I edited
  the CRAMPS configuration, basically removing everything
  relative to the PRU, and adding loadrt hal_spi in CRAMPS.hal
  (and leaving one only axis)

linuxcnc_old.log is everything before adding loadrt
  hal_spi. 

linuxcnc.log is the execution with loadrt hal_spi and
  termila_output shows what has been written, I attached it
  because it talks about rtapi_rpc(): reply timeout, that is not
  mentioned in the log




  
  pi@realtimepi:~ $
  uname -a
Linux
  realtimepi 4.14.66-rt40-v7 #2 SMP
  PREEMPT RT Mon Sep 17 21:15:46 UTC 2018 armv7l
  GNU/Linux


  
  

 

   Do so and your
linuxcnc.log will have info as to what failed.

Also as I said in my last reply, it does not look as though
you have a realtime kernel, irrespective of what you have
named your pi.

On 21/09/18 15:31, mngr wrote:


  
Hi everyone,


I am sorry to post another noob question here, but,


I am trying to use the hal module hal_spi, shortly
  I tried with 


  
  loadrt hal_spi


  in the hal file, but 

  
  CRAMPS.hal:15: insmod failed, returned -1:
  rtapi_rpc(): reply timeout
See /var/log/linuxcnc.log for more information.


  
  in the log

  
  Sep 21 14:22:09 realtimepi msgd:0: startup pid=5979 flavor=posix rtlevel=1 usrlevel=1 halsize=524288 shm=Posix cc=gcc 6.3.0 20170516  version=unknown
Sep 21 14:22:09 realtimepi msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0.0 atomics=gcc intrinsics  
   libwebsockets=2.0.3
Sep 21 14:22:09 realtimepi msgd:0: configured: sha=b87920504
Sep 21 14:22:09 realtimepi msgd:0: built:      Sep 18 2018 16:43:17 sha=b87920504
Sep 21 14:22:09 realtimepi msgd:0: register_stuff: actual hostname as announced by avahi='realtimepi.local'
Sep 21 14:22:09 realtimepi msgd:0: zeroconf: registering: 'Log service on
  realtimepi.local pid 5979'
Sep 21 14:22:10 realtimepi rtapi:0: rtapi_msgd went away, exiting
Sep 21 14:22:10 realtimepi msgd:0: zeroconf: registered 'Log service on
  realtimepi.local pid 5979' _machinekit._tcp 0 TXT "uuid=a42c8c6b-4025-4f83-ba28-dad21114744a" "instance=b9c730a2-bda9-11e8-bcc3-b827eb4bcf42" "service=log" "dsn=ipc:///tmp/0.log.a42c8c6b-4025-4f83-ba28-dad21114744a"


  
  I tried launching machinekit without it and adding it
  later using halcmd loadrt hal_spi, but with similar
  results





should I give it some arguments? I don't know how

Re: [Machinekit] using hal_spi module

[mngr]

Il giorno venerdì 21 settembre 2018 16:44:50 UTC+2, Schooner ha scritto:
>
> You are not running with DEBUG=5
>

I edited DEBUG = 5 in ini file(in EMC section), nothing changed, then I 
exported DEBUG=5 in bash. what is the difference? what is the deBUG setting 
in the ini file for?

Attached you can find the ini and the hal file, I edited the CRAMPS 
configuration, basically removing everything relative to the PRU, and 
adding loadrt hal_spi in CRAMPS.hal (and leaving one only axis)
linuxcnc_old.log is everything before adding loadrt hal_spi. 
linuxcnc.log is the execution with loadrt hal_spi and termila_output shows 
what has been written, I attached it because it talks about rtapi_rpc(): 
reply timeout, that is not mentioned in the log

pi@realtimepi:~ $ uname -a
Linux realtimepi 4.14.66-rt40-v7 #2 SMP PREEMPT RT Mon Sep 17 21:15:46 UTC 
2018 armv7l GNU/Linux


 

> Do so and your linuxcnc.log will have info as to what failed.
>
> Also as I said in my last reply, it does not look as though you have a 
> realtime kernel, irrespective of what you have named your pi.
>
> On 21/09/18 15:31, mngr wrote:
>
> Hi everyone,
>
> I am sorry to post another noob question here, but,
>
> I am trying to use the hal module hal_spi, shortly I tried with 
> loadrt hal_spi
> in the hal file, but 
> CRAMPS.hal:15: insmod failed, returned -1:
> rtapi_rpc(): reply timeout
> See /var/log/linuxcnc.log for more information.
>
> in the log
> Sep 21 14:22:09 realtimepi msgd:0: startup pid=5979 flavor=posix rtlevel=1 
> usrlevel=1 halsize=524288 shm=Posix cc=gcc 6.3.0 20170516  version=unknown
> Sep 21 14:22:09 realtimepi msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0.0 
> atomics=gcc intrinsicslibwebsockets=2.0.3
> Sep 21 14:22:09 realtimepi msgd:0: configured: sha=b87920504
> Sep 21 14:22:09 realtimepi msgd:0: built:  Sep 18 2018 16:43:17 sha=
> b87920504
> Sep 21 14:22:09 realtimepi msgd:0: register_stuff: actual hostname as 
> announced by avahi='realtimepi.local'
> Sep 21 14:22:09 realtimepi msgd:0: zeroconf: registering: 'Log service on 
> realtimepi.local pid 5979'
> Sep 21 14:22:10 realtimepi rtapi:0: rtapi_msgd went away, exiting
> Sep 21 14:22:10 realtimepi msgd:0: zeroconf: registered 'Log service on 
> realtimepi.local pid 5979' _machinekit._tcp 0 TXT 
> "uuid=a42c8c6b-4025-4f83-ba28-dad21114744a" 
> "instance=b9c730a2-bda9-11e8-bcc3-b827eb4bcf42" "service=log" 
> "dsn=ipc:///tmp/0.log.a42c8c6b-4025-4f83-ba28-dad21114744a"
>
> I tried launching machinekit without it and adding it later using halcmd 
> loadrt hal_spi, but with similar results
>
>
> should I give it some arguments? I don't know how to understand how to 
> write them from the code...
> Maybe the module is old and has lost some compatibility?
>
> right now i am executing from
> Linux realtimepi 4.14.69-v7+ #1141 SMP Mon Sep 10 15:26:29 BST 2018 
> armv7l GNU/Linux
> Debian Stretch, Machinekit compiled from source
> maybe should I explicit the path to hal_spi?
>
> mngr
> -- 
> 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.


CRAMPS.ini
Description: Binary data


CRAMPS.hal
Description: Binary data
Sep 22 09:42:34 realtimepi pi: logtest:ac39f5cfe91390fa49d37c47c58f4784
Sep 22 09:42:44 realtimepi pi: logtest:45acd71bcc7d98aa8a2059b954a25bd7
Sep 22 09:43:11 realtimepi pi: logtest:baadee1b75f3acfa77e024757363affe
Sep 22 09:46:23 realtimepi msgd:0: startup pid=862 flavor=rt-preempt rtlevel=1 
usrlevel=1 halsize=524288 shm=Posix cc=gcc 6.3.0 20170516  version=unknown
Sep 22 09:46:23 realtimepi msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0.0 
atomics=gcc intrinsicslibwebsockets=2.0.3
Sep 22 09:46:23 realtimepi msgd:0: configured: sha=f63b8a215
Sep 22 09:46:23 realtimepi msgd:0: built:  Sep 22 2018 08:06:40 
sha=f63b8a215
Sep 22 09:46:23 realtimepi msgd:0: register_stuff: actual hostname as announced 
by avahi='realtimepi.local'
Sep 22 09:46:23 realtimepi msgd:0: zeroconf: registering: 'Log service on 
realtimepi.local pid 862'
Sep 22 09:46:24 realtimepi msgd:0: zeroconf: registered 'Log service on 
realtimepi.local pid 862' _machinekit._tcp 0 TXT 
"uuid=a42c8c6b-4025-4f83-ba28-dad21114744a" 

Re: [Machinekit] executing from source, pango problems

[mngr]

I messed with the RPi so I had to redo that part,
I run also the ./configure --with-platform-raspberry 
and it gave no error

Il giorno domenica 23 settembre 2018 10:29:58 UTC+2, mngr ha scritto:
>
> Now it works:
> The missing packages were those
>
> libpth-dev libpth20 tcl-dev tk-dev
> libusb-dev
> #here was still not working
> automake1.11 avahi-discover cmake cmake-data libarchive13 
> libavahi-compat-libdnssd-dev libavahi-compat-libdnssd1 libblas-common 
> libblas3 libdbus-glib-1-2 libgfortran3 libglade2-0 libjsoncpp1  liblapack3 
> libtool-bin python-avahi python-dbus python-gdbm python-glade2 
> python-gobject-2 python-gtk2 python-netifaces python-numpy
>
> before installing I re-run 
>
> debian/configure -prx
> sudo mk-build-deps -ir
>
> and no missing package was reported
> maybe I had to rerun ./configure too...
>
> Thank again Schooner
>
> Il giorno sabato 22 settembre 2018 21:20:14 UTC+2, mngr ha scritto:
>
>> Thanks for the answer, I will try to install those packages tomorrow.
>> Yes I am on stretch.
>>
>>
>> Il giorno sabato 22 settembre 2018 20:10:58 UTC+2, Schooner ha scritto:
>>>
>>> Copy this to a file, make executable and run it.  I am assuming you are 
>>> running Stretch from the kernel version? You haven't said.
>>>
>>> I have never seen this problem before and you are probably missing 
>>> something basic.
>>>
>>>
>>> ~~~
>>> #!/bin/bash
>>>
>>> apt-get install -y  build-essential debhelper libpth-dev libgtk2.0-dev 
>>> tcl-dev tk-dev bwidget python-tk python-dev libglu1-mesa-dev \
>>> libncurses5-dev libxaw7-dev gettext libmodbus-dev;
>>>
>>> apt-get install -y  libudev-dev git libmodbus-dev libboost-python-dev 
>>> libboost-serialization-dev libboost-thread-dev libtk-img automake autoconf 
>>> libtool libusb-dev;
>>>
>>> apt-get install -y  automake1.11 libtool libtool-bin liburiparser-dev 
>>> cmake libssl-dev  openssl python-setuptools  libusb-1.0-0-dev libudev-dev  
>>> uuid-dev libavahi-client-dev libavahi-compat-libdnssd-dev \
>>>  avahi-daemon libprotobuf-dev protobuf-compiler 
>>> python-protobuf libprotoc-dev uuid-runtime python-avahi python-netifaces 
>>> avahi-discover;
>>>
>>> apt-get install -y  libssl-dev uuid-dev libavahi-client-dev 
>>> libavahi-common-dev libdbus-1-dev python-pyftpdlib libmodbus-dev 
>>> libudev-dev libglib2.0-dev \
>>> libgl1-mesa-dev libxmu-dev python-netifaces liburiparser-dev 
>>> python-protobuf ;
>>> 
>>>
>>> apt-get install -y libjansson-dev pkg-config libwebsockets-dev 
>>> python-pyftpdlib cython bwidget lsb-release gtk+2.0-dev tk8.6-dev 
>>> tcl8.6-dev libreadline-dev python-tk libglu1-mesa-dev;
>>>
>>> apt-get install -y libczmq-dev  python-zmq ;
>>>
>>>
>>> 
>>>
>>> On 22/09/18 18:11, mngr wrote:
>>>
>>> Hi everybody,
>>> I have compiled from source, and now I am trying to execute, machinekit 
>>> stars, but axis does not:
>>>
>>>
>>> MACHINEKIT - 0.1
>>> Machine configuration directory is '/home/pi/machinekit/configs/CRAMPS'
>>> Machine configuration file is 'CRAMPS.ini'
>>> Starting Machinekit...
>>> rtapi_msgd command:  /home/pi/machinekit/libexec/rtapi_msgd --instance=0 
>>> --rtmsglevel=1 --usrmsglevel=1 --halsize=524288
>>> rtapi_app command:  /home/pi/machinekit/libexec/rtapi_app_rt-preempt --
>>> instance=0
>>> io started
>>> halcmd loadusr io started
>>> task pid=25915
>>> emcTaskInit: using builtin interpreter
>>> Traceback (most recent call last):
>>>   File "/home/pi/machinekit/bin/axis", line 3362, in 
>>> get_coordinate_font(vars.dro_large_font.get())
>>>   File "/home/pi/machinekit/bin/axis", line 3259, in get_coordinate_font
>>> glnav.use_pango_font(coordinate_font, 0, 128)
>>>   File "/home/pi/machinekit/lib/python/glnav.py", line 6, in 
>>> use_pango_font
>>> import cairo, pango, pangocairo
>>> ImportError: No module named pango
>>> 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
>>>
>>> there is some problem with pango... 
>>> I found this 
>>> https://github.com/251/shaape/commit/bc8e07fb4235a7cc6401ab4f8159466ec29cdf67
>>>
>>> but gi.repository PangoCairo has some function defined differently from 
>>> pangocairo
>>>
>>> pi@realtimepi:~/machinekit/configs/CRAMPS $ uname -a
>>> Linux realtimepi 4.14.66-rt40-v7 #2 SMP PREEMPT RT Mon Sep 17 21:15:46 
>>> UTC 2018 armv7l GNU/Linux
>>>
>>> I tryed installing pango, but I have found problem while compiling, and 
>>> the site is from 2012...
>>>
>>> any opinion about that?
>>>
>>>
>>> -- 
>>> website: http://www.machinekit.io blog: http://blog.machinekit.io 
>>> github: 

Re: [Machinekit] GUI Geared towards Embedded Platforms

[schoone...@gmail.com]

  
  
Had a look at the forum thread in linuxcnc, sounds interesting.

There is obviously a github repo somewhere you have shared with
Michel Wijnja

If you would like to do the same, I will be happy to test build.


On 23/09/18 07:11, schoone...@gmail.com
  wrote:


  
  HI Travis,
  I will be interested to have a look at this later.
  The includes you want should be in the flavor package
  https://github.com/machinekit/machinekit/blob/master/debian/machinekit-rt-preempt.install.in#L4
  We don't have a -dev package and each kernel has a specific sub
package which also contains the includes etc.
  I suspect you may have just installed machinekit, whereas you
need 'apt install machinekit machinekit rt-preempt' for
instance.
  I will check the package contents later, but see no reason why
those would be missing.
  regards
  
  
  On 9/22/2018 8:07 PM, Travis Gillin
wrote:
  
  

I'm working on a GUI that's meant for embedded
  applications with fairly low resources. It's C and C++ based
  and runs entirely without X, deals directly with the
  framebuffer and evdev for mouse & keyboard. (Touchscreen
  also supported)
  
  I have a post here about it https://forum.linuxcnc.org/41-guis/35225-new-gui-for-embedded-systems.
  I posted here to figure out how to talk to LinuxCNC via C
  (libNML) and this has all been figured out most part. My
  trouble now is when I try to build against machinekit, there
  is no /usr/include/linuxcnc. (or
  /usr/include/machinekit either) Specifically I need
  "" & ""
  equivalents for MachineKit. I know this project was forked a
  while ago but I believe the NML interface is the same.  Could
  someone here point me in the right direction?
  
  Right now the GUI runs on LinuxCNC on a regular Intel-based PC
  just fine and the only hang-up in migrating to our ARM
  platform is this little difference between LinuxCNC and
  Machinekit.
  
  
  I think this GUI will be a great addition to this project
because it will allow people to use HDMI or virtually any
type of display from Beagle Bone, Rasp Pi, or other
embedded devices that Machinekit has been ported too and not
have the "click and wait" lag.

Thanks,
Travis

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


  




-- 
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] executing from source, pango problems

[mngr]

Now it works:
The missing packages were those

libpth-dev libpth20 tcl-dev tk-dev
libusb-dev
#here was still not working
automake1.11 avahi-discover cmake cmake-data libarchive13 
libavahi-compat-libdnssd-dev libavahi-compat-libdnssd1 libblas-common 
libblas3 libdbus-glib-1-2 libgfortran3 libglade2-0 libjsoncpp1  liblapack3 
libtool-bin python-avahi python-dbus python-gdbm python-glade2 
python-gobject-2 python-gtk2 python-netifaces python-numpy

before installing I re-run 

debian/configure -prx
sudo mk-build-deps -ir

and no missing package was reported
maybe I had to rerun ./configure too...

Thank again Schooner

Il giorno sabato 22 settembre 2018 21:20:14 UTC+2, mngr ha scritto:

> Thanks for the answer, I will try to install those packages tomorrow.
> Yes I am on stretch.
>
>
> Il giorno sabato 22 settembre 2018 20:10:58 UTC+2, Schooner ha scritto:
>>
>> Copy this to a file, make executable and run it.  I am assuming you are 
>> running Stretch from the kernel version? You haven't said.
>>
>> I have never seen this problem before and you are probably missing 
>> something basic.
>>
>>
>> ~~~
>> #!/bin/bash
>>
>> apt-get install -y  build-essential debhelper libpth-dev libgtk2.0-dev 
>> tcl-dev tk-dev bwidget python-tk python-dev libglu1-mesa-dev \
>> libncurses5-dev libxaw7-dev gettext libmodbus-dev;
>>
>> apt-get install -y  libudev-dev git libmodbus-dev libboost-python-dev 
>> libboost-serialization-dev libboost-thread-dev libtk-img automake autoconf 
>> libtool libusb-dev;
>>
>> apt-get install -y  automake1.11 libtool libtool-bin liburiparser-dev 
>> cmake libssl-dev  openssl python-setuptools  libusb-1.0-0-dev libudev-dev  
>> uuid-dev libavahi-client-dev libavahi-compat-libdnssd-dev \
>>  avahi-daemon libprotobuf-dev protobuf-compiler 
>> python-protobuf libprotoc-dev uuid-runtime python-avahi python-netifaces 
>> avahi-discover;
>>
>> apt-get install -y  libssl-dev uuid-dev libavahi-client-dev 
>> libavahi-common-dev libdbus-1-dev python-pyftpdlib libmodbus-dev 
>> libudev-dev libglib2.0-dev \
>> libgl1-mesa-dev libxmu-dev python-netifaces liburiparser-dev 
>> python-protobuf ;
>> 
>>
>> apt-get install -y libjansson-dev pkg-config libwebsockets-dev 
>> python-pyftpdlib cython bwidget lsb-release gtk+2.0-dev tk8.6-dev 
>> tcl8.6-dev libreadline-dev python-tk libglu1-mesa-dev;
>>
>> apt-get install -y libczmq-dev  python-zmq ;
>>
>>
>> 
>>
>> On 22/09/18 18:11, mngr wrote:
>>
>> Hi everybody,
>> I have compiled from source, and now I am trying to execute, machinekit 
>> stars, but axis does not:
>>
>>
>> MACHINEKIT - 0.1
>> Machine configuration directory is '/home/pi/machinekit/configs/CRAMPS'
>> Machine configuration file is 'CRAMPS.ini'
>> Starting Machinekit...
>> rtapi_msgd command:  /home/pi/machinekit/libexec/rtapi_msgd --instance=0 
>> --rtmsglevel=1 --usrmsglevel=1 --halsize=524288
>> rtapi_app command:  /home/pi/machinekit/libexec/rtapi_app_rt-preempt --
>> instance=0
>> io started
>> halcmd loadusr io started
>> task pid=25915
>> emcTaskInit: using builtin interpreter
>> Traceback (most recent call last):
>>   File "/home/pi/machinekit/bin/axis", line 3362, in 
>> get_coordinate_font(vars.dro_large_font.get())
>>   File "/home/pi/machinekit/bin/axis", line 3259, in get_coordinate_font
>> glnav.use_pango_font(coordinate_font, 0, 128)
>>   File "/home/pi/machinekit/lib/python/glnav.py", line 6, in 
>> use_pango_font
>> import cairo, pango, pangocairo
>> ImportError: No module named pango
>> 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
>>
>> there is some problem with pango... 
>> I found this 
>> https://github.com/251/shaape/commit/bc8e07fb4235a7cc6401ab4f8159466ec29cdf67
>>
>> but gi.repository PangoCairo has some function defined differently from 
>> pangocairo
>>
>> pi@realtimepi:~/machinekit/configs/CRAMPS $ uname -a
>> Linux realtimepi 4.14.66-rt40-v7 #2 SMP PREEMPT RT Mon Sep 17 21:15:46 
>> UTC 2018 armv7l GNU/Linux
>>
>> I tryed installing pango, but I have found problem while compiling, and 
>> the site is from 2012...
>>
>> any opinion about 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+...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/machinekit.
>> For more options, visit 

Re: [Machinekit] GUI Geared towards Embedded Platforms

[schoone...@gmail.com]

HI Travis,

I will be interested to have a look at this later.

The includes you want should be in the flavor package

https://github.com/machinekit/machinekit/blob/master/debian/machinekit-rt-preempt.install.in#L4

We don't have a -dev package and each kernel has a specific sub package 
which also contains the includes etc.


I suspect you may have just installed machinekit, whereas you need 'apt 
install machinekit machinekit rt-preempt' for instance.


I will check the package contents later, but see no reason why those 
would be missing.


regards


On 9/22/2018 8:07 PM, Travis Gillin wrote:
I'm working on a GUI that's meant for embedded applications with 
fairly low resources. It's C and C++ based and runs 
entirely without X, deals directly with the framebuffer and evdev for 
mouse & keyboard. (Touchscreen also supported)


I have a post here about it 
https://forum.linuxcnc.org/41-guis/35225-new-gui-for-embedded-systems. 
I posted here to figure out how to talk to LinuxCNC via C (libNML) and 
this has all been figured out most part. My trouble now is when I try 
to build against machinekit, there is no /usr/include/linuxcnc. (or 
/usr/include/machinekit either) Specifically I need 
"" & "" equivalents for 
MachineKit. I know this project was forked a while ago but I believe 
the NML interface is the same.  Could someone here point me in the 
right direction?


Right now the GUI runs on LinuxCNC on a regular Intel-based PC just 
fine and the only hang-up in migrating to our ARM platform is this 
little difference between LinuxCNC and Machinekit.


I think this GUI will be a great addition to this project because it 
will allow people to use HDMI or virtually any type of display from 
Beagle Bone, Rasp Pi, or other embedded devices that Machinekit has 
been ported too and not have the "click and wait" lag.


Thanks,
Travis
--
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.


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