Back
[00:32:28] ChanServ changed topic of
#linuxcnc-devel to:
http://linuxcnc.org | Latest releases: 2.7.0 and 2.6.10 | (this channel is logged by the zlog robot)
[00:41:22] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 6a6ce0e 06linuxcnc 10debian/changelog 10src/emc/task/emctaskmain.cc Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6a6ce0e
[07:09:21] <arrowbook> hi, how's the servo motor drived? also by stepgen?
[07:33:40] <AndroUser> micges,
[07:35:07] <micges> yes?
[07:35:54] <manner> sorry,nothing
[08:08:17] <KGB-linuxcnc> 05dgarr/xhc_fixes 3670375 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3670375
[08:28:38] <jepler> no, stepgen is not used for servo motors. for servo motors, generally PID, pwm, and encoder are used. preferably, the pwm and encoder are in a supported fpga card but there are software versions that can work for encoder rates up to 10kHz or so depending on your PC's realtime performance.
[08:39:24] <arrowcnc_> thanks
[08:56:57] <KGB-linuxcnc> 03Dewey Garrett 052.7 f59ad44 06linuxcnc 10lib/hallib/xhc-hb04.tcl xhc-hb04.tcl: support twopass usage * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f59ad44
[08:56:57] <KGB-linuxcnc> 03Dewey Garrett 052.7 417337e 06linuxcnc 10src/hal/components/xhc_hb04_util.comp xhc_hb04_util.comp: update man page text * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=417337e
[08:56:57] <KGB-linuxcnc> 03Dewey Garrett 052.7 2614ff4 06linuxcnc 10src/hal/components/xhc_hb04_util.comp xhc-hb04_util.comp: fix output scaling * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2614ff4
[10:22:34] <seb_kuzminsky> thanks dgarr
[12:06:34] <KGB-linuxcnc> 03Norbert Schechner 052.6 318a848 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_5_5_2 - bug in tool info handling with tool number being "-1" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=318a848
[12:07:11] <KGB-linuxcnc> 03Norbert Schechner 052.7 08e00af 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_5_5_2 - bug in handling tool info with tool being "-1" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=08e00af
[12:07:11] <KGB-linuxcnc> 03Norbert Schechner 052.7 664c282 06linuxcnc Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=664c282
[12:11:59] <norbert__> I just pushed some changes from gmoccapy to 2.6, than merged 2.6 to 2.7 and than I tried to merge 2.7 to master, to get the gmoccapy changes also to master, but I run into conflicts. Could someone please take a look?
[12:16:27] <seb_kuzminsky> norbert__: i'll take care of the merge from 2.7 to master
[12:16:36] <seb_kuzminsky> thanks for the m61 bug report too, btw
[12:21:00] <norbert__> #<seb_kuzminsky>Thanks!
[13:35:10] <pcw_home> hmm since the servo thread on uspace machines is synchronized to ntp time
[13:35:11] <pcw_home> does that mean that you could synchronize multiple machine on a local net to within a servo thread tic or so?
[13:36:12] <archivist> might get race conditions, how often to the sync to ntp and which way are they drifting
[13:37:37] <archivist> PCW, did you see that comment next door, about grabbing encoder/scale readings on a trigger from a probe ?
[13:38:01] <pcw_home> Just reading that ntp on a local net can be within a ms or so
[13:38:33] <archivist> I suppose having a local time server makes sense
[13:39:23] <pcw_home> archivist: no, I did not see the probe comment
[13:40:03] <archivist> if the fpga had a trigger input in order to grab current counts, may be better for a CMM
[13:40:34] <pcw_home> it does (for several years) but theres no current driver support
[13:41:34] <pcw_home> basically a single input latches all counts ( on latch-on-probe enabled channels )
[13:41:54] <pcw_home> also works with the stepgen
[13:43:01] <archivist> I am tending to hate the windows software on this toy, and a retrofit would be entertaining
[13:43:35] <pcw_home> what windows version?
[13:43:46] <archivist> PC-DMIS 3.2
[13:43:52] <archivist> XP
[13:44:06] <pcw_home> so not too ancient
[13:44:26] <pcw_home> what moves the axis?
[13:44:26] <archivist> the error handling is terrible though
[13:44:40] <pcw_home> error handling is always tough
[13:44:41] <archivist> it has small servos and scales
[13:45:16] <archivist> so small that it has therr L298 drivers
[13:45:21] <archivist> three
[13:45:43] <pcw_home> yeah, just need to move the probe around
[13:46:36] <archivist> Z has to do a little more, must take the Z cover off to see if it has a balance weight
[13:47:40] <pcw_home> ball screws?
[13:48:11] <archivist> no it has friction roller drive to a rod
[13:50:28] <archivist> rod coming out the middle of the tube
http://www.collection.archivist.info/archive/mirror/brown_sharpe/11.JPG
[13:51:23] <archivist> the bit to the left past the mounting is the spring roller clamping part
[13:56:29] <pcw_home> I guess with linear scales an accurate drive is not required ( and a friction drive probably has lower backlash than a ballscrew )
[13:58:14] <archivist> I just need to scope the scale signals before I decide which way to go I think
[14:09:38] <linuxcnc-build> build #104 of 1502.rip-jessie-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1502.rip-jessie-amd64/builds/104 blamelist: Norbert Schechner <nieson@web.de>
[14:18:33] <linuxcnc-build> build #3490 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3490 blamelist: Norbert Schechner <nieson@web.de>
[15:38:41] <seb_kuzminsky> what tool number means "no tool" or "unknown tool" on a nonrandom tool changer? I think it's "0", since that's what IO sets its .tool-number to at startup, and it's what you find in stat->io.tool.toolInSpindle after running "T0 M6"
[15:39:42] <seb_kuzminsky> but there's an explicit check in io's load_tool() to set it to -1
[15:40:05] <seb_kuzminsky> http://www.quickmeme.com/img/f3/f3e36114d4cac4576c9bf357b231cb308d9a3952ec4bdad48b510f4a878396c4.jpg
[15:40:31] <seb_kuzminsky> this branch sets it to 0, and makes things behave as i think they should:
[15:41:02] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6-m61-bug 97c1e23 06linuxcnc 10tests/toolchanger/m61/test-ui.py tests: better diagnostic output in m61 test * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=97c1e23
[15:41:02] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6-m61-bug 7aa30ee 06linuxcnc 10tests/toolchanger/m61/test-ui.py tests: factor out current-tool verification in m61 test * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7aa30ee
[15:41:02] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6-m61-bug 7372dd0 06linuxcnc 10tests/toolchanger/m61/test-ui.py tests: include the iocontrol.tool-number pin in the tool verification * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7372dd0
[15:41:04] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6-m61-bug 5c1053a 06linuxcnc 10tests/toolchanger/m61/test-ui.py tests: factor out the M6 toolchange HAL handshake, for future reuse * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5c1053a
[15:41:08] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6-m61-bug 9b55dbe 06linuxcnc 10tests/toolchanger/m61/test-ui.py tests: add spindle unloading to m61 test * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9b55dbe
[15:41:12] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6-m61-bug d34c4c4 06linuxcnc 10src/emc/iotask/ioControl.cc io: fix HAL pins on "M61 Q0" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d34c4c4
[15:41:16] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6-m61-bug d1d665b 06linuxcnc 10src/emc/iotask/ioControl.cc io: "no tool" is spelled "0", not "-1" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d1d665b
[15:41:20] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6-m61-bug faa5e07 06linuxcnc 10docs/src/code/Code_Notes.txt docs: update code notes on M61 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=faa5e07
[18:58:30] <skunksleep> I recall Jeff maybe trying to get probing working at the driver level but ran into issues
[18:59:30] <pcw_home> Yeah the hardware is easy, supporting it, not so easy
[19:02:14] <pcw_home> Actually I would like to rework the index logic so it always latches the count on index and uses the latched count as an encoder sanity check
[20:10:16] <jepler> yes, it's been years since when cradek and I tried to use a latched position for the result of probing
[20:11:02] <jepler> for one thing, once we read the datasheet on his wireless probe and learned it had 20ms latency, trying to remove 1ms latency from the equation seemed less important..
[20:11:37] <jepler> but we also seemed to be hitting some bug in task or motion or both and we didn't really characterize it or chase it down at the time, we just were baffled
[20:31:33] <pcw_home> It might make sense for mechanical contact probes that are fast (or even to take out the servo period uncertainty since the 20 ms is presumable constant)
[21:01:22] <jepler> it's true, removing a varying delay would still be good. for hole center finding, a fixed delay doesn't affect accuracy in the slightest.
[21:02:55] <pcw_home> yeah I guess it cancels out
[21:20:38] <micges> pcw_home: what compiler you used to make your mesa dos tools?
[21:40:52] <pcw_home> Either Turbo pascal 7.0 or FreePascal
[22:04:25] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 db3f8d7 06linuxcnc 10src/emc/task/emctaskmain.cc task: heartbeat is uint32 in 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=db3f8d7
[22:10:12] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7-tom-easterday-gs2 fc8f74b 06linuxcnc 10src/hal/user_comps/gs2_vfd.c Added an initialize option to gs2_vfd.c so it can be initialized at will. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fc8f74b
[22:10:13] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7-tom-easterday-gs2 64c7909 06linuxcnc 10src/hal/user_comps/gs2_vfd.c gs2 code review updates * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=64c7909
