[Machinekit] Re: PICnc with Machine Kit.
Hi, In my humble opinion it should have both SPI and Ethernet connection. I do not see any difference in the real-time capabilities of these two protocols. cost would go up a bit, but this project could receive more attention form already existing communities. Maybe it could re-use the MESA protocol over ethernet, allowing for mutiple slaves to be connected, reusing work on the machinekit side, and attracting the attention of the LinuxCNC community. I am in europe, I cannot buy MESA because it came out way too expensive. There already are some open source motor driver, like Odrive or VESC. Maybe we could reuse something from here (BLDC are not stepper, i know, but hey, stepper are way easyer!) How hard do you think it is to move the MESA protocol from an FPGA, VHDL, to a microcontroller? I would use something like an ATSAME54, which is a cortex m4. I feel that atmel start libraries are well made, but I am not a seasoned developer. I can work on this, but I need the guide of a experienced one. Regards, mngr Il giorno venerdì 28 febbraio 2020 16:11:23 UTC+1, Mr Greg ha scritto: > > @ JohnD > > Re your OP > The answer is yes. > I have been using a Picnc + RPi2 -Jessy OS combo with machinekit for > several yrs. Looking to upgrade/resurect/or move on if necessary. > I'm personally not the chap to do the detail code, but am working with a > dev who has an interest and can contribute some limited time and effort. > > I am currently exploring Pi4 + Buster with a view to either Mesa or Picnc? > TBD > > @ Tomp > I understand you have had Picnc successfully running on a Pi3 ? > I can't seem to get it to behave on a Pi3. Not with Jessie + MK anyways. > All motors just spiral out of control soon as MK is started :( > All the SPI and dma addressing looks compatible They are both 2837 > Any ideas? > > @ All > By way of a little history. I did quite a bit of testing & verification > for Kinsa' on the original Picnc v1. ( circa 2012/13) This was on a Pic764 > which had potential to run faster with more IO > I'm not sure of how much info there is left for that version. I may have > some stuff archived? > > Cheers > MrGreg > > On Thursday, 27 February 2020 06:42:41 UTC, John Dammeyer wrote: >> >> This project seems to have lapsed 5 years ago. >> >> https://github.com/kinsamanka/PICnc-V2/wiki >> >> >> >> Any interest in resurrecting it? >> >> >> >> John Dammeyer >> >> >> >> "ELS! Nothing else works as well for your Lathe" >> >> Automation Artisans Inc. >> >> www dot autoartisans dot 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. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/228f471a-3292-4373-9fe8-08bf92f8fd3c%40googlegroups.com.
[Machinekit] screw extrusion
Hi, We are recently working on a 3d printer with a screw extruder. I will need to control the speed of a stepper moving the screw, and I think that the slicer will make the gcode thinking of a thread extruder. (am I wrong on this?) I have heard of some module in machinekit, that can do something like that, but I don't remember where to find them or how are they called... can anyone remind me? In the Arcus-3dM2 there is a screw extruder, is its configuration available? Regards 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/1741f9d6-046c-4471-8001-800d9f8a0f11%40googlegroups.com.
[Machinekit] python hal component userspace
Hi,
I am trying to build userspace hal components, and I am trying to build
them with python.
I can find a lot of examples in the repository calling
machinekit.rtapi.loadrt, but I have the vague idea of using
machinekit.hal.loadusr
Until now the only solution i have found is something structured like this
#comp file
from machinekit import hal
comp=hal.component("name")
comp.newpin("a", HAL.IN , HAL.BIT)
while 1:
comp["a"]=comp["b"]
time.sleep(1)
and loading
hal.loadusr("comp")
Is this the way it should be used?
I know the hal.addf function, I would like to use it to load function on
threads. Is it possible to export function from userspace components? I
haven't found any way of exporting functions from python
I would like to write something like that
#comp file
from machinekit import hal
comp=hal.component("name")
#comp.newpin...
def foo():
comp["a"]=comp["b"]
hal.export(foo)
hal.loadusr("comp")
hal.addf("foo","servo-thread")
Can you please give me some advice?
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+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/321cb3b5-7379-447e-8532-063f2e50e47c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Machinekit] scheduling policy
Hi, I am trying to improve the latency on my Machinekit installation. As hardware I have an ASRock 90-MXB870-A0UAYZ. I have chosen this because I read about it in the linuxcnc forum. I am using Debian 9.8, with kernel 4.9 rt machinekit@debian:~$ uname -a Linux debian 4.9.0-8-rt-amd64 #1 SMP PREEMPT RT Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux The latency I have is 50 microsecond, and from what I have read it is a bit too high (it should be between 10 and 30 microsecond) so I started studying about latency in the rt kernel. I have found that exists more scheduling policies and that every process declares its own. Indeed in rt-preempt.c I can see it uses SCHED_FIFO (at least, I think it should) I started latency test and checked, but it showed me it is SCHED_OTHER (TS), with proiority 19, the same of every other normal process. machinekit@debian:~$ ps -e -o pid,cls,pri,comm -H PID CLS PRI COMMAND ... 825 TS 19 sshd 831 TS 19 sshd 832 TS 19 bash 1327 TS 19 latency-test 1344 TS 19 halrun 1404 TS 19 halcmd 1408 TS 19 pyvcp ... 1089 TS 19 uuidd 1393 TS 19 rtapi_msgd 1398 TS 19 rtapi:0 Then I started Machinekit, and found out the same machinekit@debian:~$ ps -e -o pid,cls,pri,comm -H PID CLS PRI COMMAND ... 825 TS 19 sshd 831 TS 19 sshd 832 TS 19 bash 843 TS 19 bash 844 TS 19 linuxcnc 1066 TS 19 linuxcncsvr 1127 TS 19 milltask 1128 TS 19 axis ... 1088 TS 19 rtapi_msgd 1089 TS 19 uuidd 1094 TS 19 rtapi:0 1103 TS 19 io But I think it should be FF (SCHED_FIFO), may it be the cause of the high latency? 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+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: xenomai.x86-amd64 FATAL ERROR
Il giorno mercoledì 17 aprile 2019 00:12:12 UTC+2, ce...@tuta.io ha scritto: > > > > Dne úterý 16. dubna 2019 23:41:48 UTC+2 mngr napsal(a): >> >> >> >> Il giorno martedì 16 aprile 2019 23:19:52 UTC+2, ce...@tuta.io ha >> scritto: >>> >>> OK, >>> on freshly installed Debian Jessie from minimal netinst ISO with >>> Ciannmon and basic tools selected during installation (and one partition) >>> on P5K Deluxe, e7200 and 6GB RAM system. Added the Machinekit repository, >>> contrib and non-free, installed the Machinekit Xenomai Jessie kernel >>> package, upgraded system to latest. >>> >>> Then I did the RIP install of obsolete machinekit git repository and >>> everything works. (GUI and simple test of creating thread, adding function >>> and running it). >>> >>> Then I tried on the same system install packages machinekit and >>> machinekit-xenomai and the error occurred. So the problem is either in >>> packaging, installation or building. >>> >>> Questing is if it is worth to resolve as it's EOL for the machinekit >>> package. >>> >> >> If my issue is the only reason to do that I think that this bug can stay. >> I tried jessie-xenomai because with stretch-preempt I had bad latency. >> >> Is there any way to improve the latency for a specific installation? >> > > You can always try to play with kernel configuration parametres (based on > your system). > > Interesting thing is that you could not run RIP installation and I could. > Could you please confirm it? > Sorry for the delay, Yes, I can confirm that the Unfortunately I formatted the SSD with Machinekit on jessie, so I cannot give you any more details than what I have already sent. I agree with your question about the utility of focusing on a soon EOL package, so I am working on improving the configuration of the rt kernel. > Cern. > > >> >> >>> >>> BTW, I will try the machinekit-hal RIP build tomorrow. The package >>> machinekit-hal-xenomai is not installable as it has unresolvable dependency >>> issues. >>> >>> Dne úterý 16. dubna 2019 19:18:16 UTC+2 ce...@tuta.io napsal(a): >>>> >>>> That's not actually what I had on my mind. Looking at the Machinekit >>>> repository on http://deb.machinekit.io/debian/pool/main/m/machinekit/ >>>> there is machinekit-xenomai_0.1.1536596683.gitb879205-1~jessie_amd64.deb >>>> file from 2018-09-17 and what I meat is that if I can get the older >>>> prebuild packages? (I don't know how to get the number of package - for >>>> example 1536596683 - to try to download it.) >>>> >>>> However today I discovered something interesting. After multiple >>>> reinstalls and so on but the RIP build from master on Debian Jessie AMD64 >>>> with Xenomai kernel from Machinekit repository works. But installing it as >>>> package from Machinekit repository shows the aforementioned error. >>>> >>>> I will try it on clean Debian Jessie + MK Xenomai later. >>>> >>>> Cern. >>>> >>>> Dne úterý 16. dubna 2019 8:43:49 UTC+2 Schooner napsal(a): >>>>> >>>>> All packages in the repo can be downloaded over html or wget and >>>>> installed with 'dpkg -i' >>>>> On 4/15/2019 8:54 PM, ce...@tuta.io wrote: >>>>> >>>>> >>>>> Hi, >>>>> doing some testing I discovered that the problem is present on >>>>> http://deb.machinekit.io/debian/pool/main/m/machinekit/machinekit-xenomai_0.1.1536596683.gitb879205-1~jessie_amd64.deb >>>>> >>>>> package but RIP on randomly chosen build of >>>>> f59143cce34cdac3bd75aae4b95b8e43a6540a61 >>>>> works (I wanted to try something before warning silencing patch). >>>>> >>>>> However to find the exact border between working and nonworking will >>>>> be even with halving method tideous without prebuild packages, so is >>>>> there >>>>> a way how to get these older packages from repository or are they forever >>>>> deleted? >>>>> >>>>> Thanks >>>>> Cern. >>>>> >>>>> Dne čtvrtek 21. března 2019 10:47:44 UTC+1 mngr napsal(a): >>>>>> >>>>>> Hi, >>>>>> >>>>>> I am on >>>>>> Linux debian 3.8-1-xeno
[Machinekit] Re: xenomai.x86-amd64 FATAL ERROR
The same happens with RIP build If I try to load modules from halrun by hand it still throws some FATAL ERROR, but doesn't crash unloading modules Il giorno giovedì 21 marzo 2019 10:47:44 UTC+1, mngr ha scritto: > > Hi, > > I am on > Linux debian 3.8-1-xenomai.x86-amd64 #1 SMP Debian 3.8.13-12~1jessie~1da > x86_64 GNU/Linux > > with machinekit installed > marco@debian:~/log$ dpkg --list | grep machinekit > ii machinekit0.1.1552558261.git355496b-1~jessie > amd64PC based motion controller for real-time Linux > ii machinekit-xenomai0.1.1552558261.git355496b-1~jessie > amd64PC based motion controller for real-time Linux > > from (apt) > deb http://deb.machinekit.io/debian jessie main > > So, I think the installation is good, but whatever (I tried some) > configuration I try to run I get errors. > I have attached in print.txt the terminal output > > Looking in the log I see that at some point it decides to unload the > modules, but I can't understand the reason. > > Maybe it is the > FATAL ERROR: OUT OF MEMORY (epoll.cpp:55) > that it keeps throwing on the terminal. > > Is there anything I can do to better debug this? > -- 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] xenomai.x86-amd64 FATAL ERROR
Hi, I am on Linux debian 3.8-1-xenomai.x86-amd64 #1 SMP Debian 3.8.13-12~1jessie~1da x86_64 GNU/Linux with machinekit installed marco@debian:~/log$ dpkg --list | grep machinekit ii machinekit0.1.1552558261.git355496b-1~jessie amd64PC based motion controller for real-time Linux ii machinekit-xenomai0.1.1552558261.git355496b-1~jessie amd64PC based motion controller for real-time Linux from (apt) deb http://deb.machinekit.io/debian jessie main So, I think the installation is good, but whatever (I tried some) configuration I try to run I get errors. I have attached in print.txt the terminal output Looking in the log I see that at some point it decides to unload the modules, but I can't understand the reason. Maybe it is the FATAL ERROR: OUT OF MEMORY (epoll.cpp:55) that it keeps throwing on the terminal. Is there anything I can do to better debug this? -- 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. Mar 21 05:29:33 debian msgd:0: startup pid=1761 flavor=xenomai rtlevel=5 usrlevel=5 halsize=524288 shm=Posix cc=gcc 4.9.2 version=v0.1~-detached~355496b Mar 21 05:29:33 debian msgd:0: ØMQ=4.0.5 czmq=4.0.2 protobuf=2.6.1 atomics=gcc intrinsicslibwebsockets= Mar 21 05:29:33 debian msgd:0: configured: sha=355496b Mar 21 05:29:33 debian msgd:0: built: Mar 14 2019 10:36:54 sha=355496b Mar 21 05:29:33 debian msgd:0: register_stuff: actual hostname as announced by avahi='debian.local' Mar 21 05:29:33 debian msgd:0: zeroconf: registering: 'Log service on debian.local pid 1761' Mar 21 05:29:33 debian rtapi:0: 2:rtapi_app:1767:user rtapi:0: cannot create core dumps - /proc/sys/fs/suid_dumpable contains 0 Mar 21 05:29:33 debian rtapi:0: 2:rtapi_app:1767:user you might have to run 'echo 1 > /proc/sys/fs/suid_dumpable' as root to enable rtapi_app core dumps Mar 21 05:29:33 debian rtapi:0: 4:rtapi_app:1767:user rtapi.so default iparms: '' Mar 21 05:29:33 debian rtapi:0: 4:rtapi_app:1767:user rtapi: loaded from rtapi.so Mar 21 05:29:33 debian rtapi:0: 4:rtapi_app:1767:user hal_lib.so default iparms: '' Mar 21 05:29:33 debian rtapi:0: 4:rtapi_app:1767:user hal_lib: loaded from hal_lib.so Mar 21 05:29:33 debian rtapi:0: 4:rtapi_app:1767:user accepting commands at ipc:///tmp/0.rtapi.f69ba253-69d8-44dc-acda-3c5aa3cabf45 Mar 21 05:29:33 debian rtapi:0: 3:rtapi_app:1767:user rtapi_app:0 ready flavor=xenomai gcc=4.9.2 git=v0.1~-detached~355496b Mar 21 05:29:33 debian msgd:0: rtapi:1767:rt rtapi_app_main:195 HAL: initializing RT hal_lib support Mar 21 05:29:33 debian msgd:0: hal_lib:1767:rt halg_xinitfv:90 HAL: initializing component 'hal_lib' type=4 arg1=0 arg2=0/0x0 Mar 21 05:29:33 debian msgd:0: hal_lib:1767:rt hal_heap_addmem:58 HAL: extending arena by 262144 bytes Mar 21 05:29:33 debian msgd:0: hal_lib:1767:rt halg_export_xfunctfv:85 HAL: exporting function 'newinst' type 2 fp=0 owner=66 Mar 21 05:29:33 debian msgd:0: hal_lib:1767:rt halg_export_xfunctfv:85 HAL: exporting function 'delinst' type 2 fp=0 owner=66 Mar 21 05:29:33 debian msgd:0: hal_lib:1767:rt halg_xinitfv:271 HAL: singleton component 'hal_lib' id=66 initialized Mar 21 05:29:33 debian msgd:0: hal_lib:1767:rt rtapi_app_main:199 HAL: RT hal_lib support initialized rc=66 Mar 21 05:29:34 debian rtapi:0: 4:rtapi_app:1767:user pid=1767 flavor=xenomai gcc=4.9.2 git=v0.1~-detached~355496b Mar 21 05:29:34 debian rtapi:0: 4:rtapi_app:1767:user pid=1767 flavor=xenomai gcc=4.9.2 git=v0.1~-detached~355496b Mar 21 05:29:34 debian rtapi:0: 4:rtapi_app:1767:user pid=1767 flavor=xenomai gcc=4.9.2 git=v0.1~-detached~355496b Mar 21 05:29:34 debian msgd:0: ulapi:1778:user _ulapi_init(): ulapi xenomai v0.1~-detached~355496b loaded Mar 21 05:29:34 debian msgd:0: ulapi:1778:user halg_xinitfv:271 HAL: singleton component 'hal_lib1778' id=70 initialized Mar 21 05:29:34 debian msgd:0: hal_lib:1778:user --halcmd ping Mar 21 05:29:34 debian msgd:0: ulapi:1781:user _ulapi_init(): ulapi xenomai v0.1~-detached~355496b loaded Mar 21 05:29:34 debian msgd:0: ulapi:1781:user halg_xinitfv:271 HAL: singleton component 'hal_lib1781' id=74 initialized Mar 21 05:29:34 debian msgd:0: hal_lib:1781:user --halcmd loadusr -Wn iocontrol io -ini /home/marco/machinekit/configs/by_interface.parport.stepper/stepper_mm.ini Mar 21 05:29:34 debian msgd:0: hal_lib:1781:user io Mar 21 05:29:34 debian msgd:0: hal_lib:1781:user -ini Mar 21 05:29:34 debian msgd:0: hal_lib:1781:user /home/marco/machinekit/configs/by_interface.parport.stepper/stepper_mm.ini Mar 21 05:29:34 debian msgd:0:
Re: [Machinekit] configure for delta printer
Il giorno mercoledì 27 febbraio 2019 18:50:06 UTC+1, Bas de Bruijn ha scritto: > > > > On 27 Feb 2019, at 18:30, mngr > wrote: > > I had a ini and hal file working for this machine. Now I have copied every > configuration parameter to the new one, but the machine is behaving > differently. > In particular delta_r and cf_rod, the values that were working in the old > configuration doesn't work in the new one. > Maybe they are interpreted as inches instead of millimiters? > > > Why would that be? > It was just an hipotesys > You should tell what’s happening, describe what’s going on cause we can’t > see or guess what your situation is. > Try to narrow down first. > Check HAL to see the pins (your offsets rod length and delta radius) and > make sure they are what you expect. > Thanks, I hadn't thought about this check, will try tomorrow. > > > > Il giorno mercoledì 27 febbraio 2019 15:02:28 UTC+1, mngr ha scritto: >> >> Thank you Bas! >> >> Il giorno mercoledì 27 febbraio 2019 11:30:13 UTC+1, Bas de Bruijn ha >> scritto: >>> >>> >>> >>> On 27 Feb 2019, at 11:02, mngr wrote: >>> >>> Hi, >>> >>> I want to tweak this configuration ( >>> https://github.com/machinekit/machinekit/tree/master/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS >>> >>> ) to work for my 3d-printer, which is a delta. >>> In normal hal configuration there is >>> >>> #loadrt trivkins >>> loadrt lineardeltakins >>> >>> But I cannot find its equivalent in python hal, can you please help me? >>> >>> >>> from machinekit import rtapi as rt >>> rt.loadrt(‘lineardeltakins’) >>> >>> You can also have a look at github.com/machinekoder/rostock-cramps to >>> see some more examples >>> >>> 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.
Re: [Machinekit] configure for delta printer
I had a ini and hal file working for this machine. Now I have copied every configuration parameter to the new one, but the machine is behaving differently. In particular delta_r and cf_rod, the values that were working in the old configuration doesn't work in the new one. Maybe they are interpreted as inches instead of millimiters? Il giorno mercoledì 27 febbraio 2019 15:02:28 UTC+1, mngr ha scritto: > > Thank you Bas! > > Il giorno mercoledì 27 febbraio 2019 11:30:13 UTC+1, Bas de Bruijn ha > scritto: >> >> >> >> On 27 Feb 2019, at 11:02, mngr wrote: >> >> Hi, >> >> I want to tweak this configuration ( >> https://github.com/machinekit/machinekit/tree/master/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS >> >> ) to work for my 3d-printer, which is a delta. >> In normal hal configuration there is >> >> #loadrt trivkins >> loadrt lineardeltakins >> >> But I cannot find its equivalent in python hal, can you please help me? >> >> >> from machinekit import rtapi as rt >> rt.loadrt(‘lineardeltakins’) >> >> You can also have a look at github.com/machinekoder/rostock-cramps to >> see some more examples >> >> 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+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] configure for delta printer
Thank you Bas! Il giorno mercoledì 27 febbraio 2019 11:30:13 UTC+1, Bas de Bruijn ha scritto: > > > > On 27 Feb 2019, at 11:02, mngr > wrote: > > Hi, > > I want to tweak this configuration ( > https://github.com/machinekit/machinekit/tree/master/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS > > ) to work for my 3d-printer, which is a delta. > In normal hal configuration there is > > #loadrt trivkins > loadrt lineardeltakins > > But I cannot find its equivalent in python hal, can you please help me? > > > from machinekit import rtapi as rt > rt.loadrt(‘lineardeltakins’) > > You can also have a look at github.com/machinekoder/rostock-cramps to see > some more examples > > 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+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
[Machinekit] configure for delta printer
Hi, I want to tweak this configuration ( https://github.com/machinekit/machinekit/tree/master/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS ) to work for my 3d-printer, which is a delta. In normal hal configuration there is #loadrt trivkins loadrt lineardeltakins But I cannot find its equivalent in python hal, can you please help me? 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+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] Machinekit with openpnp
I have given a look at OpenPnP, it has the option to connect to a driver over TCP, and send gcodes one by one. This driver is now supposed to be a smoothieboard. How much work would be implementing a machinekit interface that shows on a TCP port and reply? In this way OpenPnP will stay untouched, but some gcode will have to be modified on machinekit side. Machinekit and OpenPnP might either stay on the same or different machines (I don't think the BBB is suited to run a program of computer vision) Il giorno domenica 2 dicembre 2018 11:18:00 UTC+1, alaa momen ha scritto: > > thank you in advance for you suggestion > you are good !✌ -- 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] documentation
Thanks Schooner, thanks Bas I took my time to study, the videos have been very useful, I still have a couple of questions: What does milltask do? how does it influence the movement? I have read somewhere in this group that it is made for milling and does not fit 3d printing at 100%, why? Il giorno venerdì 26 ottobre 2018 18:06:06 UTC+2, Schooner ha scritto: > > > On 25/10/18 09:48, schoo...@gmail.com wrote: > > > > Unfortunately the piece of s**t, google customised search engine for the > actual docs, has ceased working again. > They have undoubtedly changed something in the api again. > > I have now replaced the google custom search engine, which has been > nothing but trouble, with a javascript function > which does a site search. > > Enter a search phrase in the single Search input box and it will produce 2 > hits windows. > > One window is hits within the website documentation itself, the other is > hits within the Forum threads. > > Hopefully this will improve matters and assist your research. > > 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] documentation
Hi, I have made a little project developed around Machinekit and now I have to do a report on the project, I think I will do an introduction to explain what does Machinekit do, and how it works. That kind of documentation is currently lacking, that can be a good occasion to write some of it. In this period I learned something about machinekit and the HAL, but more on the "how to use" rather than "how it works". I heard often talking about ring-buffer and NML, and it is not really clear to me what they are and what they are used for. I have seen machinetalk with ZMQ and protobuf, and the structure seems clear. I tried to look search in the group, or looking in the code, but it is hard... I am not expert enough to write that documentation by myself, can you help me in writing it? First question would be: how do you think it should be structured? 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+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: Issue when add A axis to BBB
Hi, I think that is because you said it has 3 axis, so there is axis.0 axis.1 axis.2, stop. I actually don't know if you can call them X Y A. Instead I am curious if you can name them X Y E. Il giorno lunedì 15 ottobre 2018 21:04:33 UTC+2, guozir...@gmail.com ha scritto: > > Hi Guys, > > I got issue when add A axis, this machine works fine with two Axis X Y and > rotation ( use same same pin as A Axis P9 21 Gpio 0-3, P9 22 gpio 0-2), > since we have the pins in .dts, so I just modify .hal and .ini. first Im > not sure in .ini what I should do, so I change as below: > > [TRAJ] > > AXES = 3 > COORDINATES = X Y A > > *Can use 3 AXES like this way or I need to add also axis Z? but we don't > need Z* > > *and I add ：* > > [AXIS_3] > > # Axis 2 is used for the head Z motor. > > TYPE = LINEAR > MAX_VELOCITY = 200.0 > MAX_ACCELERATION = 200.0 > # Set Stepgen max 20% higher than the axis > STEPGEN_MAX_VEL =250.0 > STEPGEN_MAX_ACC =250.0 > > > > BACKLASH = 0.000 > > WRAPPED_ROTARY = 1 > > MAX_LIMIT = 1.0 > > FERROR = 10.0 > MIN_FERROR = 1.0 > > HOME = 0.0 > HOME_OFFSET = 1.0 > HOME_SEARCH_VEL = 30.0 > HOME_LATCH_VEL =7 > > #HOME_USE_INDEX =YES > #HOME_IGNORE_LIMITS =YES > > ## BYPASS HOMING # > ##HOME = 0.0 > #HOME_OFFSET = 0.0 > #HOME_SEARCH_VEL = 0.0 > #HOME_LATCH_VEL =0.0 > #HOME_SEQUENCE = 0 > ## END OF BYPASS HOMING # > > > # nanoseconds units > DIRSETUP = 200 > DIRHOLD= 200 > STEPLEN= 1000 > STEPSPACE = 1000 > > > *in the .hal, before we use rotation this way:* > > # > #A [3] Axis (Extruder) > # > # axis enable chain > #newsig emcmot.03.enable bit > #sets emcmot.03.enable FALSE > # > #net emcmot.03.enable <= axis.3.amp-enable-out > #net emcmot.03.enable => [PRUCONF](DRIVER).stepgen.03.enable > # > # > ## position command and feedback > #net emcmot.03.pos-cmd <= axis.3.motor-pos-cmd > #net emcmot.03.pos-cmd => [PRUCONF](DRIVER).stepgen.03.position-cmd > # > #net motor.03.pos-fb <= [PRUCONF](DRIVER).stepgen.03.position-fb > #net motor.03.pos-fb => axis.3.motor-pos-fb > > > > setp [PRUCONF](DRIVER).stepgen.03.control-type1 > > setp [PRUCONF](DRIVER).stepgen.03.dirsetup[RSPIN]DIRSETUP > setp [PRUCONF](DRIVER).stepgen.03.dirhold [RSPIN]DIRHOLD > > setp [PRUCONF](DRIVER).stepgen.03.steplen [RSPIN]STEPLEN > setp [PRUCONF](DRIVER).stepgen.03.stepspace [RSPIN]STEPSPACE > > setp [PRUCONF](DRIVER).stepgen.03.position-scale [RSPIN]SCALE > > setp [PRUCONF](DRIVER).stepgen.03.maxvel [RSPIN]STEPGEN_MAX_VEL > setp [PRUCONF](DRIVER).stepgen.03.maxaccel[RSPIN]STEPGEN_MAX_ACC > > #setp [PRUCONF](DRIVER).stepgen.03.step_type 0 > # P9.22 gpio0_2 > setp [PRUCONF](DRIVER).stepgen.03.steppin 0x22 > # P9.21 gpio0_3 > setp [PRUCONF](DRIVER).stepgen.03.dirpin 0x23 > > > *Now :* > > # > #A [3] Axis (Extruder) > # > # axis enable chain > newsig emcmot.03.enable bit > sets emcmot.03.enable FALSE > # > net emcmot.03.enable <= axis.3.amp-enable-out > net emcmot.03.enable => [PRUCONF](DRIVER).stepgen.03.enable > # > # > ## position command and feedback > net emcmot.03.pos-cmd <= axis.3.motor-pos-cmd > net emcmot.03.pos-cmd => [PRUCONF](DRIVER).stepgen.03.position-cmd > # > net motor.03.pos-fb <= [PRUCONF](DRIVER).stepgen.03.position-fb > net motor.03.pos-fb => axis.3.motor-pos-fb > > > > setp [PRUCONF](DRIVER).stepgen.03.control-type1 > > setp [PRUCONF](DRIVER).stepgen.03.dirsetup[RSPIN]DIRSETUP > setp [PRUCONF](DRIVER).stepgen.03.dirhold [RSPIN]DIRHOLD > > setp [PRUCONF](DRIVER).stepgen.03.steplen [RSPIN]STEPLEN > setp [PRUCONF](DRIVER).stepgen.03.stepspace [RSPIN]STEPSPACE > > setp [PRUCONF](DRIVER).stepgen.03.position-scale [RSPIN]SCALE > > setp [PRUCONF](DRIVER).stepgen.03.maxvel [RSPIN]STEPGEN_MAX_VEL > setp [PRUCONF](DRIVER).stepgen.03.maxaccel[RSPIN]STEPGEN_MAX_ACC > > #setp [PRUCONF](DRIVER).stepgen.03.step_type 0 > # P9.22 gpio0_2 > setp [PRUCONF](DRIVER).stepgen.03.steppin 0x22 > # P9.21 gpio0_3 > setp [PRUCONF](DRIVER).stepgen.03.dirpin 0x23 > > *then I always have error: PIN "axis.3.amp-enable-out" does not exist.* > > I'm new for the machinekit, thanks a lot if some one can help me. > > regards, > > XIN > -- 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: NGCWriter is now in Cura Plugin Repository
I don't get it, what is the difference between .ngc and .gcode files? I am currently just changing the extension Il giorno domenica 14 ottobre 2018 20:25:18 UTC+2, Michael Brown ha scritto: > > I have first gotton around to testing this today and I find that NGCWritet > plugin seema to be missing in the latest Cura v. 3.5 Toolboxmenu --> Browse > packages. > Also Installing an older version 3.4.1 or 3.4.0 gices an: > Could not connect to the Cura Package Database. > ... > Whats going on ? > > On Monday, 19 March 2018 20:02:36 UTC+1, 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.
Re: [Machinekit] using hal_spi module
Sure, push the updates. Il giorno martedì 2 ottobre 2018 15:18:53 UTC+2, Schooner ha scritto: > > Good to hear. > > It just makes the minimal changes, as it appeared the only thing that had > changed was the base address. > Agree, I was going to a lot more of non-necessary code > If you are happy with that, I can push a PR, so it is in the packages. > > > On 02/10/18 13:39, mngr wrote: > > I tested your branch, everything is working fine, it loads and the spi > writes. > > Il giorno domenica 30 settembre 2018 22:55:45 UTC+2, mngr ha scritto: >> >> It will probably take me more of a evening because the next couple of >> days is already full. Maybe I will test your version and then make another >> pr to unify hal_spi.h and bcm2835.h > > -- > 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] using hal_spi module
I tested your branch, everything is working fine, it loads and the spi writes. Il giorno domenica 30 settembre 2018 22:55:45 UTC+2, mngr ha scritto: > > It will probably take me more of a evening because the next couple of days > is already full. Maybe I will test your version and then make another pr to > unify hal_spi.h and bcm2835.h -- 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
It will probably take me more of a evening because the next couple of days is already full. Maybe I will test your version and then make another pr to unify hal_spi.h and bcm2835.h -- 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
I lacked attention, I thought you imported cpuinfo.h rebuilded and now it runs, but I still need to edit something more to make it work nm shows that both get_cpuinfo_revision() and get_rpi_revision() are defined anyway, it reads correctly giving number cores as 4 and revision as 4. I will give some time trying to patch my version, if it is too hard I will clone and test yours Il giorno domenica 30 settembre 2018 18:23:39 UTC+2, Schooner ha scritto: > > > On 30/09/18 16:59, mngr wrote: > > A young guy just learned how beautiful commit diffs are > > here is a link to the diffs! > https://github.com/machinekit/machinekit/compare/master...mngr0:master > > I have been very sticky to the workings in hal_gpio.c, > and the changes in hal_spi.h are not really necessary, but I think it > should be removed, to be more consistent with hal_gpio, and to use > bcm2835.h more (this requires work on hal_spi.c) > > it compiles, but while executing it has some problem in finding > get_rpi_revision, > > > That should not be so > > You got that error because you only included cpu_info.h but nothing else. > I included the actual code by using > #include "cpu_info.c" > > When I do a check on the module my code produced and the functions defined > I get > > root@INTEL-i7:/usr/src/machinekit/rtlib/rt-preempt# nm -C hal_spi.so > 5370 b accum > 5358 b accum_diff > 53a0 b BCM2835_PERI_BASE > U cl...@@GLIBC_2.2.5 > 52d8 b comp_id > 52c0 b completed.7389 > w __cxa_finalize@@GLIBC_2.2.5 > 11a0 t deregister_tm_clones > 1210 t __do_global_dtors_aux > 4e08 t __do_global_dtors_aux_fini_array_entry > 50d0 d __dso_handle > 52e0 b dt > 4e10 d _DYNAMIC > U fcl...@@GLIBC_2.2.5 > U fe...@@GLIBC_2.2.5 > U fg...@@GLIBC_2.2.5 > 2fdc t _fini > U fo...@@GLIBC_2.2.5 > 1250 t frame_dummy > 4e00 t __frame_dummy_init_array_entry > 3760 r __FRAME_END__ > 12e0 t get_cpuinfo_revision > 1422 t get_rpi_revision > > > So *get_cpuinfo_revision(*) and *get_rpi_revision()* are both in the text > section of the module and are local to it. > > If they were undefined they would have a U in front of them > > Are you somehow trying to run your old module again? > > Run the nm command above on your module. > > any suggestion to help hal_spi dinamically link this? > > maybe a issue or pull request on github may be a more relevant place for > this discussion? > > > Il giorno domenica 30 settembre 2018 16:22:51 UTC+2, Schooner ha scritto: >> >> See https://github.com/ArcEye/machinekit/tree/hal_spi_base >> >> I have used the simplest strategy. >> As only the _PERI_BASE seems to be different, I have changed the #define >> to an unsigned int variable. >> >> This is then set to either 0x2000 or 0x3F00 depending upon >> version detected. >> >> Just added code for number_of_cores() and included cpu_info.c to get the >> others. >> >> It builds but needs testing >> >> If you get problems, add some DBG prints to see what revision and number >> of cores is being returned >> >> regards >> >> On 29/09/18 17:56, mngr wrote: >> >> https://github.com/mngr0/machinekit >> >> >> Il giorno sabato 29 settembre 2018 18:50:47 UTC+2, Schooner ha scritto: >>> >>> Can you link to a github repo with this in? I will look tomorrow. >>> >>> You have probably declared something as extern or otherwise done enough >>> to satisfy the compiler, but not actually linked it or similar. >>> >>> Each driver probably needs to have all the routines and info within it. >>> >>> On 29/09/18 17:41, mngr wrote: >>> >>> i have copied all the function and recompiled, >>> now when i run realtime start; halcmd loadrt hal_spi an error says >>> do_load_cmd: dlopen: /home/pi/machinekit/rtlib/rt-preempt/hal_spi.so: >>> undefined symbol: get_rpi_revision >>> rpath=/home/pi/machinekit/rtlib/rt-preempt:/home/pi/machinekit/lib >>> >>> it does not happen if I run halcmd loadrt hal_gpio >>> >>> >>> then I have seen that there is bcm26835.h that unify all the useful >>> definitions, it would be nice if hal_spi.h was removed since it duplicates >>> definitions. >>> the only problem is that hal_spi.h defines the regis
Re: [Machinekit] using hal_spi module
A young guy just learned how beautiful commit diffs are here is a link to the diffs! https://github.com/machinekit/machinekit/compare/master...mngr0:master I have been very sticky to the workings in hal_gpio.c, and the changes in hal_spi.h are not really necessary, but I think it should be removed, to be more consistent with hal_gpio, and to use bcm2835.h more (this requires work on hal_spi.c) it compiles, but while executing it has some problem in finding get_rpi_revision, any suggestion to help hal_spi dinamically link this? maybe a issue or pull request on github may be a more relevant place for this discussion? Il giorno domenica 30 settembre 2018 16:22:51 UTC+2, Schooner ha scritto: > > See https://github.com/ArcEye/machinekit/tree/hal_spi_base > > I have used the simplest strategy. > As only the _PERI_BASE seems to be different, I have changed the #define > to an unsigned int variable. > > This is then set to either 0x2000 or 0x3F00 depending upon version > detected. > > Just added code for number_of_cores() and included cpu_info.c to get the > others. > > It builds but needs testing > > If you get problems, add some DBG prints to see what revision and number > of cores is being returned > > regards > > On 29/09/18 17:56, mngr wrote: > > https://github.com/mngr0/machinekit > > > Il giorno sabato 29 settembre 2018 18:50:47 UTC+2, Schooner ha scritto: >> >> Can you link to a github repo with this in? I will look tomorrow. >> >> You have probably declared something as extern or otherwise done enough >> to satisfy the compiler, but not actually linked it or similar. >> >> Each driver probably needs to have all the routines and info within it. >> >> On 29/09/18 17:41, mngr wrote: >> >> i have copied all the function and recompiled, >> now when i run realtime start; halcmd loadrt hal_spi an error says >> do_load_cmd: dlopen: /home/pi/machinekit/rtlib/rt-preempt/hal_spi.so: >> undefined symbol: get_rpi_revision >> rpath=/home/pi/machinekit/rtlib/rt-preempt:/home/pi/machinekit/lib >> >> it does not happen if I run halcmd loadrt hal_gpio >> >> >> then I have seen that there is bcm26835.h that unify all the useful >> definitions, it would be nice if hal_spi.h was removed since it duplicates >> definitions. >> the only problem is that hal_spi.h defines the register addresses, while >> bcm2835.h defines offsets, so a lot of hal_spi.c would have to be modified. >> >> >> >> Il giorno venerdì 28 settembre 2018 19:45:13 UTC+2, XL600R ha scritto: >>> >>> On 28.09.18 17:16, schoo...@gmail.com wrote: >>> > It can only have been written for v1 or v2, probably not v2B given its >>> date of writing. >>> > I have not heard anything of the guy who wrote it for some years >>> either. >>> >>> Hi, >>> >>> Gemi has wrote this driver for a particular board >>> https://github.com/kinsamanka/PICnc-V2/wiki . >>> I can't believe that it is very useful for someone else. >>> IMHO the nomenclature isn't overly happy. >>> A little bit to general. ;) >>> >>> BR >>> >> >> I need a way to write commanded velocity on the spi, my bigger problem >> wiill be on the spi-slave, and this seems to me a pretty easy protocol to >> implement >> >> -- >> 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+...@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] using hal_spi module
https://github.com/mngr0/machinekit Il giorno sabato 29 settembre 2018 18:50:47 UTC+2, Schooner ha scritto: > > Can you link to a github repo with this in? I will look tomorrow. > > You have probably declared something as extern or otherwise done enough to > satisfy the compiler, but not actually linked it or similar. > > Each driver probably needs to have all the routines and info within it. > > On 29/09/18 17:41, mngr wrote: > > i have copied all the function and recompiled, > now when i run realtime start; halcmd loadrt hal_spi an error says > do_load_cmd: dlopen: /home/pi/machinekit/rtlib/rt-preempt/hal_spi.so: > undefined symbol: get_rpi_revision > rpath=/home/pi/machinekit/rtlib/rt-preempt:/home/pi/machinekit/lib > > it does not happen if I run halcmd loadrt hal_gpio > > > then I have seen that there is bcm26835.h that unify all the useful > definitions, it would be nice if hal_spi.h was removed since it duplicates > definitions. > the only problem is that hal_spi.h defines the register addresses, while > bcm2835.h defines offsets, so a lot of hal_spi.c would have to be modified. > > > > Il giorno venerdì 28 settembre 2018 19:45:13 UTC+2, XL600R ha scritto: >> >> On 28.09.18 17:16, schoo...@gmail.com wrote: >> > It can only have been written for v1 or v2, probably not v2B given its >> date of writing. >> > I have not heard anything of the guy who wrote it for some years >> either. >> >> Hi, >> >> Gemi has wrote this driver for a particular board >> https://github.com/kinsamanka/PICnc-V2/wiki . >> I can't believe that it is very useful for someone else. >> IMHO the nomenclature isn't overly happy. >> A little bit to general. ;) >> >> BR >> > > I need a way to write commanded velocity on the spi, my bigger problem > wiill be on the spi-slave, and this seems to me a pretty easy protocol to > implement > > -- > 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] using hal_spi module
i have copied all the function and recompiled, now when i run realtime start; halcmd loadrt hal_spi an error says do_load_cmd: dlopen: /home/pi/machinekit/rtlib/rt-preempt/hal_spi.so: undefined symbol: get_rpi_revision rpath=/home/pi/machinekit/rtlib/rt-preempt:/home/pi/machinekit/lib it does not happen if I run halcmd loadrt hal_gpio then I have seen that there is bcm26835.h that unify all the useful definitions, it would be nice if hal_spi.h was removed since it duplicates definitions. the only problem is that hal_spi.h defines the register addresses, while bcm2835.h defines offsets, so a lot of hal_spi.c would have to be modified. Il giorno venerdì 28 settembre 2018 19:45:13 UTC+2, XL600R ha scritto: > > On 28.09.18 17:16, schoo...@gmail.com wrote: > > It can only have been written for v1 or v2, probably not v2B given its > date of writing. > > I have not heard anything of the guy who wrote it for some years either. > > Hi, > > Gemi has wrote this driver for a particular board > https://github.com/kinsamanka/PICnc-V2/wiki . > I can't believe that it is very useful for someone else. > IMHO the nomenclature isn't overly happy. > A little bit to general. ;) > > BR > I need a way to write commanded velocity on the spi, my bigger problem wiill be on the spi-slave, and this seems to me a pretty easy protocol to implement -- 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
Il giorno venerdì 28 settembre 2018 15:10:04 UTC+2, Schooner ha scritto: > > > On 28/09/18 13:21, mngr wrote: > > edited from 0x2000 to 0x3F00 and now the raspberry loads the > hal_spi module. hal_spi.c should check the Pi version in a similar way to > hal_gpio.c . > > > Well done. > > There were no other Pi versions when it was written. > > Would you like to submit a PR? > sure thing! I have just seen that after modifying naively BCM2835_PERI_BASE the chip select stops working. there is some part of hal_spi that I don't understand: a very lot of costants in hal_spi.h are not used; and https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_spi.c#L401 it does something on GPIO23 and 24. for which raspberry version was it written? I see it is related to pin_out hal pin, but... how was it designed? Cut and paste the hal_gpio.c code that version checks into hal-spi.c and > test that. > I only have rasppberry 3B on my desk, so I only can test on it. > > > Il giorno mercoledì 26 settembre 2018 12:33:31 UTC+2, mngr ha scritto: >> >> The cpuinfo information says BCM2835 for any raspberry version you can >> have, this helps with something in the kernel, the revision is the filed >> actually accurate. >> The first version of RPi have the base address at 0x2000 from RPi 2 >> on it is at 0x3F00 >> >> hal gpio recognize this difference, hal_spi does not, I still have to run >> hal gpio, though, will do it in next days >> >> https://web.stanford.edu/class/cs140e/docs/BCM2837-ARM-Peripherals.pdf >> here is a BCM 2837 datasheet that shows all the addresses, I will try to >> correct them in next days >> >> Other <https://ultibo.org/wiki/Unit_BCM2710> says to have a SPI driver >> for the 2710 (aka 2837) but it is hard to find the code, in case I will try >> to ask directly to them >> >> >> Il giorno lunedì 24 settembre 2018 11:41:53 UTC+2, Schooner ha scritto: >>> >>> Well, despite what /proc/cpuinfo says, I don't see how it can be a >>> BCM2835 Soc. >>> >>> The elinux hardware history (https://elinux.org/RPi_HardwareHistory) >>> clearly shows the v3 B has a BCM2037 and even if you >>> were sold an almost identical v2 B purporting to be a v3 B, it would >>> have a BCM2036. >>> >>> Looks like it is testing CS (chip select) to see if it is in an active >>> state and waiting until it is? >>> Hence my question about whether SPI was activated. >>> The most likely sources of the problem are either that SPI is inactive >>> or >>> that whatever address *spi points to it does not contain what is >>> expected so the & test will never result as expected. >>> >>> This in turn makes one suspicious about what will happen when the driver >>> is attached to a thread and started. >>> Will it work? >>> >>> It might be useful to try to get the hal_gpio demo running on the board >>> with DEBUG set and look at the output. >>> >>> Regards the args, that is peculiar. Just ignore the print out. >>> Look at hal_gpio.c for an example of how RTAPI_MP_STRING should appear, >>> and then you can see them being used in the later code. >>> If there is any initialisation to be done it would normally be in >>> rtapi_app_main() >>> >>> You need to find someone who is up on bit twiddling on the v3 B and >>> check all the addresses and offsets with them. >>> (Particularly the SPI_BASE offset, which may or may not vary between >>> models of Soc) >>> >>> >>> On 23/09/18 20:35, mngr wrote: >>> >>> 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 someth
Re: [Machinekit] using hal_spi module
edited from 0x2000 to 0x3F00 and now the raspberry loads the hal_spi module. hal_spi.c should check the Pi version in a similar way to hal_gpio.c . Il giorno mercoledì 26 settembre 2018 12:33:31 UTC+2, mngr ha scritto: > > The cpuinfo information says BCM2835 for any raspberry version you can > have, this helps with something in the kernel, the revision is the filed > actually accurate. > The first version of RPi have the base address at 0x2000 from RPi 2 > on it is at 0x3F00 > > hal gpio recognize this difference, hal_spi does not, I still have to run > hal gpio, though, will do it in next days > > https://web.stanford.edu/class/cs140e/docs/BCM2837-ARM-Peripherals.pdf > here is a BCM 2837 datasheet that shows all the addresses, I will try to > correct them in next days > > Other <https://ultibo.org/wiki/Unit_BCM2710> says to have a SPI driver > for the 2710 (aka 2837) but it is hard to find the code, in case I will try > to ask directly to them > > > Il giorno lunedì 24 settembre 2018 11:41:53 UTC+2, Schooner ha scritto: >> >> Well, despite what /proc/cpuinfo says, I don't see how it can be a >> BCM2835 Soc. >> >> The elinux hardware history (https://elinux.org/RPi_HardwareHistory) >> clearly shows the v3 B has a BCM2037 and even if you >> were sold an almost identical v2 B purporting to be a v3 B, it would have >> a BCM2036. >> >> Looks like it is testing CS (chip select) to see if it is in an active >> state and waiting until it is? >> Hence my question about whether SPI was activated. >> The most likely sources of the problem are either that SPI is inactive or >> that whatever address *spi points to it does not contain what is expected >> so the & test will never result as expected. >> >> This in turn makes one suspicious about what will happen when the driver >> is attached to a thread and started. >> Will it work? >> >> It might be useful to try to get the hal_gpio demo running on the board >> with DEBUG set and look at the output. >> >> Regards the args, that is peculiar. Just ignore the print out. >> Look at hal_gpio.c for an example of how RTAPI_MP_STRING should appear, >> and then you can see them being used in the later code. >> If there is any initialisation to be done it would normally be in >> rtapi_app_main() >> >> You need to find someone who is up on bit twiddling on the v3 B and check >> all the addresses and offsets with them. >> (Particularly the SPI_BASE offset, which may or may not vary between >> models of Soc) >> >> >> On 23/09/18 20:35, mngr wrote: >> >> 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_
Re: [Machinekit] using hal_spi module
The cpuinfo information says BCM2835 for any raspberry version you can have, this helps with something in the kernel, the revision is the filed actually accurate. The first version of RPi have the base address at 0x2000 from RPi 2 on it is at 0x3F00 hal gpio recognize this difference, hal_spi does not, I still have to run hal gpio, though, will do it in next days https://web.stanford.edu/class/cs140e/docs/BCM2837-ARM-Peripherals.pdf here is a BCM 2837 datasheet that shows all the addresses, I will try to correct them in next days Other <https://ultibo.org/wiki/Unit_BCM2710> says to have a SPI driver for the 2710 (aka 2837) but it is hard to find the code, in case I will try to ask directly to them Il giorno lunedì 24 settembre 2018 11:41:53 UTC+2, Schooner ha scritto: > > Well, despite what /proc/cpuinfo says, I don't see how it can be a BCM2835 > Soc. > > The elinux hardware history (https://elinux.org/RPi_HardwareHistory) > clearly shows the v3 B has a BCM2037 and even if you > were sold an almost identical v2 B purporting to be a v3 B, it would have > a BCM2036. > > Looks like it is testing CS (chip select) to see if it is in an active > state and waiting until it is? > Hence my question about whether SPI was activated. > The most likely sources of the problem are either that SPI is inactive or > that whatever address *spi points to it does not contain what is expected > so the & test will never result as expected. > > This in turn makes one suspicious about what will happen when the driver > is attached to a thread and started. > Will it work? > > It might be useful to try to get the hal_gpio demo running on the board > with DEBUG set and look at the output. > > Regards the args, that is peculiar. Just ignore the print out. > Look at hal_gpio.c for an example of how RTAPI_MP_STRING should appear, > and then you can see them being used in the later code. > If there is any initialisation to be done it would normally be in > rtapi_app_main() > > You need to find someone who is up on bit twiddling on the v3 B and check > all the addresses and offsets with them. > (Particularly the SPI_BASE offset, which may or may not vary between > models of Soc) > > > On 23/09/18 20:35, mngr wrote: > > 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 f
Re: [Machinekit] using hal_spi module
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
Re: [Machinekit] using hal_spi module
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
Re: [Machinekit] using hal_spi module
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 > <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_p260c.c> > ) > > > >> 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 ev
Re: [Machinekit] using hal_spi module
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 <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_p260c.c> ) > 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 >&
Re: [Machinekit] using hal_spi module
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 <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_p260c.c> ) > 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
Re: [Machinekit] using hal_spi module
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' Se
Re: [Machinekit] executing from source, pango problems
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: >>>
Re: [Machinekit] executing from source, pango problems
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 >> >
Re: [Machinekit] executing from source, pango problems
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 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] executing from source, pango problems
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+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
[Machinekit] using hal_spi module
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+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: Error when install Machinekit on Raspberry Pi 3, Raspian Stretch
I compiled from source, using ./ configure --with-platform-raspberry and machinekit works. I randomly gave a look in the /var/log/linuxcnc.log file and I found that Sep 21 13:24:10 realtimepi msgd:0: startup pid=4467 *flavor=posix* rtlevel=1 usrlevel=1 halsize=524288 shm=Posix cc=gcc 6.3.0 20170516 version=unknown even if pi@realtimepi:~ $ uname -a Linux realtimepi 4.14.69-v7+ #1141 SMP Mon Sep 10 15:26:29 BST 2018 armv7l GNU/Linux should'nt flavor be preempt-rt? did I missed something while compiling? Il giorno martedì 18 settembre 2018 14:40:20 UTC+2, mngr ha scritto: > > Thanks Tac!! > i was just about to ask how did you make a debian stretch real-time image > for the Pi, thank you very much! > > Il giorno lunedì 17 settembre 2018 19:54:18 UTC+2, Tac Huynh ha scritto: >> >> Thanks Schooner. >> Latest update worked. >> >> For other people using the raspberry pi. I used the ready made image from >> RealtimePi. >> >> https://github.com/guysoft/RealtimePi >> >> saving a lot of time for patching the preEmpt realtime kernel >> Tac. >> >> On Friday, September 14, 2018 at 7:41:29 AM UTC-7, Tac Huynh wrote: >>> >>> Please help: >>> How do I fix this installation error? >>> Thanks, >>> Tac. >>> >>> I tried to install Machinekit on Raspberry Pi 3, Raspian Stretch, got >>> following errors: >>> >>> sudo apt-get install machinekit-rt-preempt >>> >>> >>> Setting up xdot (0.7-2) ... >>> Setting up machinekit-rt-preempt (0.1.1536747208.git041712d-1~stretch) ... >>> ln: failed to create symbolic link >>> '/usr/lib/linuxcnc/rt-preempt/pru_generic.bin': No such file or directory >>> ln: failed to create symbolic link >>> '/usr/lib/linuxcnc/rt-preempt/pru_generic.dbg': No such file or directory >>> ln: failed to create symbolic link >>> '/usr/lib/linuxcnc/rt-preempt/pru_decamux.bin': No such file or directory >>> ln: failed to create symbolic link >>> '/usr/lib/linuxcnc/rt-preempt/pru_decamux.dbg': No such file or directory >>> dpkg: error processing package machinekit-rt-preempt (--configure): >>> subprocess installed post-installation script returned error exit status 1 >>> dpkg: dependency problems prevent configuration of machinekit: >>> machinekit depends on machinekit-rt-threads; however: >>> Package machinekit-rt-threads is not installed. >>> Package machinekit-rt-preempt which provides machinekit-rt-threads is not >>> configured yet. >>> >>> dpkg: error processing package machinekit (--configure): >>> dependency problems - leaving unconfigured >>> Processing triggers for libc-bin (2.24-11+deb9u3) ... >>> Processing triggers for systemd (232-25+deb9u2) ... >>> Errors were encountered while processing: >>> machinekit-rt-preempt >>> machinekit >>> E: Sub-process /usr/bin/dpkg returned an error code (1) >>> >>> -- 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: Connecting HAL components across multiple CPUs
I am not that expert on machinekit, but I will try to give my opinion, maybe someone will support or correct it The problem is communicating with lots of machine pieces, in Machinekit exists Machinetalk but it makes more Machinekit instances talking to each other (and Machinekit runs on Linux). It is based on ZMQ, that requires some Unix system calls, so moving to MCU world may be quite hard, always if it is possible to port ZMQ to firmware. Talking about low level communication protocol CAN may be a good option, since it is already used in automotive and supports multiple endpoints talking (one at time) with a master. Or even multi master if needed. But this would require some work above that comunicate in a proper way with machinekit, at least a HAL module/ direver that manages the CAN communication and shows all the connected MCU to the other HAL module Another system that try to solve this is EtherCAT, LinuxCNC can surely talk with ethercat modules I tried it a couple of years ago, and i found that the industrial world use EtherCAT on windows and has the xml config file written in a different way from the LinuxCNC world. Manufacturer will give the config in the standard way, and you will have to translate it for yourself. For example, I made a xml file to work with that arduino shield <https://www.bausano.net/en/hardware/ethercat-e-arduino/easycat.html> , but I died while trying to interface with a Weidmuller EtherCAT module (again, it was a couple of years ago, and I am a very beginner). talking about the Raspberry, I have seen everyone avoided it's Ethernet controller is on the USB-bus, so it's inherently non-real-time. Other boards available are the asus Tinkerboard, or the banana Pi, but I have seen few people using that alternatives. mngr Il giorno martedì 18 settembre 2018 05:07:43 UTC+2, Joshua Dickerson ha scritto: > > Hello everyone, > > I am working on and off again on writing my own machine controller, > largely to understand LinuxCNC and related projects like MachineKit. For > reference, here's the controller I wrote running a few years ago: > > https://www.youtube.com/watch?v=qasLhuJFZNU > > > I'm starting back up on the project. Right now it works very similar to > LinuxCNC, a shared memory space, all HAL components running on a single > controller. What I want to do is make a machine controller that could have > conceivably worked on 80s MCUs, but also work on single desktop machine. > The idea would be to have a distributed HAL that would function across > multiple MCUs- but of course works in the degenerate case of a single > machine/PC with shared memory space, as with LinuxCNC. For instance, there > would be a main MCU which reads files, runs the GUI/HMI and handles the > trajectory planning, homing, probing, tapping, etc. There would also be a > dedicated MCU for each joint controller which is updating encoders and > sensors, generating step pulses, closing servo loops, etc. > > My naive approach would be to have a registry of output signals which > includes which MCU each actually resides on. So if a particular HAL > component task is reading a signal that's already on the MCU it's running > on, it's immediately returned- otherwise it pulls the data over a network > layer (which could shared memory bus, RS485, ethernet, etc.) Is there > something out there that does this? Maybe some kind of mutant hybrid > between HAL/NML/SCADA? > > Of course this complicates things over simply using pointers to a single > shared memory space. I also get the sense the linuxCNC group balks at this > kind of idea, they want to keep it all on one machine in the interest of > latency anyway. Just searching various machine controller project > communities for where this kind of idea might be interesting. I would > really like something like a Raspberry Pi tied into a MCU which does all > the hard-RT/IO stuff, but not quite in the way Klipper does it. Klipper > basically sends commands to be followed at some specific time stamp. > That's actually pretty cool, but I want something that allows for more > feedback and flexibility between the various systems. > > Anyhow, thanks in advance for your 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: Error when install Machinekit on Raspberry Pi 3, Raspian Stretch
Thanks Tac!! i was just about to ask how did you make a debian stretch real-time image for the Pi, thank you very much! Il giorno lunedì 17 settembre 2018 19:54:18 UTC+2, Tac Huynh ha scritto: > > Thanks Schooner. > Latest update worked. > > For other people using the raspberry pi. I used the ready made image from > RealtimePi. > > https://github.com/guysoft/RealtimePi > > saving a lot of time for patching the preEmpt realtime kernel > Tac. > > On Friday, September 14, 2018 at 7:41:29 AM UTC-7, Tac Huynh wrote: >> >> Please help: >> How do I fix this installation error? >> Thanks, >> Tac. >> >> I tried to install Machinekit on Raspberry Pi 3, Raspian Stretch, got >> following errors: >> >> sudo apt-get install machinekit-rt-preempt >> >> >> Setting up xdot (0.7-2) ... >> Setting up machinekit-rt-preempt (0.1.1536747208.git041712d-1~stretch) ... >> ln: failed to create symbolic link >> '/usr/lib/linuxcnc/rt-preempt/pru_generic.bin': No such file or directory >> ln: failed to create symbolic link >> '/usr/lib/linuxcnc/rt-preempt/pru_generic.dbg': No such file or directory >> ln: failed to create symbolic link >> '/usr/lib/linuxcnc/rt-preempt/pru_decamux.bin': No such file or directory >> ln: failed to create symbolic link >> '/usr/lib/linuxcnc/rt-preempt/pru_decamux.dbg': No such file or directory >> dpkg: error processing package machinekit-rt-preempt (--configure): >> subprocess installed post-installation script returned error exit status 1 >> dpkg: dependency problems prevent configuration of machinekit: >> machinekit depends on machinekit-rt-threads; however: >> Package machinekit-rt-threads is not installed. >> Package machinekit-rt-preempt which provides machinekit-rt-threads is not >> configured yet. >> >> dpkg: error processing package machinekit (--configure): >> dependency problems - leaving unconfigured >> Processing triggers for libc-bin (2.24-11+deb9u3) ... >> Processing triggers for systemd (232-25+deb9u2) ... >> Errors were encountered while processing: >> machinekit-rt-preempt >> machinekit >> E: Sub-process /usr/bin/dpkg returned an error code (1) >> >> -- 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: Error when install Machinekit on Raspberry Pi 3, Raspian Stretch
Wow, you have been fast! is there a way for us to manually set this variable? or will you release a new package? Il giorno domenica 16 settembre 2018 16:56:48 UTC+2, Schooner ha scritto: > > Thanks > > I have found the error, the problem was that a variable was not getting > set, but because it was then 0, > if you tested on a posix thread, because posix is enumerated to 0, there > was no problem :-P > > > On 16/09/18 15:29, mngr wrote: > > I installed the old machinekit version, taken from you comment, and the > upgraded > > Il giorno domenica 16 settembre 2018 16:28:31 UTC+2, mngr ha scritto: >> >> Same issue here, I am on jessie, debian 8.0 >> >> Linux raspberrypi 4.4.4-rt9-v7+ #7 SMP PREEMPT RT Mon Mar 7 14:53:11 UTC >> 2016 armv7l GNU/Linux >> >> here is the console output, maybe it helps >> >> MACHINEKIT - 0.1 >> Machine configuration directory is >> '/home/pi/machinekit/configs/ARM.BeagleBone.CRAMPS' >> Machine configuration file is 'CRAMPS.ini' >> Starting Machinekit... >> Warning - /usr/libexec/linuxcnc/rtapi_app_posix not setuid >> 'sudo make setuid' missing? >> rtapi_msgd command: /usr/libexec/linuxcnc/rtapi_msgd --instance=0 >> --rtmsglevel=5 --usrmsglevel=5 --halsize=524288 >> rtapi_app command: /usr/libexec/linuxcnc/rtapi_app_posix --instance=0 >> /usr/bin/realtime: line 237: /usr/libexec/linuxcnc/rtapi_app_posix: No >> such file or directory >> rtapi_app startup failed; aborting >> halcmd: cant connect to rtapi_app: -1 (uri= >> uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout >> E: 18-09-16 14:25:25 dangling 'DEALER' socket created at >> hal/utils/halcmd_rtapiapp.cc:281 >> >> >> Il giorno domenica 16 settembre 2018 15:40:13 UTC+2, Schooner ha scritto: >>> >>> This is the same error as in this thread >>> Re: [Machinekit] Re: RT demon is not running. rtapi_app_main(rtapi): -22 >>> Invalid argument ??? >>> >>> Looks like the rt-preempt is reported as being posix, at a guess. >>> Probably why it does not cause an issue when it IS a posix install like >>> mine. >>> >>> Thanks, I will look at it again and see if I can find a way to install a >>> rt-preempt kernel for testing on arm. >>> Perhaps test on amd64 rt-preempt first, if it fails on that it will be >>> much easier to work on. >>> >>> >>> On 16/09/18 13:58, Tac Huynh wrote: >>> > Sep 16 12:52:23 realtimepi rtapi:0: 4:rtapi_app:1514:user RTAPI:0 >>> > posix v0.1~-~e656585 init >>> > Sep 16 12:52:23 realtimepi rtapi:0: 1:rtapi_app:1514:user RTAPI:0 BUG: >>> > thread flavors dont match: global 1 rtapi 0 >>> > Sep 16 12:52:23 realtimepi rtapi:0: rtapi_app_main(rtapi): -22 Invalid >>> > argumen >>> >>> -- > 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] Re: Error when install Machinekit on Raspberry Pi 3, Raspian Stretch
I installed the old machinekit version, taken from you comment, and the upgraded Il giorno domenica 16 settembre 2018 16:28:31 UTC+2, mngr ha scritto: > > Same issue here, I am on jessie, debian 8.0 > > Linux raspberrypi 4.4.4-rt9-v7+ #7 SMP PREEMPT RT Mon Mar 7 14:53:11 UTC > 2016 armv7l GNU/Linux > > here is the console output, maybe it helps > > MACHINEKIT - 0.1 > Machine configuration directory is > '/home/pi/machinekit/configs/ARM.BeagleBone.CRAMPS' > Machine configuration file is 'CRAMPS.ini' > Starting Machinekit... > Warning - /usr/libexec/linuxcnc/rtapi_app_posix not setuid > 'sudo make setuid' missing? > rtapi_msgd command: /usr/libexec/linuxcnc/rtapi_msgd --instance=0 > --rtmsglevel=5 --usrmsglevel=5 --halsize=524288 > rtapi_app command: /usr/libexec/linuxcnc/rtapi_app_posix --instance=0 > /usr/bin/realtime: line 237: /usr/libexec/linuxcnc/rtapi_app_posix: No > such file or directory > rtapi_app startup failed; aborting > halcmd: cant connect to rtapi_app: -1 (uri= > uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout > E: 18-09-16 14:25:25 dangling 'DEALER' socket created at > hal/utils/halcmd_rtapiapp.cc:281 > > > Il giorno domenica 16 settembre 2018 15:40:13 UTC+2, Schooner ha scritto: >> >> This is the same error as in this thread >> Re: [Machinekit] Re: RT demon is not running. rtapi_app_main(rtapi): -22 >> Invalid argument ??? >> >> Looks like the rt-preempt is reported as being posix, at a guess. >> Probably why it does not cause an issue when it IS a posix install like >> mine. >> >> Thanks, I will look at it again and see if I can find a way to install a >> rt-preempt kernel for testing on arm. >> Perhaps test on amd64 rt-preempt first, if it fails on that it will be >> much easier to work on. >> >> >> On 16/09/18 13:58, Tac Huynh wrote: >> > Sep 16 12:52:23 realtimepi rtapi:0: 4:rtapi_app:1514:user RTAPI:0 >> > posix v0.1~-~e656585 init >> > Sep 16 12:52:23 realtimepi rtapi:0: 1:rtapi_app:1514:user RTAPI:0 BUG: >> > thread flavors dont match: global 1 rtapi 0 >> > Sep 16 12:52:23 realtimepi rtapi:0: rtapi_app_main(rtapi): -22 Invalid >> > argumen >> >> -- 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: Error when install Machinekit on Raspberry Pi 3, Raspian Stretch
Same issue here, I am on jessie, debian 8.0 Linux raspberrypi 4.4.4-rt9-v7+ #7 SMP PREEMPT RT Mon Mar 7 14:53:11 UTC 2016 armv7l GNU/Linux here is the console output, maybe it helps MACHINEKIT - 0.1 Machine configuration directory is '/home/pi/machinekit/configs/ARM.BeagleBone.CRAMPS' Machine configuration file is 'CRAMPS.ini' Starting Machinekit... Warning - /usr/libexec/linuxcnc/rtapi_app_posix not setuid 'sudo make setuid' missing? rtapi_msgd command: /usr/libexec/linuxcnc/rtapi_msgd --instance=0 --rtmsglevel=5 --usrmsglevel=5 --halsize=524288 rtapi_app command: /usr/libexec/linuxcnc/rtapi_app_posix --instance=0 /usr/bin/realtime: line 237: /usr/libexec/linuxcnc/rtapi_app_posix: No such file or directory rtapi_app startup failed; aborting halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout E: 18-09-16 14:25:25 dangling 'DEALER' socket created at hal/utils/halcmd_rtapiapp.cc:281 Il giorno domenica 16 settembre 2018 15:40:13 UTC+2, Schooner ha scritto: > > This is the same error as in this thread > Re: [Machinekit] Re: RT demon is not running. rtapi_app_main(rtapi): -22 > Invalid argument ??? > > Looks like the rt-preempt is reported as being posix, at a guess. > Probably why it does not cause an issue when it IS a posix install like > mine. > > Thanks, I will look at it again and see if I can find a way to install a > rt-preempt kernel for testing on arm. > Perhaps test on amd64 rt-preempt first, if it fails on that it will be > much easier to work on. > > > On 16/09/18 13:58, Tac Huynh wrote: > > Sep 16 12:52:23 realtimepi rtapi:0: 4:rtapi_app:1514:user RTAPI:0 > > posix v0.1~-~e656585 init > > Sep 16 12:52:23 realtimepi rtapi:0: 1:rtapi_app:1514:user RTAPI:0 BUG: > > thread flavors dont match: global 1 rtapi 0 > > Sep 16 12:52:23 realtimepi rtapi:0: rtapi_app_main(rtapi): -22 Invalid > > argumen > > -- 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] best way of making new hal modules
Il giorno giovedì 13 settembre 2018 10:52:53 UTC+2, Schooner ha scritto: > > > On 11/09/18 22:58, mngr wrote: > > Hi, > > I have to declare some new HAL modules, which is the best way to do it? > > First one: when a security switch gets pressed I have to pause the > printing and override actual temperature and position (move up of a cm), > before resuming printing I need to wait for the temperature to be on point. > My idea: defining a new "pause" button, outside of axis, and show it in a > glade panel. this module will know the switch state and pause axis, and > know temperature so it will resume axis only when it is possible. > I looked in the guide, I guess I should do it in icomp, is it suited? or > is there a better way? > > > I have just included a 'watch' instantiated component into machinekit, > along with a demo sim > > > https://github.com/machinekit/machinekit/blob/master/src/hal/user_icomps/watch.c > > https://github.com/machinekit/machinekit/tree/master/configs/sim/axis/watch-demo-sim > > You may find it of use, in itself or as a guide, as I wrote it to get over > the problem of monitoring a pin value without constantly calling halcmd and > trying to parse the output. > (which is what M109 in FDM does) > > The sim demo shows how to use it in a dummy FDM printer heater scenario, > setting a pin or signal to the target value (eg. heater component) > monitoring a pin value and setting an output pin and triggering a message > in a pyvcp panel when it reaches a target value. > > Thanks! Will look on that! > > Second one: this is more like a driver, I have to take the commanded > position from axis, do some stepgen-magic things and send the velocity to > the stepper controller via spi. (the point is sending something via spi, > from a raspberry) > What should I use to write this? > Here ( > https://forum.linuxcnc.org/27-driver-boards/29742-pidicnc-control-system?start=50#115691) > > I have something very similar to what I want to do,after line 2300 ( > https://github.com/mngr0/stepgenspi/blob/master/pidi.c#L2306) there is > the code to write directly on the registers for spi (code made for the > raspberry). > I guess that lot of common libraries for rpi-spi cannot work in real-time > environment, what can be a clean way to implement that? > > > I'll leave bit twiddling on a Pi to someone else to answer :) > I have found a hal module called hal_spi.h <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_spi.h>, I am hoping it works, cause it is maybe exactly what I need > > > by the way, in the guide > http://www.machinekit.io/docs/developing/writing-components/ there is a > dead link at "Further info here > <http://www.machinekit.io/docs/hal/new-instantiated-components>" > > > Looks like an old doc ref, I'll check later > > Probably see > http://www.machinekit.io/docs/hal/instcomp_writing_a_component > for a tutorial I wrote regards instcomp specifically > > 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.
[Machinekit] best way of making new hal modules
Hi, I have to declare some new HAL modules, which is the best way to do it? First one: when a security switch gets pressed I have to pause the printing and override actual temperature and position (move up of a cm), before resuming printing I need to wait for the temperature to be on point. My idea: defining a new "pause" button, outside of axis, and show it in a glade panel. this module will know the switch state and pause axis, and know temperature so it will resume axis only when it is possible. I looked in the guide, I guess I should do it in icomp, is it suited? or is there a better way? Second one: this is more like a driver, I have to take the commanded position from axis, do some stepgen-magic things and send the velocity to the stepper controller via spi. (the point is sending something via spi, from a raspberry) What should I use to write this? Here ( https://forum.linuxcnc.org/27-driver-boards/29742-pidicnc-control-system?start=50#115691) I have something very similar to what I want to do,after line 2300 ( https://github.com/mngr0/stepgenspi/blob/master/pidi.c#L2306) there is the code to write directly on the registers for spi (code made for the raspberry). I guess that lot of common libraries for rpi-spi cannot work in real-time environment, what can be a clean way to implement that? by the way, in the guide http://www.machinekit.io/docs/developing/writing-components/ there is a dead link at "Further info here <http://www.machinekit.io/docs/hal/new-instantiated-components>" 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+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
[Machinekit] launching machinekit after build
Hi, I have build machinekit from source, now I am trying to launch it. marco@tmarco:~/machinekit$ ./bin/machinekit ./bin/machinekit: line 1: linuxcnc: command not found I tried to make a simbolic link to tcl/linuxcnc.so in /usr/lib/ but nothing changed I am sure I am simply noob, and don't know the standard procedure... can you please help me? now I don't have a kernel-rt, but I will only do test, does this change anything? 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+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] Lattice FPGA
Thanks Michael! Some little news about my project: I am working in myHDL (yep, python) and I am using this repo https://github.com/mngr0/test myHDL gets translated in verilog or VHDL before synthesis, I go for verilog, to use icestorm. (I am learning a lot in these days). At this point I have a very simple pulse generator, with some other support module (or block, depending on the language you are used to) All the motor control side is overall easy to implement, but I have problem to understand how machinekit/linuxcnc communicate with the mesa card (can I say that there is a protocol, and call it hostmot2?) I have been told to look in hal/drivers/mesa-hostmot2 <https://github.com/LinuxCNC/linuxcnc/tree/master/src/hal/drivers/mesa-hostmot2> in linuxcnc repo, or in the VHDL source code, but there is a very lot of code, and I don't even exactly know what I am looking for... can anyone bring some light on this? mngr0 Il giorno giovedì 2 agosto 2018 14:52:41 UTC+2, Michael Brown ha scritto: > > THe hostmot3 variant has been tied to the (neglected)Cramps cape versions, > and > an experimental persuit to create a more comprehensive Systemverilog > config system. > > The simplicity is due only including stuff that can be driven by the (bbb) > Cramps cape: > steppers, pwm's and adc converter. > > I think the xxx_Cramps projects still are in working shape and should be > more easy to comprehend > due to the minimal functionality. > > BTW > Nice to hear from a fellow Verilog programmer :-) > > On Saturday, 28 July 2018 16:15:50 UTC+2, mngr wrote: >> >> I just realized that hostmot3 does the same thing of hstmot2, but the 3 >> is very more tidy. >> I was following the signals to and form the modules (the entityes used in >> hostmot3) and i see that they come from outside of hostmot3. >> Then I saw the hostmot3_cfg.vhd file in DE0 and DE10 config folders, but >> here too the signals come from outside... >> I think that the "main" is generated by a script >> >> >> >> Il giorno venerdì 27 luglio 2018 17:06:23 UTC+2, mngr ha scritto: >>> >>> thanks pcwcol, >>> >>> the index/probe support has some concrete functionality or is only for >>> debugging? >>> >>> I see hostmot2 and hostmot3, can I assume that these are two possible >>> global configuration (I mean, they are never used togheter)? >>> a grep reveals that hostmot3 does not make use of any stepgen entity, so >>> I am ignoring it. >>> >>> Is this right or I am missing something? >>> - mostra testo citato - >>> >>> >>> Il giorno mercoledì 18 luglio 2018 19:40:37 UTC+2, pcwcol ha scritto: >>>> >>>> >>>> >>>> On Tuesday, July 17, 2018 at 7:55:08 AM UTC-7, mngr wrote: >>>>> >>>>> Thanks Charles, >>>>> >>>>> The open source toochain for Lattice FPGA works only with Verilog, for >>>>> what I know, so I will have to translate from VHDL. >>>>> What do you think about that? >>>>> >>>>> I have tried to understand wat the qcounter* modules do, but may I ask >>>>> for a bit of explanation about them? >>>>> >>>>> What other modules do I need to make a step generator? (the most >>>>> simple possible) >>>>> what is the difference between kubstepgenz and kubstepgenzi? (I guess >>>>> those are stepgens... what does the "i" stands for? just like "kub", what >>>>> does it mean?) >>>>> >>>>> >>>>> Thanks and regards, >>>>> mngr >>>>> >>>>> Il giorno sabato 9 giugno 2018 03:52:01 UTC+2, Charles Steinkuehler ha >>>>> scritto: >>>>>> >>>>>> On 6/7/2018 11:46 AM, mngr wrote: >>>>>> > Hi everybody, >>>>>> > >>>>>> > I am trying to replicate the mesa drivers, but using a Lattice >>>>>> FPGA, since >>>>>> > there is an open source toolchain for them. >>>>>> > I want to do something like the 7i76, maybe 7i76E if managing the >>>>>> ethernet >>>>>> > does not consume too much logic elements. >>>>>> > >>>>>> > I have seen mksocfpga, and I have searched for a vhd module that >>>>>> control >>>>>> > the position and gives steps and direction to the motor. >>>>>> > Is there a module like th
