Back
[03:00:43] <KGB-linuxcnc> 03Francis Tisserant 05seb/master/po4a c3a6c0d 06linuxcnc 03docs/src/common/User_Concepts.fr.po 10docs/src/common/User_Concepts.txt 10docs/src/common/User_Concepts_fr.txt French doc adaptation to po4a * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c3a6c0d
[08:09:49] <skunkworks> pcw_home, so glad that the 5i25/6i25 was used by tormach. Congrats!
[08:10:23] <skunkworks> (no wonder why you have been so busy over the last few months..)
[08:29:52] <mozmck> skunkworks: does tormach really sell that many machines?
[08:30:04] <skunkworks> they must..
[08:30:53] <mozmck> interesting.
[08:31:38] <skunkworks> seems they are selling the upgrade kit for the price of hardware...
[08:31:51] <mozmck> Yes, that is what it looked like.
[08:32:35] <skunkworks> my thought is they are probably weighing the support costs of mach vs linuxcnc
[08:33:23] <mozmck> yes, and the uncertainty of mach4, and you still can't just go in and fix or change something.
[08:34:08] <skunkworks> right
[08:34:09] <mozmck> I think Andreas picked a fitting nick on youtube :)
[08:34:24] <archivist> and the hardware mach relies on is all propriety too where mesa is very friendly
[08:34:25] <skunkworks> I have not read the comments
[08:34:47] <mozmck> Moronicsmurf
[08:37:33] <mozmck> archivist: true, and I'm not sure Mach4 can do the same level of control yet as linuxcnc with mesa. Mach3 does not have realtime communication with any of the external hardware.
[08:38:26] <mozmck> which means that boards like the SmoothStepper (USB and Ethernet) have to do homing in the hardware, and numbers of other things.
[08:38:54] <archivist> the ability to gear axes is far ahead of anything that they can do too
[08:48:20] <skunkworks> and any new mach bells and whistle need to be added to the hardware... vs linuxcnc - any new things ie rigid tapping are available to all hardware.
[08:50:19] <mozmck> Yes, I'm painfully aware of that with Mach3 :) I don't know if Mach4 is any better in that regard either.
[08:52:42] <mozmck> If Tormach developed their own GUI, then it's quite possible that it does not have to be made open source I think.
[09:02:01] <skunkworks> if anything - from what I have read is is worse.. Relying on external motion devices more
[09:02:56] <skunkworks> (mach4)
[09:03:39] <skunkworks> and from some un-named people - the trajectory planner is exactly the same as mach3..
[09:03:52] <archivist> if the rats are now leaving that sinking ship, I wonder what will happen to it
[09:21:46] <CaptHindsight> it runs on winders, they will still get all that business
[09:23:04] <skunkworks> kwallace_shop1, great work..
https://www.youtube.com/watch?v=VFSy0RoFyGM
[09:27:19] <archivist> I think since win8 lots of escapees
[09:36:59] <seb_kuzminsky> mozmck: i'm not sure if that's true about the gui, i'd have to look at the licensing for our ui nml code
[09:41:44] <mozmck> ah, the library?
[09:41:50] <mozmck> didn't think of that.
[09:42:04] <mozmck> HAL allows closed source components
[09:45:04] <micges> seb_kuzminsky: nml.hh and rcs.hh both got LGPL
[09:46:30] <seb_kuzminsky> i think there's a mixture of gpl and lgpl in the code-pile (i won't call it a library!) that the UIs use to talk to Task
[09:46:47] <micges> but emc.hh and emc_nml.hh have GPL
[09:47:06] <seb_kuzminsky> looks like they use gremlin too, which is gpl
[09:48:23] <micges> yeah code-pile is a good description ;)
[09:48:29] <mozmck> heh!
[09:53:22] <KGB-linuxcnc> 03Bence Kovacs 052.6 24c590b 06linuxcnc 10src/hal/drivers/hal_gm.c Fix RS485 DAC problem, when DAC has zero V output. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=24c590b
[09:56:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 55e235b 06linuxcnc Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=55e235b
[09:56:01] <KGB-linuxcnc> 03Bence Kovacs 052.7 ee8908a 06linuxcnc 10src/Makefile 10src/hal/drivers/gm.h 10src/hal/drivers/hal_gm.c Add USPACE support * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ee8908a
[09:56:01] <KGB-linuxcnc> 03Bence Kovacs 052.7 7f43591 06linuxcnc 10src/hal/drivers/hal_gm.c License changed, because some function required it under Ubuntu * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7f43591
[09:58:30] <seb_kuzminsky> btw, jepler and i started cleaning up the ui interface code, in the branch called liblinuxcnc-ui
[09:58:42] <seb_kuzminsky> once 2.7 settles down i hope to pick that work up again
[09:59:18] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 5718f6f 06linuxcnc Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5718f6f
[10:02:02] <seb_kuzminsky> bbl
[12:25:46] <skunkworks> pcw_home, what came first? tormach or the 5i25?
[12:26:32] <pcw_home> umm Tormach was in business before we made the 5I25
[12:27:16] <skunkworks> heh - I mean did tormach want a db25 solution and you made it?
[12:29:38] <pcw_home> Yes I think they suggested it
[12:30:17] <skunkworks> (now that I think about the converstaions with tormach at their fest - A lot of things are clearerer..) :)
[12:30:36] <pcw_home> clearererer?
[12:31:00] <skunkworks> I think it is a awesome idea - it allows people to 'upgrade' pretty easy (using their existing bobs) with a ton of future expandabillity
[12:31:12] <skunkworks> exactly
[12:31:13] <pcw_home> (PCW found a new old M keyboard under the house)
[12:31:24] <skunkworks> wow - does it work?
[12:31:36] <skunkworks> I bet chris would buy it from you :)
[12:31:48] <skunkworks> well - he probably has dozens..
[12:32:02] <pcw_home> much better than the one I spilled 1/2 cup of coffe on
[12:32:09] <skunkworks> oops
[12:32:22] <pcw_home> may have spiders though
[12:37:21] <Connor> I'm betting Tormach wishes they didn't have "Mach" in their name.. :)
[12:37:43] <pcw_home> :-)
[12:43:04] <Connor> I love that they made the switch away from Mach. Still a few die-hard fans of Mach out there.. saying "it works great for them" etc..
[12:43:15] <Connor> I loath the idea of Windows running my CNC machines.
[12:43:48] <pcw_home> Yeah
[12:44:06] <Connor> pcw_home: Congrats on them choosing Mesa BTW
[12:44:35] <Connor> So, Did they help bring 5i25 6i25 into existence ?
[12:44:43] <pcw_home> Thanks Good to have some linuxcnc OEMs
[12:45:17] <pcw_home> Well I think they suggested making a DB25 FPGA card
[12:45:44] <Connor> I.E. The Super Port! :)
[12:46:22] <pcw_home> well that was my silly name
[12:46:35] <Connor> Not silly.
[12:52:21] <seb_kuzminsky> yeah, congrats peter, that's got to be good for mesa :-)
[12:57:45] <micges> next version should be 'Uber Port' ;)
[12:59:11] <pcw_home> Yeah its first larger linuxcnc OEM
[12:59:41] <pcw_home> there are some small ones also
[12:59:47] <Connor> I swear someone on the IRC was working on the new GUI...
[13:10:34] <skunkworks> there are a few newer gui's.. gscreen, gmoccapy
[13:17:36] <ssi> the superport stuff really is nice
[13:17:59] <ssi> simplifies wiring, better physical separation of PC from control hardware
[13:18:23] <ssi> the fact that the host cards are cheaper is due more to the removal of the pci bridge than the superport, but it's a nice side benefit
[13:25:21] <PCW> also smaller card size helps
[13:26:55] <ssi> yeah definitely... most of the cheap pcs I get for linuxcnc machines are low profile, and the 5/6i25 is a great solution
[13:28:07] <PCW> hoping the Ethernet stuff will eventually make the I/O CPU agnostic
[13:47:29] <kwallace_shop1> Conner, Daniel Rogge is the main force behind the Tormach UI. He doesn't hang out here often, but he will be talking about the software tomorrow in a webinar:
http://www.tormach.com/pathpilot . I missed the webinar bit until I scrolled to the bottom of the page.
[13:48:27] <kwallace_shop1> Oops, not the bottom but down a little.
[14:04:31] <seb_kuzminsky> kwallace_shop1: that'll be interesting to see
[14:08:48] <Connor> kwallace_shop1: Yea, the UI and wizards aspect are allot of what people are looking for.
[15:02:36] <KGB-linuxcnc> 03Robert W. Ellenberg 052.7 ba0c8fd 06linuxcnc 10src/emc/motion/command.c 10src/emc/tp/tp.c 10src/emc/tp/tp_types.h motion: fix for zero-length line errors * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ba0c8fd
[15:02:36] <KGB-linuxcnc> 03Robert W. Ellenberg 052.7 22ac5d9 06linuxcnc 10(5 files) tp: Added optimizations to increase arc tangential acceleration * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=22ac5d9
[15:02:36] <KGB-linuxcnc> 03Robert W. Ellenberg 052.7 feab885 06linuxcnc 10src/libnml/posemath/posemath.cc posemath: fixed PM_CARTESIAN cross product * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=feab885
[15:02:37] <KGB-linuxcnc> 03Robert W. Ellenberg 052.7 3122c02 06linuxcnc 10src/emc/tp/blendmath.c tp: fix for rare acceleration violation that that Sam found * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3122c02
[15:02:41] <KGB-linuxcnc> 03Robert W. Ellenberg 052.7 752b044 06linuxcnc 10tests/trajectory-planner/circular-arcs/configs/sim_XYZ.ini 10tests/trajectory-planner/circular-arcs/configs/sim_XYZ_fast.ini tests: increased optimization depth in fast sim config * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=752b044
[15:14:34] <seb_kuzminsky> sweet!
[15:14:49] <seb_kuzminsky> rob ellenberg pushed to our 2.7 branch himself :-)
[15:15:33] <seb_kuzminsky> aw, but he didn't fix the indentation errors i had pointed out to him :-/
[16:25:42] <seb_kuzminsky> ~
[16:38:38] <PCW> hmm 3.18.7-rt1 preemt-rt seems ok...
[16:40:32] <seb_kuzminsky> did you build it or did the debian kernel folks?
[16:41:13] <PCW> built myself (didnt even change the config)
[16:41:48] <PCW> (the rt patch makes a sensible config)
[16:42:02] <seb_kuzminsky> cool
[16:42:23] <PCW> make make module_install make install
[16:43:09] <PCW> seem better Ethernet latency wise but need a day or so at 4KHz to see
[16:43:22] <PCW> seems
[16:49:26] <PCW> forgot about the initrd stuff and looked all around about how to do it in a way i could understand, then turns out make install does everything
[17:19:06] <mozmck> oh, neat. that patch is brand new
[17:19:37] <mozmck> it seems better than what? the 3.14 preemt-rt or wheezy?
[17:21:51] <PCW> wheezy is the only other rt kernel I have tried on this system
[17:24:33] <mozmck> ok
[17:25:50] <PCW> kernel compiling +youtube videos dont seem to phase it but do mess with 3.2
[17:32:20] <mozmck> I see, that sounds like pretty good improvement. 3.2 is pretty old now - in software years anyhow.
[18:06:02] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/histo ade20d8 06linuxcnc 03lib/hallib/hal_procs_lib.tcl 10lib/hallib/hookup_moveoff.tcl 10lib/hallib/xhc-hb04.tcl 10scripts/moveoff_gui hal_procs_lib.tcl: consolidate common procs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ade20d8
[18:06:02] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/histo 41bb2d8 06linuxcnc 10(6 files in 3 dirs) hal-histogram: histogram util for s32,float pins * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=41bb2d8
[18:08:11] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/histo ca4a454 06linuxcnc 10(7 files in 4 dirs) hal-histogram: histogram util for s32,float pins * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ca4a454
[19:03:57] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 07a502b 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis gui: rename joint_mode to teleop_mode * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=07a502b
[19:03:57] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 1e55ddf 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis gui: fix teleop jog speeds * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1e55ddf
[19:03:57] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 98556aa 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis gui: fix jog speed in Free mode * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=98556aa
[19:04:08] <KGB-linuxcnc> 05seb/2.6/axis-jog-speed 48ee6b0 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=48ee6b0
[19:04:51] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 4c2ec15 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4c2ec15
[19:57:59] <wortley> I have a question about updates to the state data structure and when those would get shared with another component. Specifically, if I set a bit in one component in the servo thread, and it get's pre-empted by something int the base thread, will that bit have been published and passed through the net as input to all of the base thread functions yet? When does the data passing occur?
[19:59:42] <wortley> I could see an architecture where that data passing is handled in a base thread creature explicitly before passing control to the base thread kids, and the bit data gets published. I could also see an architecture where that is the last thing that happens after a component exits.
[19:59:56] <wortley> Which is PROBABLY the easier thing to do.
[20:00:32] <wortley> Which could be great too -- because that means that if I update pins within a function they could all come out as a snapshot.
[20:01:07] <wortley> Anyone know how that works?
[20:08:32] <micges> pins are pointers and hal read/write are atomic operations so after write in one component it will be available to all component using it, in all threads
[20:10:09] <cradek> I agree with micges's answer, but I'm not sure I understood all of your question
[20:10:43] <wortley> The variable does not live in the component then? How does directionality get enforced? When hal parses the file to tie the pointers together?
[20:10:45] <cradek> there is no "published" step because all the pins just point to the same place in shared memory. as soon as the write is done, it's available everywhere to be read
[20:11:03] <wortley> Ok -- That's good.
[20:11:34] <wortley> So if I write a "lock" pin, the pre-empting function will know it right away.
[20:12:08] <cradek> yes a faster thread can interrupt a slower one, and if they have pins netted together it will see the latest state immediately
[20:14:12] <wortley> So that is why the __comp_state struct contain pointer...
[20:14:56] <wortley> or contains pointers, as people with english as their first language would say :)
[20:16:41] <wortley> Is it safe to leave out all the #undef TRUE junk?
[20:16:57] <cradek> ??
[20:17:59] <wortley> The component generator has some #defines that remove all possible definitins of TRUE true FALSE and false so they are guarunteed to be 1 and 0 respectively.
[20:26:58] <PCW> 3.18.7-rt1 seems quite a bit better than Wheezy stock 3.2 preemt-rt :-)
[20:26:59] <PCW> at least after 3 hours of youtube videos+kernel compiling I cant trip up hm2_eth at 4KHz
[20:29:06] <PCW> also learned there are 9 hour youtube videos
[20:40:23] <mozmck> very nice!
[20:48:25] <wortley> Is servo thread pre-emption really very common? It seems that since it executes rarely (in comparison to base thread), that execution might be something like 50 passes through the base thread, and then 1 pass through the servo thread.
[20:49:03] <wortley> If the servo thread is really big, it could take a few base thread passes.. Is that true?
[20:49:37] <wortley> I'm just trying to make sure that if I lock a data structure in my base thread, it isn't locked for more than a pass or two, not a full millisecond.
[20:51:20] <wortley> of if I lock it in the servo thread that 50 base thread passes don't have to wait another ms for it to complete .... Sorry for thinking aloud.
[21:01:41] <wortley> Is there a directive I can put into my hal code for a component that can prevent a sensitive block of it from being pre-empted? Like some sort of RT_API_LET_ME_FINISH. and then RT_API_AS_YOU_WERE?
[21:02:23] <wortley> It would sure save passing around a lot of locks.
[21:26:23] <seb_kuzminsky> wortley: no, slower threads can not block quicker threads from pre-empting them
[21:26:39] <seb_kuzminsky> if they could, it would mess up (for example) step generation, which happens in the base thread
[21:28:16] <seb_kuzminsky> PCW: that's great news about the new rt-preempt kernel
[21:28:46] <seb_kuzminsky> i'd be really excited if debian (or someone) was still publishing debs for it
[21:54:26] <pcw_home> trivial to make though
[22:08:56] <cradek> your questions make me wonder whether you've chosen the right way to split your task into multiple threads, including whether it should be split at all
[22:09:31] <cradek> perhaps explaining more about what you are trying to do would help us think about better answers
[22:32:41] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 7a6ff9e 06linuxcnc 10VERSION 10debian/changelog LinuxCNC 2.7.0~pre3 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7a6ff9e
[22:32:41] <KGB-linuxcnc> 03Sebastian Kuzminsky 05signed tags 41cc1b7 06linuxcnc 03v2.7.0-pre3 LinuxCNC v2.7.0-pre3 (tagged commit: 7a6ff9e) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=41cc1b7
[23:05:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 2e1b358 06linuxcnc 10VERSION 10debian/changelog LinuxCNC 2.6.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2e1b358
[23:05:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 05signed tags 21fd88d 06linuxcnc 03v2.6.6 LinuxCNC v2.6.6 (tagged commit: 2e1b358) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=21fd88d