#linuxcnc-devel Logs

Apr 24 2017

03:21 AM KGB-linuxcnc: 03Norbert Schechner 05master 532d771 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_2_3_1 - added a new hal pin for tool diameter * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=532d771
07:01 AM KGB-linuxcnc: 03John Thornton 052.7 c2d0786 06linuxcnc 10docs/src/gui/pyvcp.txt Docs: fix multi label description * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c2d0786
10:14 AM seb_kuzminsky: does anyone have an idea on Evan Foss's configure problem? It looks to me like he's got the right boost_python library name and the path to it in LDFLAGS -L, but his linker still says it can't link configure's test program
10:15 AM seb_kuzminsky: https://sourceforge.net/p/emc/mailman/emc-users/thread/CAM2RGhTN7BwT_rwZn45PYDoFuzmoPpPt-BmZBB-zM95S-g5FMw%40mail.gmail.com/#msg35803051
10:15 AM cradek: cannot find -lboost_python-py27 collect2: error:
10:16 AM seb_kuzminsky: yeah, that's sure the key error message
10:16 AM cradek: said earlier you have it here: /usr/lib64/libboost_python-2.7.so
10:16 AM cradek: those don't match
10:16 AM seb_kuzminsky: the linker command line has the right -L
10:16 AM cradek: no the filenames don't match
10:16 AM cradek: -2.7 vs -py27
10:16 AM seb_kuzminsky: oh you're right!
10:16 AM seb_kuzminsky: darn it all to heck
10:17 AM * seb_kuzminsky <-- derp
10:17 AM cradek: heck darn picklejuice
10:18 AM seb_kuzminsky: heh i just had a Go game that felt a lot like this conversation :-/
10:20 AM seb_kuzminsky: thanks cradek
10:21 AM cradek: welcome/sorry
10:31 AM jepler: pcw_home: if you get a chance can you try with the jepler/setfsuid branch to check that (A) hostmot2 still works for you on your mint systems and (B) whether it has fixed the missed realtime deadline starting halscope
10:31 AM jepler: I tested ethernet and pci cards on my jessie system; I don't reproduce the missed deadline starting halscope, so I can't test whether it's fixed
10:57 AM pcw_home: I can test it on this Ubuntu 16.04 system (it reliable gets a real time error when launching Halscope for the first time)
11:16 AM pcw_home: Hmm still get a joint following error when launching HALScope (if moving)
11:16 AM pcw_home: Interestingly, servo-thread.tmax is not changed
11:24 AM jepler: :-/ darn
11:24 AM jepler: but you think this didn't always happen in uspace?
11:24 AM jepler: .. doesn't happen in 2.7 ?
11:37 AM pcw_home: I dont think ive ever seen it before master /Mint18/Ubuntu 16.04 with their required patch to fix halscope permissions
12:06 PM cradek: in the before times, we had to load the rt part of halscope [before hal start] for halscope to work. does doing that again fix this?
12:28 PM pcw_mesa: how would you do that?
12:32 PM cradek: I think it's just loadrt halscope_rt
02:33 PM jepler: cradek: we did?
02:33 PM jepler: pcw_home: please remind me what patch is needed for Mint 18 halscope permissions
02:36 PM jepler: I seem to remember seeing it once and poo-poohing it
02:39 PM cradek: > if the scope_rt component was not already loaded, halscope will load it (2.2 docs)
02:40 PM cradek: Halscope has two parts - a realtime part that is loaded as a kernel module, and a user part that
02:40 PM jepler: ah that was an enhancement in the 2.2 release? that must be very long ago
02:40 PM cradek: supplies the GUI and display. Before starting the GUI you must load the realtime part:
02:40 PM cradek: (2.0 docs)
02:40 PM cradek: too tired to check 2.1
02:40 PM jepler: no worries
02:40 PM jepler: I accept your version of history now
02:45 PM jepler: seems like creating a new map with mmap must be a similar stop-the-world affair to setresuid
02:46 PM jepler: so it's weird I can't reproduce pcw's report and may be even weirder that the same rtai test stops crashing after I get rid of setresuid
03:28 PM pcw_mesa: Halscope would not launch on Mint 18 / Ubuntu 16.04 (shared memory permission error IICRC)
03:49 PM jepler: affecting 2.7 only, or master too?
04:02 PM pcw_mesa: Let me check 2.7
04:16 PM pcw_mesa: Works on 2.7
04:18 PM jepler: OK, so affects master only?
04:18 PM jepler: but you had some workaround you mentioned?
04:18 PM pcw_mesa: seem to
04:41 PM pcw_mesa: http://psha.org.ru/irc/%23linuxcnc-devel/2016-11-26.html#
04:50 PM jepler: pcw_home: I vaguely remember this conversation now, thanks for fiding it
04:50 PM jepler: finding
04:50 PM jepler: it didn't seem to come to a satisfactory conclusion though
05:17 PM pcw_mesa: no its still fairly mysterious
05:55 PM andypugh: The commit that added floats to smart-serial produces a warning about type-punning.
05:56 PM andypugh: The code in question was written by Rene, and it seems to work
05:58 PM andypugh: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/mesa-hostmot2/sserial.c#L1529
05:59 PM andypugh: (When I fix the warning I will also fix the white-space, that bit is my fault, unfamilar editor)
06:00 PM andypugh: Is memcpy the “right” way to take a bit pattern out of an integer buffer, interpret it as a single-precision float, and put that decimal value into a double HAL pin?
06:03 PM andypugh: The actual message from the compiler is “hal/drivers/mesa-hostmot2/sserial.c:1531:6: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]"
06:27 PM seb_kuzminsky: memcpy will work, or i think you can just cast a pointer in the right way and assign
06:31 PM andypugh: float *temp = &buff; ?
06:32 PM seb_kuzminsky: something like this:
06:32 PM seb_kuzminsky: float f;
06:32 PM seb_kuzminsky: uint8_t *buffer;
06:32 PM seb_kuzminsky: f = *(float*)buffer;
06:36 PM andypugh: buff is already an rtapi_u64
06:36 PM seb_kuzminsky: uint64_t *buf;
06:37 PM seb_kuzminsky: f = *(float*)buf;
06:37 PM andypugh: (And now I realise that, I think I see a part of the problem)
06:37 PM seb_kuzminsky: ;-)
06:43 PM andypugh: I am not sure if memcpy doesn’t seem “cleaner” somehow.
06:43 PM andypugh: I have 96 bits in a row, comprising potentially many data types.
06:46 PM andypugh: I already have the “buff”, and not as a pointer. So would I also need buf = &buff in you scheme?
06:47 PM andypugh: rtapi_u64 *b;
06:47 PM andypugh: b = &buff
06:48 PM andypugh: f = *(float*)b;
06:53 PM andypugh: Clearly that isnt right.
06:53 PM andypugh: rtapi_u32 *temp;
06:53 PM andypugh: temp = &buff;
06:54 PM andypugh: Is “warning: assignment from incompatible pointer type”
06:54 PM Tinker09: Hello! Can i ask you where to learn the Linux CNC trajectory planner ? :)
06:55 PM andypugh: I sish I understoof the tp myself
06:55 PM andypugh: (wish I understood)
06:56 PM andypugh: Tinker09: I assume you have tried staring at the code?
06:58 PM Tinker09: I'm new to linux CNC. I did trying looking for the code but it is nowhere to be found :D
06:58 PM andypugh: https://github.com/LinuxCNC/linuxcnc/tree/master/src/emc/tp
06:59 PM Tinker09: wow! Thank you :) so this trajectory planner is linux CNC team effort, or does is it from any standard mathematical sources.. :D
07:00 PM Tinker09: because i don't know which is the standard for trajectory planner ( i have searched for NURBS, DDA...)
07:01 PM andypugh: It was re-written a few years ago to use circular arc blends. Previously it used parabolc blends (parabolic blends are just what you get when you accelerate axes independently as a fixed rate)
07:04 PM andypugh: Tinker09: This is a presentation about the new TP from the author: https://www.youtube.com/watch?v=412N5A-N8Fc
07:07 PM Tinker09: thank you Sir! i will start learning it, thank you for your rapid help. Linux CNC is the best ! :)
07:50 PM andypugh: seb_kuzminsky: Well, squashed all the warnings with memcpy. The only slight drawback is that the driver no-longer works.
07:50 PM andypugh: Job for tomorrow.
07:50 PM andypugh: Night all