Back
[02:54:53] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 29b9ebe 06linuxcnc 10src/rtapi/rtapi_parport.h rtapi_parport.h: make all inline functions static * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=29b9ebe
[03:41:23] <linuxcnc-build> build #1910 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/1910 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[06:18:45] <skunkworks> Oh - Thank you andy!
[06:38:01] <skunksleep> Forum is down
[07:54:12] <jepler> May 18 06:13:43 forum kernel: [167092.802930] apache2 invoked oom-killer: gfp_mask=0x200da, order=0, oom_score_adj=0
[07:54:22] <jepler> something made it run out of memory
[07:54:59] <jepler> [Wed May 18 06:13:39.351145 2016] [mpm_prefork:error] [pid 1263] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting
[07:56:15] <jepler> that's eastern time zone apparently
[07:59:11] <jepler> at that time, some system in the ukraine was spidering flo very agressivley
[07:59:15] <jepler> aggressively
[08:00:06] <jepler> anyway, it's back up; a reboot was the simplest thing to do
[08:00:17] <skunkworks> yay - thanks!
[08:02:23] <jepler> hm excuse me while I reboot it again because of fat fingers
[08:06:36] <jepler> anyway I can't easily increase the amount of RAM so I tripled the swapfile; maybe it'll survive the next jerkface who thinks it'd be a good idea to download all the posts
[08:07:45] <archivist> bing is a common culprit
[08:14:33] <jepler> this was not a standard robot, it didn't identify itself in the user agent string.
[08:38:49] <cradek> apache needs mod_jerkface
[08:39:05] <cradek> oh I suppose they already have it, but they mistakenly called it ratelimit
[10:45:16] <seb_kuzminsky> Ed's project writeups always make me chuckle:
https://softsolder.com/2016/05/18/blender-bearing-repair-round-three/
[11:46:06] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 5e1badd 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hm2_eth.h hm2_eth: switch from using rxudp count to confirm_write_cnt * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5e1badd
[11:46:07] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 298464d 06linuxcnc 10docs/man/man9/hm2_eth.9 hm2_eth: improve docs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=298464d
[11:46:07] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 1befc75 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/tram.c hostmot2: Treat -EAGAIN from hm2_finish_read specially * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1befc75
[11:46:10] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss ca9e4ca 06linuxcnc 10src/hal/drivers/mesa-hostmot2/tram.c hostmot2: fix trivial typo in diagnostic message * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ca9e4ca
[11:46:14] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 089c64b 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c hostmot2: sserial: don't keep resetting instance * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=089c64b
[11:46:18] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 8321aaf 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c hostmot2: sserial: avoid glitches when starting to run * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8321aaf
[11:46:22] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss a183e6e 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c hostmot2: sserial: avoid long wait after lost packet * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a183e6e
[11:46:32] <jepler> PCW_: .run initial state should be fixed, but I didn't test before pushing because it's inconvenient :-P
[12:25:20] <mozmck> I have an o subroutine with an M66 P1 L1 Q.5 When doing a run-from-line, this delay is executed waiting for something which of course doesn't happen. Would it not be better if it ignored those delays?
[12:26:03] * seb_kuzminsky hands mozmck a block-skip character
[12:26:17] <mozmck> and what is that?
[12:26:53] <seb_kuzminsky> http://linuxcnc.org/docs/html/gcode/overview.html#_block_delete
[12:27:13] <seb_kuzminsky> it lets you skip lines of gcode in some situations
[12:27:30] <seb_kuzminsky> (i was being a little flippant, i'm not sure if it's the right answer to your problem)
[12:28:09] <jepler> the right answer is for some moth to devote a moth-man-year to really making RFL work
[12:28:35] <seb_kuzminsky> moth?
[12:28:42] <jepler> yeah I think it's a job for the moths
[12:28:46] <mozmck> Yeah, that's what I was thinking.
[12:28:48] <jepler> the human-mans haven't taken care of the problem.
[12:29:26] <mozmck> I'm starting to work on a simple rfl that will not run through the code, but simply start where you tell it to.
[12:29:38] <seb_kuzminsky> http://ia.media-imdb.com/images/M/MV5BNDcyMjIyOTk1N15BMl5BanBnXkFtZTgwMzI0MDkwMzE@._V1_UX182_CR0,0,182,268_AL_.jpg
[12:30:04] <jepler> I bet mothra is one of those 10x moth-velopers we hear so much about these days
[12:30:29] <seb_kuzminsky> heh
[12:31:09] <seb_kuzminsky> am i the only one around here who's freaked out by metamorphosis? that's some god-level biotechnology right there
[12:31:46] <mozmck> I could either make it an INI setting, and rfl would work in the "simple" manner if the ini setting is TRUE. Or, possibly make simple rfl a new mode so they could both be used?
[12:32:14] <seb_kuzminsky> i'm generally opposed to INI settings
[12:32:17] <mozmck> it is god-level - same as the rest of creation!
[12:32:26] <seb_kuzminsky> heh yeah
[12:32:54] <seb_kuzminsky> what we do now is walk through the program, setting interpreter variables but not issuing motion commands, until we get to the line? then start running from there?
[12:33:05] <mozmck> I believe so - brokenly
[12:33:16] <seb_kuzminsky> and what you want instead is to accept whatever interpreter state you happen to be in, and just start executing from the selected line?
[12:33:31] <mozmck> Maybe we should also make a list of what is broken while I'm at it.
[12:33:31] <seb_kuzminsky> what do we currently do with modal gcodes?
[12:33:44] <seb_kuzminsky> that'd be a good place to start
[12:34:02] <mozmck> Yes, I want to just start from the selected line.
[12:34:09] <seb_kuzminsky> maybe write down the current behavior as you figure it out into the Code Notes document?
[12:34:28] <mozmck> Yeah, that would be good.
[12:34:50] <mozmck> Right now, I know that probe moves in an O subroutine are badly broken in RFL
[12:35:11] <mozmck> M66 IMO should not delay waiting for the signal.
[12:35:17] <seb_kuzminsky> the code on (and after) the line you Run From surely expects some specific interp state (modal gcodes, named & numbered parameters, etc?)
[12:35:42] <mozmck> Well, that would be one of the possible drawbacks to a simple RFL
[12:35:43] <seb_kuzminsky> i can imagine situations where waiting is the right answer
[12:36:01] <mozmck> how is that?
[12:36:28] <mozmck> You are not wanting to run any of the code, simply set state I think.
[12:37:00] <seb_kuzminsky> what if the input it's waiting on is the door close switch?
[12:37:22] <mozmck> For a simple RFL, you just have to be careful where you start. That is pretty common from what I hear.
[12:37:50] <mozmck> I would think that would be more in an e-stop chain or similar.
[12:38:17] <seb_kuzminsky> oh wait, are you saying this: "in the current RFL, as the interpreter advances up to the line the user asked for it should not perform the M66 wait or the probe moves"?
[12:38:38] <mozmck> exactly! thanks for wording it better.
[12:39:06] <mozmck> The probe moves work properly if they are not in O subroutines.
[12:39:21] <mozmck> If they are in O subroutines it does *really* nasty stuff.
[12:39:50] <seb_kuzminsky> when advancing past non-O-sub probe moves, do they act as if the probe move happened but didn't detect a probe trip?
[12:40:16] <mozmck> Seems like when it starts running at the line requested, it does the move as a probe move.
[12:40:39] <seb_kuzminsky> mozmck: yuck, bug
[12:41:46] <mozmck> So if it is a G2 arc for instance, it runs it at the probing speed - and will eventually say the probe move ended without making contact etc I believe depending on the move.
[12:42:07] <seb_kuzminsky> that's just bonkers
[12:43:11] <mozmck> For a simple RFL, you make sure you start at a sane place, and it works great.
[12:43:45] <mozmck> I think I'll look into making simple RFL a different command. Now I have to figure out how normal RFL is commanded.
[12:44:21] <seb_kuzminsky> good place to start
[12:53:35] <pcw_home> jepler: sserial run state is fixed
[13:27:03] <jepler> pcw_home: thank you for doing my testing
[13:39:54] <cradek> I'm pretty sure I believe in the simple-rfl algorithm you're talking about
[13:40:25] <cradek> it's important that invoking it doesn't affect any machine state, like spindle settings or coolant
[13:40:53] <cradek> then you can set things how you want them, and then simple-rfl
[13:41:11] <cradek> very papertapey
[13:41:32] <mozmck> Yes, that is my plan.
[13:42:28] <mozmck> And if both methods are available at the same time, then conceivably a GUI could have a way to use both and the user could choose the best one for each case even.
[13:42:39] <cradek> seems like you won't be able to (for instance) start in a sub, because when it gets to endsub you'll just get an error
[13:43:03] <cradek> ... which is fine by me
[13:43:10] <cradek> if nothing else it's sure predictable
[13:43:29] <mozmck> Yes
[13:48:36] <jepler> it might run some of the sub, at least until readahead reaches the endsub
[13:49:12] <jepler> https://en.wikipedia.org/wiki/Document_Structuring_Conventions
[13:49:28] <jepler> my own biases make me think a real working RFL has to add metadata not present in gcode, just like DSC adds to postscript
[13:50:35] <jepler> in particular, you'd have a prolog(ue) section, G20 G64 ... would go there, as would subroutine definitions
[13:51:30] <jepler> and then you'd have annotations at each spot where you can sensibly resume
[13:52:27] <cradek> touchy (barely barely) does this; it assumes sensible resume points are the ones that have N words
[13:52:47] <cradek> I wonder if that's even documented
[13:53:08] <cradek> I would put them before tool changes and at other sensible places
[13:53:43] <cradek> listing sensible resume places somehow would also be very smart for simple-rfl
[13:54:39] <cradek> at those places you could carefully set all machine state, making it safe to resume without any special care
[13:54:45] <mozmck> I talked to one man who mentioned controllers he has worked on had special codes for places you could resume from.
[13:55:19] <cradek> you could just use sharpie on the paper tape
[13:55:47] <mozmck> They also had a button on the gui, and the code would automatically go to the previous resume point iirc
[13:56:00] <cradek> mozmck: touchy does exactly that
[13:56:08] <cradek> previous/next resume point
[13:56:21] <mozmck> what is an N word?
[13:56:34] <jepler> mozmck: N012345
[13:56:37] <cradek> N1234 type line number at the beginning of the line
[13:56:44] <jepler> it's like good old basic line numbers
[13:56:58] <cradek> y'know, "N" for restart poiNt
[13:57:08] <mozmck> Oh, ok. I don't even use those now.
[13:57:37] <mozmck> Code that I've seen with them has an N number on every line - so I don't know how useful that would be.
[13:57:40] <cradek> other than touchy's thing, they do nothing except make some humans more comfortable
[13:57:58] <cradek> yes that's the typical usage
[13:58:09] <mozmck> I don't really like them because if you add code you have to change them all - etc.
[13:58:17] <cradek> not in linuxcnc - they do nothing
[13:58:27] <jepler> oh linuxcnc doesn't check if they're in order or not repeated or anything like that
[13:58:30] <cradek> leave 'em out, out of order, whatever
[13:58:52] <mozmck> No, but become meaningless :-)
[13:59:07] <cradek> although, hilariously, I think it will error if the number is too big
[13:59:13] <mozmck> or confusing.
[13:59:18] <cradek> I remember us increasing it
[13:59:22] <mozmck> what is "too big"?
[13:59:46] <cradek> I sure don't know without looking at the source
[13:59:52] <mozmck> ok
[13:59:52] <cradek> or maybe it's in the docs
[14:00:20] <jepler> hmph the n-number can't be the result of a [calculation]
[14:00:25] <cradek> http://www.linuxcnc.org/docs/html/gcode/overview.html#_line_number
[14:00:45] <cradek> or negative (according to the docs)
[14:00:55] <jepler> n10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[14:00:59] <jepler> is accepted though
[14:01:08] <jepler> as is n1.1
[14:01:48] <mozmck> I would think a special code for resume points might be good - if we implement that.
[14:01:52] <cradek> ... CHKS((value > 99999), NCE_LINE_NUMBER_GREATER_THAN_99999); */
[14:02:05] <cradek> it's commented out and the comment has an explamation point
[14:02:24] <jepler> /*! ... */ is special to doxygen I think
[16:12:53] <skunkworks> http://www.practicalmachinist.com/vb/cnc-machining/hmc-retrofit-320332/
[16:14:07] <skunkworks> seems most people on practical machinist are purists.. A machine control needs to be fanuc, centroid or any of the other really expensive controls
[16:15:09] <cradek> > At this moment I would like to know what is the best option.
[16:15:20] <cradek> me too, my friend, always
[16:17:11] <cradek> (haha, linuxcnc on it in 2 weeks)
[16:17:40] <cradek> maybe if done by a couple experienced folks that would be possible, but the machine is unknown and has been stripped
[16:19:16] <PCW_> interfacing Fanuc drives is not easy currently
[16:19:52] <PCW_> ( with non Fanuc hardware I mean)
[16:20:14] <cradek> > Basically all of that is incorrect.
[16:20:16] <cradek> haha
[16:21:16] <PCW_> assuming these are digital (PWM) or worse FSSB drives
[16:22:28] <cradek> "I looked at it about 8 years ago therefore I'm an expert"
[16:23:56] <skunkworks> sorry ;)
[16:24:39] <cradek> aside from being your fault, it's not your fault
[16:24:42] <cradek> :-)
[16:29:41] <skunkworks> of all of that - the only thing anyone got right was that linuxcnc doesn't have a lathe roughing, finishing cycle
[16:31:07] <cradek> true! but it's not a lathe is it?
[16:38:25] <skunkworks> details ;0
[18:41:50] <skunkworks> zlog
[18:44:04] <JT-Shop> anyone have an absolute encoder?
[18:49:01] <cradek> I have at least one unknown parallel-interface-of-some-kind model
[18:49:29] <cradek> it has, I think, a DB25, and it's marked with a pinout
[18:49:59] <JT-Shop> dewey is looking for someone to test the absolute dgarr/ja14-abshome branch
[18:50:52] <cradek> I'd send it to him if it'd help him
[18:51:17] <cradek> but someone who has one with a known already-working interface might sure be better
[18:51:51] <cradek> oh hey, could he use a resolver on a 7iwhatever?
[18:52:04] <JT-Shop> I don't think he has much hardware
[18:52:08] <cradek> I think that's already known to work
[18:52:55] <JT-Shop> hmm
[18:53:29] <cradek> I have a spare HNC resolver *somewhere* that I could loan, but I'd want back eventually
[18:53:55] <JT-Shop> let me fish some more :)
[18:54:02] <cradek> ok :-)
[18:54:10] <cradek> sounds like I'm probably not the best one to help
[18:54:28] <JT-Shop> I can get one from aliexpress cheap
[18:54:51] <seb_kuzminsky> is there something about absolute-encoder homing that requires ja?
[18:55:12] <JT-Shop> good question for dewey
[18:55:26] <kwallace> I also have some HNC resolvers on the shelf somewhere.
[18:55:32] <JT-Shop> I think he made a branch to home them properly
[18:57:30] * JT-Shop heads inside to veg
[18:57:38] <skunkworks> I think he just added absolute homing - what ever that means. I wasn't part of the conversation
[19:14:40] <PCW_> I can send you a Fanuc absolute encoder (it needs a battery to retain its position info)
[20:24:14] <jepler> a resolver is absolute-within-revolution, I think this kind of homing is for absolute-over-many-revolutions
[20:24:24] <jepler> we have support for some such encoders in hostmot2 don't we?
[20:27:38] <PCW_> Yes, for Fanuc serial pulsecoders, SSI and BISS
[20:28:00] <cradek> jepler: you're right, but it would still be possible to test with just one rev
[20:31:33] <PCW_> unfortunately eth-packet-loss has problems with sserial (maybe a race condition it works at low servo thread rates but not high rates)
[21:05:31] <jepler> PCW_: noted. this machine doesn't have great latency so I haven't tried to get any results at faster than 1.25kHz
[21:07:03] <jepler> hmph, tried and failed to add peak triggering to halscope. I guess I need to tinker more with the capture logic than I had wanted to
[21:08:06] <jepler> it doesn't count values occurring after the trigger point in a trace as counting towards the peak-to-be-surpassed
[21:10:55] <PCW_> the problem seem to only be at startup
[21:11:03] <PCW_> seems
[21:14:59] <jepler> PCW_: what's the symptom?
[21:15:08] <jepler> ah that simple change made peak detection work better
[21:16:29] <jepler> .. and how fast do you run before you see it routinely?
[21:17:53] <jepler> hm2/hm2_7i92.0: Smart serial card hm2_7i92.0.7i73.0.1 error = (8) Remote fault
[21:18:05] <jepler> ^^ this ?
[21:28:10] <skunkworks> looks like the matsuura only has a few tenths backlash on the x and y - but Z has close to .002. It seems consistant over the whole travel so hoping a loose bearing or mis-adjusted ball nut.
[21:30:26] <skunkworks> (it is nice having a jog wheel hooked up.
[21:30:54] <skunkworks> the pendent interface encoder counters are great - they are 1x
[21:36:28] <andypugh> skunkworks: Did you see yesterdays update to carousel.comp?
[21:38:26] <skunkworks> andypugh, yes - I tried it just a little. If I first bring up the machine and poke one of the jog buttons it starts rotating and doesn't stop
[21:38:55] <skunkworks> if I then poke the oposite jog button it stops - then jogs normally.
[21:39:27] <skunkworks> I thought maybe it was homing and didn't have a tool number at that point - but giving it a tool number doesn't help the initial jog running forever
[21:40:00] <skunkworks> does that make sense?
[21:40:22] <skunkworks> (that is as far as I got testing it)
[21:51:24] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss ae7364e 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c hostmot2: sserial: avoid glitches when starting to run * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ae7364e
[21:51:24] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss ab4eec3 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c hostmot2: sserial: avoid long wait after lost packet * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ab4eec3
[21:52:15] <jepler> PCW_: if it was the (8) Remote Fault message, I think I may have found where I introduced it. new branch drops the change that I claimed "avoided a reset loop" which was apparently my misunderstanding
[21:52:35] <jepler> I was confused between repeatedly writing 0x800 and 0x80000000
[21:52:41] <jepler> afk
[21:57:54] <andypugh> skunkworks: Yes, the carousel needs to be homed before it can be jogged.
[21:58:33] <andypugh> Though I thought I had set things up so un-homed jogs were ignored.
[21:58:58] <andypugh> I will look at it if I get time tomorrow
[21:59:18] <andypugh> Yours is a single-direction index-type carousel?
[22:00:33] <andypugh> email me or try to catch me tomorrow, time to sleep, I have an early start tomorrow
[22:41:32] <skunksleep> So... What if I wanted to home the tool chain at startup... I would have to know the tool that is in the spindle at shut down.. Possible?
[22:43:32] <skunksleep> If the carousel component was really fancy - it could home keeping track of the counts to the index - then return it to the pocket that was facing the spindle.
[22:47:35] <pcw_home> jepler: yes, remote fault
[23:28:31] <KGB-linuxcnc> 03andypugh 05dgarr/ja14-abshome 0e4415a 06linuxcnc 10scripts/update_ini update_ini: Add the halui pins to the conversion * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0e4415a
[23:28:32] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja14-abshome c67aff2 06linuxcnc 10src/emc/ini/inijoint.cc 10src/emc/motion/homing.c 10src/emc/motion/motion.h 10src/emc/task/taskintf.cc homing,abs encoder, optn to suppress final move JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c67aff2
[23:28:32] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja14-abshome 21aa0f4 06linuxcnc 10docs/src/config/ini-config.txt 10docs/src/config/ini-homing.txt homing docs update for absolute encoder JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=21aa0f4
