Back
[05:49:53] <jthornton> anyone know what this error means Disriminant -0.012892 <0 in velocity calculation!"
[05:50:01] <jthornton> http://linuxcnc.org/index.php/english/forum/40-subroutines-and-ngcgui/29451-rigid-tapping-fail-advice-and-qdiscriminantq-err
[06:06:28] <skunkworks> jthornton: we are in the process of fixing that problem. A sample of gcode that shows the problem would help.
[06:07:01] <skunkworks> rob has a branch that takes care of the issue - but causes a few violations he hopes to look at this week.
[06:07:34] <jthornton> thanks
[06:20:02] <KGB-linuxcnc> 03John Thornton 052.7 b86ba3e 06linuxcnc 10docs/src/config/stepper.txt Docs: remove some unused anchors * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b86ba3e
[08:44:07] <mozmck> In 2.7, if you need a dual motor gantry setup where each motor has it's own scale, I presume you have to set up 2 axes and use gantrykins - or can this even be done?
[09:17:13] <jepler> with gantrykins I don't see why different motor scales would create any additional problems
[09:19:18] <skunkworks> from the memory wearhouse - homing is an issue if you have a position other than the home position set. one joint will take off to the postion even though the other joint isn't finished homing.
[09:19:46] <cradek> yeah homing is definitely the tricky part
[09:20:20] <seb_kuzminsky> skunkworks: that's true in theory but in practice it's not too bad
[09:21:00] <seb_kuzminsky> i have a gantry machine with dual motors drivign the gantry, it homes fine every time, even though the two homing joints don't wait for each other
[09:21:43] <cradek> I bet it's true you wouldn't want to rapid somewhere far away at the end of homing
[09:21:47] <skunkworks> sure - but you don't have a home position set. (say you want it to move to the center of the gantry after it is done..)
[09:21:49] <seb_kuzminsky> the gantry tolerates being a little bit out of true, the two joints share a HOME_SEQUENCE and use the same HOME_*_VELs
[09:22:00] <seb_kuzminsky> ah, yeah
[09:22:08] <skunkworks> I agree otherwise.
[09:22:22] <seb_kuzminsky> i put the home for my gantry near the home switches, that surely helps
[09:22:28] <skunkworks> sure
[09:22:44] <skunkworks> (that is what I would do..) But I know that issue has come up.
[09:22:46] <seb_kuzminsky> one of these... years, i'm going to pick up cradek's synchronized-home branch
[09:23:30] <seb_kuzminsky> which fixes the problem correctly, once and for all
[09:33:59] <skunkworks> that is exciting
[09:46:21] <jepler> ooh, cbmc can verify that a "sign-extend" routine works properly.
http://emergent.unpythonic.net/files/sandbox/verify_extend.c
[09:47:01] <jepler> of course, the version actually in linuxcnc pluto_servo.c turned out to be buggy :-P
[09:47:09] <skunkworks> oops
[09:47:11] <skunkworks> :)
[09:47:33] <skunkworks> is that why some had problems with the servo only moving one way?
[09:47:36] <jepler> no
[09:47:39] <jepler> that's something else
[09:47:43] <skunkworks> heh
[09:48:06] <jepler> I think the bug in question would only occur when going over 2^63 counts since power on
[09:48:16] <jepler> which is not at all likely
[09:54:43] <skunkworks> aww - that sucks.. cradek your back on with the oword douplicate issue. :)
[09:55:13] <cradek> arg
[09:55:47] <cradek> I hate that they have a bug tracker that doesn't let me see anything but the summary
[09:56:03] <cradek> and by me I mean everybody
[10:01:05] <skunkworks> darn
[10:01:20] <skunkworks> I am going down there this weekend.. I could ask. :)
[10:04:38] <jepler> it's amazing to me that there are efficient algorithms that do well at solving SAT instances that arise in program verification. Knowing that SAT is NP, you'd predict that it would be infeasible to verify even a small program like mine that way..
https://en.wikipedia.org/wiki/Boolean_satisfiability_problem#Algorithms_for_solving_SAT
[10:31:33] <seb_kuzminsky> skunkworks: that would be great, i think everyone would benefit if we were cooperating more closely
[11:05:03] <skunkworks> I suppose I could setup andys config on machinekit and then ask mah to fix it.. But he would probably yell at me.
[11:12:40] <mozmck> Oops, I had to go out shortly after asking my gantry question.
[11:13:27] <mozmck> Right now I'm using trivkins and connecting the axis position to two stepgens (7i92) running motors.
[11:14:36] <mozmck> I do see that each stepgen has a position-scale parameter, so I presume I could set them differently.
[11:15:10] <mozmck> Does the SCALE value for an axis get used in motion or another internal component?
[11:15:22] <jepler> mozmck: it only gets used in HAL
[11:15:51] <mozmck> Ah, then I should be able to set a different scale for each motor using trivkins. Thanks jepler.
[11:28:06] <mozmck> My ini file is going to look weird :) I made a config gui for our stuff, and it reads the ini instead of an xml file. I put in some custom values though. I think using a combination of custom INI values and HALTCL, I can make a config where you don't need to change the hal file at all - just the ini file.
[11:28:39] <jepler> haltcl should be the next big thing
[11:49:14] <jepler> hm does using haltcl break calibration, since it is all about parsing the .hal file to find out what inifile values are used and what hal command to execute to change them?
[11:50:18] <mozmck> I'm not sure I understand your question?
[11:50:29] <jepler> I'm not sure I stated my question well
[11:50:41] <mozmck> I'm not parsing the hal file at all the way I'm doing it.
[11:51:14] <jepler> we have a gui program "emccalib.tcl" aka Calibration
[11:51:30] <mozmck> oh, I didn't even know that.
[11:52:18] <mozmck> Hmm, I would think what I'm doing or thinking of would break anything parsing a hal file.
[11:53:02] <jepler> what it does is (I'm summarizing) grep the .hal files for "setp" lines that use the halcmd [SECTION]VAR syntax
[11:53:29] <jepler> each one it recognizes (or maybe just the ones where the sections are AXIS_x) it puts in the GUI so that it can be adjusted "live"
[11:53:43] <jepler> and optionally it can write the new tuned value back into the inifile
[11:54:03] <mozmck> I was thinking of using loops in haltcl, so you could have any number of axes and joints defined in the ini, and tcl could loop through and set up only as many as were defined in ini - along with other similar things.
[11:54:10] <jepler> anyway, this program emccalib.tcl knows about the halcmd syntax "setp pid.0.Pgain [AXIS_0].P" but it won't know about the .tcl syntax
[11:54:26] <jepler> er there's a stay dot in there but maybe my drift is still clear
[11:54:43] <mozmck> Hmm, yes, haltcl uses $::AXIS_0(P)
[11:55:23] <jepler> anyway, before we decided to change the shipped configuration files to use haltcl we'd need to make sure we aren't creating a big regression in how calibration works
[11:55:48] <mozmck> I haven't seen the emccalib.tcl - I need to look at that. I was thinking of making something like that which could be integrated into a gui, maybe it's already done.
[11:55:50] <jepler> this gui is accessible from inside axis, machine > calibration
[11:55:59] <mozmck> Oh, already done! neat.
[11:56:45] <pcw_home> Yeah its very handy for servo tuning
[11:57:01] <pcw_home> (or stepgen FF2 tuning)
[11:57:08] <jepler> maybe by the changes that introduced "hallib", I don't think calibration is looking in there to find hal files
[11:57:59] <mozmck> Yes, I'm sure it would need a lot of work and testing, and that would be done in a separate branch. My thought is that if everything could be done in the INI file, then configuration could be easier, and a configuration GUI can be easier I would think.
[11:58:12] <mozmck> I haven't followed hallib - what does it do?
[11:58:40] <jepler> I think it's just a search path for .hal files
[11:58:56] <mozmck> oh
[12:03:05] <jepler> it looks like the linuxcnc script searches a single additional directory for .hal files specified in the inifile. in a RIP install it is a path like /home/jepler/local/src/linuxcnc/lib/hallib
[12:03:14] <jepler> that directory gets .hal files that are used in more than one configuration file
[12:03:37] <jepler> and, yeah, this seems to have broken the calibration gui, booo
[12:04:19] <jepler> dgarr: if you're reading the logs, maybe you're willing to take a look at this?
[13:40:43] <dgarr> jepler:
http://www.panix.com/~dgarrett/stuff/hallib.txt
[13:45:24] <jepler> dgarr: I think I'd prefer to see emccalib.hal (and, now that I do some grepping, halconfig.tcl) learn about how to search HALLIB_PATH
[13:45:44] <jepler> dgarr: but I'm glad to know that only one configuration -- and a sim one at that -- that we ship is broken
[13:48:40] <dgarr> i think that shows how often tklinuxcnc/servo_sim.ini has been used
[13:51:44] <jepler> yes, that or calibration
[13:58:27] <dgarr> jepler: i will work on incorporating HALLIB_PATH into tcl/bin/emccalib.tcl unless you have already started on it
[15:17:58] <dgarr> jepler: well here is my way: (first patch in mbox is semi-related cleanup):
http://www.panix.com/~dgarrett/stuff/27jul15.mbox
[15:19:47] <seb_kuzminsky> awesome
[15:20:03] <seb_kuzminsky> does that make emccalib work on the sim servo config?
[15:32:30] <dgarr> i think so, i just fixed an oversight in the patch and tested
[15:33:04] <seb_kuzminsky> great
[16:08:37] <jepler> dgarr: I haven't started coding. thank you, I'll have a glance at your patch
[16:22:30] <andypugh> Has anyone investigated any further into the spurious duplicate O-word?
[16:24:02] <cradek> I spent half a day on it but didn't get anywhere. I don't think anyone else has looked at it.
[16:24:31] <andypugh> Half a day sounds like it’s not a trivial thing to find?
[16:24:44] <cradek> well it wasn't for me
[16:25:03] <andypugh> I guess it is a job for debuggers and other such stuff that I have never used?
[16:25:04] <seb_kuzminsky> i moved the remap config to 2.6 and made it into a smaller runtest-able... test
[16:25:37] <andypugh> The config should work anywhere that remapping is possible.
[16:26:02] <cradek> it's specific to mdi?
[16:26:10] <andypugh> Yes, it seems to be
[16:26:19] <cradek> ok, that's a good clue that I didn't have at the time
[16:26:32] <cradek> gotta run, bbl
[16:26:37] <seb_kuzminsky> seeya
[16:26:41] <andypugh> Not the only one, either. There is a similar thing with someone elses variant of lathe-fanucy
[16:27:33] <andypugh> Well, actually the symptoms are quite different, but it is once-only and MDI only
[16:28:40] <andypugh> http://www.linuxcnc.org/index.php/english/forum/20-g-code/29271-tool-offset#59712
[16:35:24] <andypugh> DIY Ethernet IO board (fairly cool)
http://pekka.eu/cnc/
[16:41:51] <seb_kuzminsky> andypugh: neat
[16:43:02] <seb_kuzminsky> haha:
[16:43:04] <seb_kuzminsky> Currently the board and software are in the state where my projects usually end. That is, they work, but they are not pretty. :)
[16:43:49] <seb_kuzminsky> he's got a 500-600 us thread time :-(
[16:53:25] <PCW> With Preempt-RT, thread time is somewhat host dependent (dont know how much overhead his ucontroller stack has)
[16:55:59] <PCW> Also, a 500 Hz servo thread is probably OK for a lot of step/dir machines if you dont need very high accel or high precision
[17:17:54] <andypugh> My impression was that there were on-board stepgens. Perhaps I misunderstood?
[17:19:05] <PCW> the stepgens still need a servo thread
[17:22:13] <PCW> that is a 500 Hz update rate is acceptable with a Mhz stepgen as long as you dont have very high acceleration
[17:28:19] <jepler> ah, I see his design needs a lot of round trips
[17:28:56] <jepler> er, no, that's not it
[17:31:46] <PCW> might be using a generic network stack on the STM32 which would likely be slow
[18:03:40] <jepler> who the hell thought it was a good idea to use SD cards to store operating system images? I can feel my beard hairs turning gray as I wait for it to install packages
[18:10:13] <jepler> .. I think this sandisk-branded "class 10" sdhc is slower than the off-brand one that failed after 2 months, too
[18:18:47] <jepler> aaaannnd now I know for sure I lost some un-pushed code from the failed sd card, boo. (nothing linuxcnc related, another personal project using a pi2)
[18:31:38] <seb_kuzminsky> lol @ jeplers beard hairs
[18:33:12] <jepler> oh look another qemu "pwn via virtualized device" bug.
https://access.redhat.com/security/cve/CVE-2015-5154
[18:35:00] <seb_kuzminsky> virtual cdroms are only slightly less silly than virtual floppy disks
[18:40:11] <jepler> [ 1.020389] ata2.00: ATAPI: QEMU DVD-ROM, 1.0, max UDMA/100
[18:40:32] <jepler> ^^^ dmesg on my favorite virtual hosting provider
[19:23:18] <dgarr> jepler: seb_kuzminsky: i improved the patch to find halfiles using a hallib proc so it works the same with emccalib.tcl and xhc-hb04.tcl:
http://www.panix.com/~dgarrett/stuff/27jul15.mbox, earlier version is named 27jul15_obsolete.mbox
[20:09:24] <jepler> dgarr: I agree with using a proc to find the real path
[20:10:18] <skunkworks> so - why when you run this -
http://pastebin.com/GJpsCA3W
[20:10:33] <skunkworks> the first thing it does is the G53 g0 x0 y0?
[20:10:41] * skunkworks is so confused
[20:15:03] <jepler> skunkworks: g53 g0 x0 y0 z0 seems like a pretty dubious thing to do, whether first thing or not, in some sort of canned cycle / feature generator
[20:25:50] <skunkworks> it seems to do the g53 line then back though and does the threading
[20:44:50] <jepler> OK, so "halconfig.tcl" is the one that has been broken 10 years. somebody should remove it
[20:46:07] <jepler> dgarr: verified your patch fixes calibration, and that "halconfig.tcl" is broken in 2.6 (and probably long before) so it doesn't matter if it's broken in 2.7 / master
[20:59:27] <jepler> (that's the other place that looked like it was finding hal files from the inifile)
[21:01:34] <jepler> dgarr: thanks
[21:09:57] <skunkworks> ok - never mind. it is the tool change position...
[21:10:19] <skunkworks> duh