Back
[09:15:48] <mozmck> cmorley: thanks for reviewing and merging that.
[09:16:30] <mozmck> I can delete that branch to help keep things clean now unless you think it should stay around.
[10:49:45] <seb_kuzminsky> that test failure above is another race in the halui test, not related to the gscreen fix that mozmck and cmorley pushed
[11:09:55] <skunkworks_> that should be fixed.
[11:10:10] <skunkworks_> :)
[11:26:19] <seb_kuzminsky> yeah, someone should fix that
[11:26:51] <seb_kuzminsky> it's actually kind of a deep and interesting design issue
[11:27:23] <seb_kuzminsky> we have a bunch of moving parts (UIs, Task, motion) connected by strange IPC mechanisms with poor synchronization
[11:30:29] <pcw_home> How do you tell that its a buildbot issue? (If that can be determined easily maybe a "sorry, the buildbot messed up" message could be sent)
[11:31:15] <seb_kuzminsky> it's not a buildbot issue, it's a linuxcnc issue exposed by the unusual timing characteristics of the buildbot
[11:31:33] <seb_kuzminsky> the issue could absolutely happen anywhere, if you just got lucky/unlucky
[11:32:09] <pcw_home> ahh
[11:38:53] <skunkworks_> I think what rick did looks right..
[11:39:13] <skunkworks_> am I missing something? I bet he isn't picking the RT kernel from grub on boot.
[11:41:46] <pcw_home> Yeah (and maybe his MAC is disabled in the BIOS)
[11:42:29] <pcw_home> not finding Ethernet hardware is odd
[11:45:38] <skunkworks_> unless it is some wierd nic that the kernel doesn't recognize..
[11:45:42] <pcw_home> When I build and install a new preemt-rt kernel with make install
[11:45:43] <pcw_home> it becomes the default (maybe the package install does no do this)
[11:45:57] <skunkworks_> the package doesn't
[11:46:03] <skunkworks_> for whatever reason
[11:46:13] <pcw_home> Ahh
[11:49:06] <pcw_home> I asked about the MB to see what MAC it uses
[12:01:05] <pcw_home> the $39 dc7800 with preemt-rt and upgraded to a e8500 CPU seems to be fine with hm2_eth at 4 KHz and normal youtube/browsing etc
[12:02:49] <pcw_home> I hope Rick doesn't have some weird MAC thats troublesome
[12:31:21] <pcw_home> arghh Atheros :-(
[12:36:04] <skunkworks_> I am hoping the -rt kernel will see it...
[13:30:06] <skunkworks_> http://www.tormach.com/blog/pathpilot-moves-out-of-beta/?utm_source=blog&utm_medium=email&utm_campaign=postnotify&utm_id=5483&utm_title=PathPilot+Moves+Out+of+Beta
[13:32:44] <cradek> Mill - Interpreter: G50 and G80 should be allowed on same line
[13:32:48] <cradek> wonder what G50 is
[13:34:17] <skunkworks_> scaling?
[13:34:44] <skunkworks_> http://machmotion.com/cnc-info/g-code.html#G50_&_G51_Scale_Factor
[13:36:31] <skunkworks_> I wonder if scaling is implimented or they just allow G50 for backward compatibility
[13:38:06] <cradek> or the bug report is just mistaken and G50 isn't allowed
[13:38:20] <cradek> unfortunately I can't see inside the bug reports for details
[13:41:31] <skunkworks_> G50 doesn't show up in the pathpilot menu
[13:41:39] <skunkworks_> *manual
[13:48:24] <kwallace2> # much existing Mach3 g-code has G50 to reset scaling
[13:48:24] <kwallace2> # implement G50 here to prevent error and also cancel rotation
[13:48:24] <kwallace2> def g500(self, **words):
[13:48:24] <kwallace2> if self.task == 0: return INTERP_OK
[13:48:24] <kwallace2> print('remapped g50: G10 L2 P0 R0 to cancel current coordinate system rotation')
[13:48:25] <kwallace2> self.execute('G10 L2 P0 R0')
[13:48:25] <kwallace2> return INTERP_OK
[13:54:54] <cradek> interesting
[13:54:55] <cradek> thanks
[13:55:24] <cradek> it would be somewhat harder to really implement scaling
[13:57:32] <kwallace2> I have no idea. I tend to think CAM might do it.
[13:57:40] <cradek> yeah
[14:01:40] <cradek> haha you can have a different scale on different axes but then arcs are "not permitted"
[14:05:22] <skunkworks_> another gcode implimented in mach that wasn't really well thought tou
[14:05:23] <skunkworks_> out
[14:09:55] <cradek> implementing G50 in linuxcnc (not remap) would be pretty easy...
[14:15:11] <kwallace2> How easy is it to add a tpAddLine instead of tpAbort as in:
[14:15:15] <kwallace2> if (emcmotStatus->probing) {
[14:15:15] <kwallace2> /* check if the probe has been tripped */
[14:15:15] <kwallace2> if (!ignore_probe && (emcmotStatus->probeVal ^ probe_whenclears)) {
[14:15:15] <kwallace2> /* remember the current position */
[14:15:15] <kwallace2> emcmotStatus->probedPos = emcmotStatus->carte_pos_fb;
[14:15:16] <kwallace2> /* stop! */
[14:15:16] <kwallace2> emcmotStatus->probing = 0;
[14:15:17] <kwallace2> emcmotStatus->probeTripped = 1;
[14:15:17] <kwallace2> //tpAbort(&emcmotDebug->tp);
[14:17:24] <skunkworks_> cradek, scaling would be easy?
[14:17:27] <kwallace2> Crud, actually I don't want to add a line, I want to continue the path for say .020" then abort.
[14:18:02] <cradek> skunkworks_: no, just G50 for compatibility (turn off scaling) would be easy
[14:18:11] <skunkworks_> ah - ok
[14:19:58] <cradek> kwallace2: the old old ngc standard promised after probing the probe would be backed off
[14:20:15] <cradek> kwallace2: (I don't think continuing forward is a good idea at all)
[14:21:44] <cradek> > If the probe trips, the probe is retracted slightly from the trip point at the end of command execution. If the probe does not trip even after overshooting the programmed point slightly, an error is signalled.
[14:22:42] <cradek> the overshoot "slightly" promise is very weird
[14:23:05] <cradek> I'd sure ignore that
[14:23:42] <cradek> but it'd be worth considering auto-retract-after-probe functionality
[14:24:43] <cradek> task already knows that after probing the ending position is undefined and needs to be synced, so I don't think it would be too hard to add
[14:27:03] <cradek> http://www.linuxcnc.org/docs/html/gcode/rs274ngc.html
[14:27:18] <cradek> for years we've warned that the retraction could be added
[15:08:01] <kwallace2> cradek, the problem I'm having is with slow probing with a less than perfect probe. Probing at 3 IPM can have the probe stop right at trip point which is or can be unstable. The G38.6/7 probe masking motion was added to fix the errors on retract, but they need the correct stable state in order to start without an error. It doesn't happen very often but I'm still getting errors.
[15:09:15] <kwallace2> I would prefer the probing routines not stop in the unstable zone, which means not stopping when the probe trips.
[15:13:37] <kwallace2> At least, I'd like to give it a try. So far my attempts have shown what doesn't fully work. Yet another way wouldn't be a tragedy.
[15:18:58] <cradek> kwallace2: is there some way I'm not seeing, where continuing solves your problem better than retracting? seems like retracting has got to be the safer alternative.
[15:28:00] <kwallace2> But the retract invokes another move which so far cares about a stable state to start. Fast probes work okay because they overrun up to .020" or more so they stop in a stable state.
[15:29:32] <kwallace2> Rogge just called and he is going to change our G38.6 to mask the start status as well.
[15:48:07] <cradek> kwallace2: no, I mean the g38.2 itself would retract before it finishes
[15:49:09] * cradek shrugs
[15:49:55] <kwallace2> Yes, I agree. That means that I need to understand the G38 code well enough to get what I want without clobbering other features.
[15:50:37] <cradek> the hard question is what the probe-until-release variants do to "retract"
[15:51:20] <cradek> of course adding a resistor and capacitor to the probe is the better fix than any of this :-/
[15:53:04] <kwallace2> I prefer to trigger and capture on the first edge then ignore all else. The RC filter adds a delay, which is most likely okay, but..
[15:55:27] <kwallace2> As well as capture the first edge, it might be good to count the on and off time to test that the first edge was a valid trigger.
[18:24:14] <andypugh> Is “Features” part of the main LinuxCNC distriubution?
[18:26:39] <andypugh> It is starting to look pretty slick:
http://www.linuxcnc.org/index.php/english/forum/40-subroutines-and-ngcgui/26578-linuxcnc-features-a-kind-of-ngcgui?start=170#56725
[18:59:32] <cradek> andypugh: that really looks impressive.
[19:02:44] <andypugh> Doesn’t it? I keep meaning to try it.
[19:03:17] <cmorley> mozmck: I think deletion is fine.
[19:03:36] <cradek> I keep meaning to try ngcgui on the lathe and I haven't even done that.
[19:03:58] <cradek> jthornton sure speaks highly of it
[19:04:20] <cradek> a semi-automated lathe seems really ideal
[19:09:46] <andypugh> I have never tried ngcgui either. I wrote my simple macros and their GUI and use that nearly all the time.
[19:38:27] <KGB-linuxcnc> 03Robert Ellenberg 05feature/reverse-run-2.7 8339aff 06linuxcnc New branch with 32 commits pushed, 1024 files changed, 03366(+), 0457(-) since feature/reverse-run-2.7/7021767
[20:42:40] <skunkworks> uh - wow?
[20:44:00] <Tom_itx> heh