Back
[08:24:09] <skunkworks> I chatted with the one of the main authors of PathPilot today. What PathPilot is doing is normal. My toolpath generator does not do G93 at this time. So, G94 does not translate linear and rotational movement well in a single block. I am going to talk to the company tomorrow about the issue. It appears PathPilot is working correctly at this point.
[08:33:19] <jepler> hm, it looks like linuxcnc's documentation for G94 may have been simplified too much and no longer really says what happens
[08:33:27] <jepler> http://linuxcnc.org/docs/html/gcode/gcode.html#sec:G93-G94-G95-Mode
[08:34:22] <jepler> hm, I swear it used to be very specific, but even the 2.2 docs look substantially like what is there now
[08:36:02] <jepler> (if any of XYZ move, then the F number is applied to the coordinated XYZ motion; otherwise, if any of ABC are moving, the F number is applied to the coordinated ABC motion; otherwise, UVW must be moving and the F-number is applied to the coordinated UVW motion)
[08:38:26] <cradek> http://linuxcnc.org/docs/html/gcode/machining-center.html#sub:feed-rate
[08:39:47] <jepler> hm I got it wrong
[08:40:59] <jepler> skunkworks: anyway if a behavior is pathpilot specific it's a safe bet that I don't want to hear about it. :-P
[08:41:14] <cradek> skunkworks: does that mean their gui's F readout does something unexpected but the motion is as documented? I can't tell what he means.
[08:41:32] <cradek> (I bet the motion is right)
[08:41:49] <skunkworks> I don't know either. (I just wanted to make sure that linuxcnc doesn't have an issue.)
[08:42:00] <cradek> yeah, me too, and thanks
[08:42:20] <skunkworks> I have run a lot of constraint tests - but not many - 'is it going the right feed rate'
[08:42:36] <cradek> yeah, especially those combined moves
[08:43:04] <jepler> seb_kuzminsky: it looks like the "right way" to do the inb/outb is via read() and write() to the appropriate /sys/.../resourceN file of the PCI device
[08:43:22] <cradek> and although it uses the old planner still for those, all of the code feeding it (deciding things like feed) was disturbed
[08:43:58] <cradek> so it's entirely possible there's a regression
[08:45:00] <jepler> this probably doesn't have great performance, but in hm2_pci it's a startup-only activity
[08:45:13] <skunkworks> The bits of mdi moves I have been doing seem to work as expected
[09:03:31] <seb_kuzminsky> hm2_pci's main read() and write() functions do mmio on the pci bars
[09:03:56] <seb_kuzminsky> seems easy enough to teach the fpga programming code to do the same (by mmapping the right file in /sys, as you say, for uspace)
[09:15:59] <jepler> yes I'm thinking in a uspace-centric way
[09:16:24] <cradek> skunkworks: thanks for testing it
[09:17:23] <skunkworks> I was thinking that I could just copy the lines from his program on youtube but the second he clicks cycle start the program is instantly at lin n55670...
[09:17:59] <cradek> in my opinion, transcribing gcode from a youtube video is unnecessarily heroic
[09:18:25] <skunkworks> heh
[09:18:51] <cradek> especially if there are 55669 unknown lines above it
[09:19:09] <skunkworks> I think it counts by 10.. ;)
[09:19:20] <cradek> ok still
[09:33:30] <jepler> a video on youtube is *not* a bug report :-P
[09:42:01] <skunkworks> pureist!
[09:42:10] <cradek> elitist!
[11:41:42] <seb_kuzminsky> this looks interesting:
https://www.crowdsupply.com/krtkl/snickerdoodle
[11:45:54] <ssi> indeed
[11:46:19] <ssi> be nice if people could make useful stuff without giving it dumb names
[11:48:29] <seb_kuzminsky> yeah they should have skipped the anglicized name and gone with the original german Schneckennudel
[11:53:45] <skunkworks> no video?
[12:10:20] <seb_kuzminsky> skunkworks: put it in the fpga!!1
[13:02:29] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 5d46248 06linuxcnc 10lib/python/rs274/glcanon.py glcanon.py(joints_axes) fix lathe homeicon display * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5d46248
[13:36:17] <jepler> the question of what to do with home icons in the context of ja is a complicated one
[13:36:51] <cradek> don't show them except in joint mode
[13:36:52] <cradek> ?
[13:37:04] <jepler> for nontrivkins? maybe.
[13:37:23] <jepler> except aren't they making everything nontrivkins to support gaps in the axis numbers?
[13:38:21] <cradek> umm I don't know exactly what trivkins means now
[13:38:53] <cradek> 0->X 1->Z may or may not be possible with KINEMATICS_NONE or however it's spelled
[13:39:34] <cradek> unfortunately I don't know what the original design was, or if there really was one
[13:40:29] <jepler> besides looking at the kinematics type, UI would need a way to retrieve the 0<->X 1<->Z mapping from task
[13:40:36] <cradek> gentrivkins is KINEMATICS_IDENTITY
[13:45:41] <micges> gentrivkins idea was to be unable to jog single joint on gantry
[13:46:17] <jepler> what kinematics module does a lathe use now in ja, to make the Z axis be joint 1?
[13:46:21] <micges> with XYYZ mapping and KIN IDENTITY it's just trivkins with axis mapped to two joints nothing more
[13:48:29] <micges> it should be gentrivkins
[13:52:39] <micges> loadrt gentrivkins coordinates=XZ
[13:55:47] <jepler> >>> s.kinematics_type
[13:55:47] <jepler> 1
[13:55:47] <jepler> >>> s.homed
[13:55:47] <jepler> (1, 0, 1, 0, 0, 0, 0, 0, 0)
[13:56:17] <jepler> Given this information, that the kinematics_type is KINEMATICS_IDENTITY and the homed flags are as shown, ...
[13:56:27] <jepler> what *axes* should the GUI show as homed?
[13:56:38] <jepler> As I understand it, this is not enough information to answer the question
[13:57:27] <jepler> so sub-question: where in the stat buffer does the UI look for the additional required information?
[14:00:47] <jepler> and actually I'm surprised by this result when running configs/sim/axis/lathe.ini in branch dgarr/ja_configs, because I thought lathes were now going to have 0=X 1=Z, but it looks like I have 0=X 2=Z
[14:00:57] <cradek> I have a suggestion: The axis display should show whether or not the joints are ALL homed since that is the what controls important behavior, such as whether gcode can be run
[14:01:06] <jepler> and I can't actually run gcode, because after home all it still says "Can't issue MDI command when not homed"
[14:12:12] <mozmck> micges: are you using ja for your gantry setups?
[14:12:27] <micges> yes
[14:12:42] <micges> around ja3~ja4 with some fixes
[14:14:14] <mozmck> Do you have two home switches on the gantry?
[14:14:14] <micges> yes
[14:14:14] <mozmck> So does that work well? Do you have problems with it staying in joint mode after homing like I've heard about?
[14:14:14] <micges> I just home all, no single homing avail
[14:14:46] <mozmck> So it does not go into joint mode to home?
[14:15:14] <jepler> it looks like there is no docs written in the ja8 branch except a manpage for lineardeltakins
[14:19:41] <mozmck> micges: so I guess it goes into joint mode to home, and then back out. I really need to get ja8 and start working with it.
[14:23:46] <micges> yes
[14:27:00] <micges> I think better solution would be [TRAJ]LOCK_JOINT_JOGGING = 1 on gantry, then it would be safe with all guis and all kinematics
[14:32:09] <cradek> you mean disallow joint jogging altogether?
[14:32:48] <micges> yes, only teleop
[14:38:12] <cradek> that sounds useful
[14:44:41] <mozmck> But during homing it would have to still move each joint separately somehow.
[14:45:11] <mozmck> Oh, I see. only disallow joint jogging
[14:58:56] <KGB-linuxcnc> 03Michael Geszkiewicz 052.7 d678fa5 06linuxcnc 10src/configure.in configure: add check for pkg-config * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d678fa5
[15:40:18] <PCW> I wonder if this is like the BBB where they got a special price basically in exchange for chip promotion
[15:41:41] <seb_kuzminsky> i haven't seen many (any?) of the ARM+FPGA SoCs getting used, so that could be
[15:45:33] <PCW> For our parts costs a FPGA+CPU is much cheaper (though at the expense of lower CPU <-> FPGA bandwidth)
[15:45:35] <PCW> maybe in higher qtys this changes, dont know
[15:59:27] <jepler> the x15 looks interesting, but probably not *that* interesting at $239
[16:03:26] <jepler> though with esata you could just put a proper disk on it, ooh
[21:16:48] <KGB-linuxcnc> 03Dewey Garrett 052.7 6540f66 06linuxcnc 10docs/src/config/ini-homing.txt ini-homing.txt: show complete ini entries names * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6540f66
[21:19:27] <seb_kuzminsky> thanks dewey
[21:20:04] <jepler> whee, moving my little laser engraver with the power of linuxcnc
https://goo.gl/photos/WyKHzXsU8sTJbWvUA
[21:21:56] <jepler> (the microcontroller is bypassed by holding its NRESET line low)
[21:22:36] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 85f3e90 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py no show masked joints (joints_axes) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=85f3e90
[21:22:36] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 11e047f 06linuxcnc 10configs/sim/axis/lathe.ini axis/lathe.ini add [JOINT_1] stanza (joints_axes) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=11e047f
[21:24:34] <cradek> wow we all whine about it not working, and dgarr jumps in and starts fixing it
[21:31:51] <jepler> yay PWM laser control
[21:32:24] <cradek> sweet!
[21:32:26] <jepler> OK, enough success for one night
[21:32:31] <cradek> me too
[21:39:50] <jepler> hm looks like if you power off the hm2-eth board while linuxcnc is running, rtapi_app is crashing or something
[21:39:55] <jepler> hm2_eth: enqueue_read ERROR: reading packet: recv() -> -1 Resource temporarily unavailable (expected to read 136 bytes)
[21:39:58] <jepler> hm2/hm2_7i92.0: error finishing read! iter=1816059)
[21:40:01] <jepler> hm2_eth: enqueue_read ERROR: reading packet: recv() -> -1 Resource temporarily unavailable (expected to read 204 bytes)
[21:40:04] <jepler> you get a few of these, with the "expected to read" increasing each time
[21:40:12] <jepler> and then nothing, which I think means rtapi_app has crashed
[21:43:11] <jepler> yep
[21:43:12] <jepler> Program received signal SIGSEGV, Segmentation fault.
[21:43:12] <jepler> [Switching to Thread 0x7f5c2cfaa700 (LWP 28341)]
[21:43:12] <jepler> hm2_eth_receive_queued_reads (this=0x7f5c2b5d2a40 <boards>)
[21:43:12] <jepler> at hal/drivers/mesa-hostmot2/hm2_eth.c:486
[21:43:15] <jepler> 486 t1 = rtapi_get_time();
[21:43:34] <jepler> 484 rtapi_u8 tmp_buffer[board->queue_buff_size];
[21:43:39] <jepler> (gdb) p board->queue_buff_size
[21:43:39] <jepler> $1 = 1979728573
[21:43:45] <jepler> something's gone wrong by this point...
[21:43:46] <jepler> will debug
[21:45:09] <jepler> another thing that is inconvenient: I want the stepgens on 7i92 "p1", which has the higher numbered stepgens on it
[21:45:39] <jepler> .. so to get the two stepgens I want, I have to have num_stepgens=7
[21:46:29] <jepler> maybe I should be able to say: stepgen_mask=0x60 to get just the two I want
[21:47:21] <micges> that would be cool but it's a big change
[21:48:56] <jepler> I believe you
[21:59:31] <jepler> > The estimated Volkswagen pollution, about 46,000 tons since late 2008 [...] could be expected to cause an estimated 106 deaths[. Another] method brought the effects to about 40 additional deaths over the period[.]
http://www.nytimes.com/2015/09/29/upshot/how-many-deaths-did-volkswagens-deception-cause-in-us.html
[22:00:49] <cradek> doubt there'll be a judge to tell it to
[22:01:19] <cradek> it's not like he was a real criminal, having weed or something
[22:02:57] <mozmck> my method puts it at -500 because of people getting to the hospital in time :)
[22:25:14] <skunksleep> Dad says z axis is clunking at the rapid in to the hole of g83 but not the rapid out
[22:29:49] <skunksleep> He is going to lower the acceleration and see if it helps
[22:30:30] <Tom_itx> i had to lower the limits on z on my sherline
[22:30:41] <Tom_itx> with the new tp
[22:31:11] <skunksleep> (He is drilling 7000 .050" holes in 1/4 aluminum.
[22:31:39] <cradek> 7000!
[22:31:46] <Tom_itx> swiss cheese
[22:32:12] <skunksleep> Z always had a bit of backlash... Around 2 tenths
[22:32:49] <cradek> for 7000 holes it'd be worth the trouble to figure out what pecks are really needed
[22:32:59] <skunksleep> It is a vacuum table
[22:33:09] <cradek> bet the first peck can be deeper
[22:33:16] <skunksleep> Sure
[22:34:25] <skunksleep> Initially he is doing 5 or 6 a minute
[22:35:16] <skunksleep> No
[22:36:36] <skunksleep> (No was a slip of the finger)