#linuxcnc-devel Logs

Mar 20 2018

08:16 AM ed_: hello
12:34 PM hazzy-dev: After much head scratching it seem that the LCNC config picker does not follow sim links, amirite?
12:35 PM hazzy-dev: I don't use the config picker much, but it seems like it might be a nice option it it did follow links, it there a reason why it does not?
12:39 PM seb_kuzminsky: it doesnt? i agree it probably should
01:02 PM cradek: you can't necessarily represent a symlinked heirarchy in a tree widget
01:03 PM cradek: what problem are you trying to solve by using symlinks?
01:24 PM hazzy-dev: cradek: I keep all my lcnc configs and other machine specific files in git repos located in ~/gitrepos.
01:24 PM hazzy-dev: I normally launch LCNC from the cmd line specifying the desired INI, but I was just playing around with the config picker and thought I would link the configs so I could use the picker to browse/launch them
01:24 PM hazzy-dev: No big deal since most of the configs won't even run on this sim machine
01:25 PM cradek: cool, I recommend making ~/linuxcnc the git repo directly, so you don't have to maintain things outside of git (your symlink structure)
01:25 PM cradek: I sure do exactly that
01:27 PM hazzy-dev: I guess that would work, the config dirs are nested a few layers deep though, will the config picker still find the INI files?
01:27 PM * hazzy-dev off to try it!
01:30 PM hazzy-dev: That works nicely! And the config picker even only shows the dirs that contain .ini files!
01:30 PM hazzy-dev: Thanks cradek!
01:32 PM cradek: sweet!
01:42 PM skunkworks: but that wasn't what hazzy-dev wanted? Damn you!
01:42 PM skunkworks: ;)
01:44 PM hazzy-dev: lol skunkworks, that was very slick of cradek! He changed the problem to something that *I* had to fix, not himf :D
01:44 PM skunkworks: I find that a lot on here...
01:44 PM skunkworks: (but usually the more correct solution..)
01:46 PM cradek: sometimes the first solution you think of isn't the best one, and it's easy to get stuck on it.
01:54 PM jepler: on maintainers vs developers https://lwn.net/SubscriberLink/749676/94d7eb1a8f6a3b47/
01:57 PM jepler: > The community, he said, likes to think that its decisions are based entirely on merit. In truth, there is also an important social element involved in working in the development community
01:57 PM jepler: qft
02:06 PM Tom_itx: http://paste.debian.net/1015741/
02:06 PM Tom_itx: any ideas?
02:07 PM Tom_itx: not sure it's a 'feature' or not...
02:07 PM Tom_itx: also, the correct numbes show up in AXIS when each offset it MDI input
02:08 PM Tom_itx: numbers*
02:08 PM Tom_itx: tried it with G90 and G91 active
02:08 PM cradek: what is your ngcgui home axis button supposed to do?
02:08 PM Tom_itx: send it to the x y z zero fixture offset
02:09 PM cradek: how?
02:09 PM Tom_itx: let me find the code
02:10 PM Tom_itx: i don't have it here, i'll have to go out to the machine
02:11 PM Tom_itx: MDI_COMMAND = O<work_zero> call
02:11 PM Tom_itx: i'll get the ngc file..
02:17 PM Tom_itx: appears that file is a symbolic link :(
02:17 PM Tom_itx: maybe that's it
02:19 PM Tom_itx: o<work_zero> sub
02:19 PM Tom_itx: G90
02:19 PM Tom_itx: G0 Z0
02:19 PM Tom_itx: G0 X0 Y0
02:19 PM Tom_itx: o<work_zero> endsub
02:19 PM Tom_itx: m2
02:20 PM Tom_itx: like i said, it works until i power down and restart it after homing
02:20 PM cradek: well luckily since they're zeroes at least you don't have a inch/mm bug. but any active G92 offsets or tool offsets will break this.
02:21 PM cradek: on the AXIS screen you can see both those kinds of offset
02:21 PM cradek: have a look at the differences between when it does what you expect and when it doesn't
02:22 PM Tom_itx: the numbers in the post appear in axis after selecting the appropriate work ofset: G54 G55 yes
02:22 PM Tom_itx: and i can jog to those coordinates and it's where it's supposed to be
02:23 PM Tom_itx: running 2 fixture offsets in this program...
02:23 PM Tom_itx: well, trying to
02:28 PM Tom_itx: should i add an H word for the current tool there?
04:01 PM hazzy-dev: Why does master emit duplicate error messages when joint/axis limits are exceeded? http://dpaste.com/1EZ4Z5G
04:01 PM hazzy-dev: Is one of the errors for the joint limit being exceeded and the other for the axis limit being exceeded?
04:02 PM hazzy-dev: I did not think the joint limits were checked at this time
04:10 PM rene-dev: joint position min/max are checked, so you can get 2 errors.
04:11 PM rene-dev: joint vel/acc is not checked in works mode, as this is currently not possible.
04:11 PM rene-dev: because the planner is not aware of the joints, as the kinematic is after the planner.
04:14 PM hazzy-dev: Thank you rene-dev
04:15 PM hazzy-dev: I did not realize the joint limits were checked, that is great!
04:16 PM hazzy-dev: I really should find/build a non trivial machine so I can play with joints more ...
04:27 PM seb_kuzminsky: jepler: i saw that lwn writeup, it's pretty spot on
06:40 PM jepler: andypugh: I would love to see a blog post about your 3d printed foundry patterns too
06:50 PM skunkworks: blog
06:50 PM skunkworks: heh
07:12 PM jepler: skunkworks: I'm obliquely referring to http://bodgesoc.blogspot.com/2018/03/LED.html
07:14 PM andypugh: I haven’t blogged it up yet. But this is a 3D printed pattern: https://photos.app.goo.gl/FQ5ndcRE8pnUs3zv1
07:15 PM andypugh: (fancy sectional one) to make this: https://photos.app.goo.gl/Uxso8ficUUmfZC5p1
07:23 PM jepler: thanks for the photos andypugh
07:33 PM Tom_shop: the issue i've been having, fails on a G0 Z0 MDI command
07:33 PM Tom_shop: does nothing
07:38 PM skunkworks: Andy just needs to blog about what he is doing every day... I am sure it would be very interesting
07:41 PM hazzy-dev: The difference between QtCreator and Glade: When glade crashes you can just restart the application and keep going, when QtCreator crashes the whole OS goes down, HARD :)
07:44 PM skunkworks: ouch
07:49 PM hazzy-dev: Of course they are not in the same league since QtCreator is a full on IDE, so I guess there is a lot more to go wrong, but then I was just opening a file ...
08:32 PM jepler: $ python2 -c 'import math; print(type(math.floor(3.14)))'
08:32 PM jepler: <type 'float'>
08:32 PM jepler: $ python3 -c 'import math; print(type(math.floor(3.14)))'
08:32 PM jepler: <class 'int'>
08:32 PM jepler: wtf python3
08:45 PM hazzy-dev: jepler: It makes sense to return an INT since the the mathematical meaning of floor is the largest integer less than the number
08:46 PM hazzy-dev: I say Py2 is the one that is wrong :)
08:48 PM hazzy-dev: lol, look at the definition of floor in 2.7: "Return the floor of x as a *float*, the largest *integer* value less than or equal to x."
08:49 PM jepler: hazzy-dev: should be the same as C
08:51 PM hazzy-dev: Doesn't C return an Int?
08:51 PM jepler: of course not
08:52 PM jepler: afaik IEC 60559 aka IEEE 754 arithmetic always specified the *return type* of ceil() / floor() as a floating point type
08:53 PM hazzy-dev: Hmm, that seems counter intuitive, interesting
08:54 PM jepler: $ python2 -c 'inf = 1e400; import math; print(math.ceil(inf))'
08:54 PM jepler: inf
08:54 PM jepler: $ python3 -c 'inf = 1e400; import math; print(math.ceil(inf))'
08:54 PM jepler: OverflowError: cannot convert float infinity to integer
08:55 PM jepler: for any FP number x, floor(x) and ciel(x) are exactly representable
08:55 PM jepler: and no exceptions (of the python type) for inf and nan, the functions simply return the values
08:58 PM jepler: $ python3 -c 'import numpy; print(numpy.floor(1e400))'
08:58 PM jepler: inf
08:58 PM jepler: numpy follows C
09:02 PM jepler: hmmm I may be wrong, in that IEE Std 754-1985 actually doesn't *define* floor. I wrongly inferred that when ISO/IEC 9899:2011 Annex F "IEC 60559 floating-point arithmetic" specified how floor() and ceil() work, they were essentially restating IEEE 754
09:03 PM jepler: in C there is no arbitrary precision integer type for them to elect to return
09:04 PM jepler: ah here's 754, they just don't call any of the functions after the names in C
09:04 PM jepler: > 5.9 Details of operations to round a floating-point datum to integral value
09:04 PM jepler: 5.9.0
09:04 PM jepler: Several operations round a floating-point number to an integral valued floating-point number in the same
09:04 PM jepler: format.
09:06 PM jepler: here's the only way I've figured so far that python3 does something useful with an input that python2 chokes on..
09:06 PM jepler: $ python3 -c 'import math; print(math.ceil(10**400))'
09:07 PM jepler: python3 returns the argument, python2 gives an exception: OverflowError: long int too large to convert to float
09:07 PM jepler: OK, I'm done arguing with mysel
09:07 PM jepler: f
09:07 PM jepler: (no I'm not)
10:04 PM * hazzy-dev 's gears are still crunching