Back
[01:27:08] <CIA-62> EMC: 03seb 07master * rbe9df99437b2 10/debian/ (emc2-dev.files emc2.files.in): move the comp(1) manpage from emc2.deb to emc2-dev.deb
[05:04:55] <Dave911> logger_dev: bookmark
[05:04:55] <Dave911> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-12-30.txt
[07:39:43] <CIA-62> EMC: 03seb 07master * rab3cb34332d5 10/src/hal/components/ (logic.comp scale.comp threadtest.comp timedelta.comp): add missing whatis information to a couple of .comp components
[13:27:58] <tom3p> if i change control of a joint (trivkins) from stepgen type 'p' to type 'v',
[13:27:58] <tom3p> will a jerk be caused by the new 'v' type stepgen.N.position-fb disagreeing with the current axis.N.joint-pos-fb?
[13:29:35] <tom3p> (it was noted that i should beware a jerk on exit v to p, but i suspect it happens on entry... p to v)
[13:34:49] <jepler> the original design assumed the control mode would not be changed during operation. somebody hacked that in later. I have no idea what guarantees, if any, you get when you change modes.
[13:34:59] <jepler> anyway, stepgen never limited jerk; it only limits velocity and acceleration
[13:36:16] <tom3p> will there be a mismatch on changeover?
[13:36:39] <alex_jon1> tom3p: best would be to use 2 stepgens
[13:36:46] <alex_jon1> one in position one in velocity mode
[13:36:48] <tom3p> yes, i plan on 2
[13:36:52] <alex_jon1> and do the switch before those
[13:37:03] <alex_jon1> a faulted stepgen will always track the feedback
[13:37:30] <alex_jon1> so you can disable the one you're not using, and when you're ready for it to be re-enabled it should be ok
[13:38:23] <tom3p> i imagine a position mismatch because the new velocity mode stepgen doesnt know anything about current position.
[13:38:25] <tom3p> i dont understand 'a faulted stepgen wil track the feedback'
[13:38:52] <tom3p> the step gen reports posn to axis
[13:47:28] <tom3p> jepler i was unaware of the hack, i take it that control mode >can< be changed during operation, that'd mean there'd be no position mismatch if only 1 stepgen is used.
[13:51:27] <alex_jon1> tom3p: there are 2 things
[13:51:35] <alex_jon1> emc2 position, and stepgen position
[13:51:50] <alex_jon1> while an axis is in velocity mode, you need to loop emc2 position back
[13:52:04] <alex_jon1> then no matter what commands come for that axis, it doesn't error
[13:52:12] <alex_jon1> (it's just like one of the sim configs)
[13:52:35] <tom3p> where its at is where it should be ( istwerte sollwerte) ok
[13:52:47] <alex_jon1> the second is the stepgen position. while stepgen2 (velocity) is active, stepgen1 (position) should be disabled
[13:53:47] <alex_jon1> hmm.. or maybe not
[13:54:00] <alex_jon1> here's a new thought
[13:54:12] <alex_jon1> have stepgen1 (position) connected to emc2 at all times
[13:54:22] <alex_jon1> that way it's position and emc2's never disagree
[13:54:38] <alex_jon1> simply switch the stepgen outputs from stepgen1 to stepgen2 (velocity)
[13:54:47] <alex_jon1> aka step/dir signals
[13:54:54] <tom3p> (been thinking bout that, ok)
[13:55:13] <tom3p> one tracks the correct position
[13:55:15] <alex_jon1> that way stepgen1 will always do what emc2 tells it to
[13:55:32] <alex_jon1> and stepgen2 will output pulses based on velocity/whatever commands
[13:55:46] <tom3p> thx stepgen 1 will be position, and stepgen2 will be velocity
[13:55:47] <alex_jon1> when you switch back to stepgen1 there's no change from emc2's point of view
[13:56:37] <tom3p> ah! but stepgen 2 moved out of position, stepgen1 didnt get feedback during that time
[13:57:13] <tom3p> i think... becuz position is from step & dir accumulation
[13:57:21] <tom3p> i think ;)
[13:57:51] <alex_jon1> does it matter?
[13:58:15] <tom3p> if the position doesnt agree there's jerk when the handoff occurs (i think )
[13:58:16] <jepler> tom3p: it looks like hostmot2 stepgen can change mode at runtime, software stepgen can't. I assumed from your initial remark that you'd determined that this *was* possible in whichever stepgen you were using, and wanted to know what conditions there were
[13:58:34] <alex_jon1> tom3p: if you switch at step/dir level there can't be any jerk
[13:58:41] <jepler> .. which I don't know (and I had software stepgen in mind, so I said it was a [recent] hack [that I'd forgotten])
[13:58:45] <jepler> bbl, time to go to the office
[13:59:03] <tom3p> thx
[13:59:31] <alex_jon1> tom3p: each stepgen keeps his own position, and it doesn't change from the outside, so there cannot be any jump/jerk
[14:00:46] <alex_jon1> both stepgens are running at all times, you're just discarding the output from the one you don't want
[14:02:50] <tom3p> alex_jon1: i can try it, i thought motion's axis.N.motor-pos-fb came from the stepgen.N.position-fb and those 2 sources (v & p) would disagree.
[14:02:51] <tom3p> thx
[14:03:44] <tom3p> right, i dont understand how axis.N knows the correct position if not from the stepgen.
[14:03:59] <jthornton> tom3p: I just removed the difference between where EMC thought it was and where the THC had hijacked the position to during a safe move on my plasma
[14:04:28] <jthornton> dunno if that helps in your situation...
[14:04:54] <tom3p> jthornton: i thought you had problems to resolve about jerk on returning to emc2 position control
[14:05:11] <tom3p> and dallur ditto
[14:06:00] <jthornton> no, I just made sure to remove the difference slowly (so to speak) during a Z move up
[14:06:33] <tom3p> i was working on how to make the 2 agree ( to remove the difference by crawling till desired = expected )
[14:08:19] <tom3p> jthornton: thanks, did you used a single stepgen and always stayed in position mode?
[14:09:14] <jthornton> for my offset I used an encoder in velocity mode to tell me if an offset is needed then hijacked the stepgen output and added or subtracted from it
[14:10:20] <jthornton> then if(some conditions && Z is moving up) remove the offset a little at a time till offset == 0
[14:13:52] <jthornton> tom3p: I gotta run ttul
[14:13:56] <tom3p> jthornton: if i get it..., your stepgen was in position mode and you commanded new positions to accomodate the THC. when done you commanded new positions a bit at a time until stepgen position agreed with axis position.
[14:13:58] <tom3p> thx
[14:14:05] <tom3p> me2
[14:14:12] <jthornton> exactly
[14:16:14] <micges> for that types of joints emc shoud have velocity based joints, so you don't must hack positions loopbacks
[14:18:15] <micges> ignore above
[14:34:02] <SWPadnos> tom3p, do you need to track the motion while the V mode stepgen is "in control"?
[14:35:08] <SWPadnos> the (second) method ALex mentioned is what I had thought of, just use two and ignore position changes made by the V mode stepgen
[14:37:52] <alex_jon1> SWPadnos: I think (judging by his answers/questions) that he needs to track position
[14:38:00] <SWPadnos> it does seem that way
[14:38:06] <SWPadnos> and that's hard
[14:38:10] <SWPadnos> er
[14:38:12] <alex_jon1> my guess is tom3p is using the v-stepgen during EDM
[14:42:41] <tom3p> yes, i use v mpde for edm and was concerned about initial and exit positions reported by the v mode stepgen to axis.N.motor-pos-fb. i thought that'd be a problem. i'll try alex's idea of the posn mode stepgen kept sync'd always.
[14:43:38] <tom3p> i dont need to control position during edm, (besides boundaries)
[14:44:33] <tom3p> thx for all the info, cars up to heat, off now
[14:44:46] <SWPadnos> you'll need something more, like jthornton has, to let EMC know about V mode motion (somehow)
[14:45:02] <tom3p> yes will swx
[14:48:47] <skunkworks_> bad news is - ice dam leaked a bit of water into one of the back rooms of the house.. good news is - under the carpet is oak floors.
[14:48:53] <skunkworks_> * skunkworks_ hates carpeting.
[14:55:34] <jepler> * jepler wonders why there are two similar messages:
[14:55:34] <jepler> rs274ngc_return.hh:#define NCE_ARC_RADIUS_TOO_SMALL_TO_REACH_END_POINT _("Arc radius too small to reach end point")
[14:55:38] <jepler> rs274ngc_return.hh:#define NCE_RADIUS_TOO_SMALL_TO_REACH_END_POINT _("Radius too small to reach end point")
[14:56:16] <jepler> apparently only NCE_ARC_RADIUS_TOO_SMALL_TO_REACH_END_POINT is actually used
[14:57:12] <cradek> are you working on stuart's thing?
[14:57:25] <jepler> that's what prompted me to see this thing I just mentioned
[14:59:00] <jepler> I can't find anything that would make tolerance depend on machine configuration... there's something that depends on the current length units, but that's it
[14:59:42] <cradek> I don't understand what that error is even supposed to mean. R < half the distance between the points?
[15:00:15] <jepler> if you have two points on an arc, what's the smallest possible radius of the arc?
[15:00:45] <cradek> half the distance between them, I think
[15:00:50] <jmkasunich> half the distance between them
[15:00:56] <SWPadnos> yep, that makes the distance one diameter
[15:01:47] <SWPadnos> I'm assuming it doesn't, but is it possible that kins has anything to do with it?
[15:01:52] <cradek> no
[15:01:54] <SWPadnos> (Stuart's problem)
[15:01:59] <SWPadnos> that's what I thought
[15:02:09] <jepler> I agree, kins should be irrelevant here
[15:02:52] <jmkasunich> the error is coming from the interp, right?
[15:03:08] <jepler> yes, as far as I understand it
[15:03:22] <jmkasunich> doesn't the interpreter know almost nothing about the machine config?
[15:03:45] <jmkasunich> even velocity and accel limits are applied by task, not interp... (or maybe not?)
[15:03:48] <cradek> the test in Interp::arc_data_r is just wrong
[15:04:29] <cradek> err
[15:04:58] <cradek> I'm wrong
[15:06:50] <cradek> it seems right
[15:07:08] <jepler> CHKS(((half_length - abs_radius) > tolerance),
[15:07:08] <jepler> NCE_ARC_RADIUS_TOO_SMALL_TO_REACH_END_POINT);
[15:07:15] <jepler> this is the test we're talking about, right?
[15:07:18] <cradek> yes
[15:08:27] <jepler> I think it does what it intends (accepts a radius down to half_length-tolerance)
[15:09:14] <cradek> the /* allow a small error for semicircle */ case is kind of baffling
[15:09:14] <jepler> the next line still has me scratching my head a bit; I see that it's indended to make an arc that is "rather close" to a semicircle into "exactly" a semicircle
[15:09:21] <jepler> but I'm not convinced that's what it does
[15:10:10] <jmkasunich> isn't the real mystery the fact that it works on one config and not on another?
[15:10:52] <cradek> I suspect there are different versions at work to explain that
[15:11:09] <jmkasunich> oh
[15:12:04] <cradek> [but I probably only think that because it would be a big surprise otherwise]
[15:13:05] <jepler> Author: John Kasunich <jmkasunich@fastmail.fm> 2008-11-10 22:55:26
[15:13:07] <jepler> actual implementation of G90.1/G91.1 absolute arc centers - still need to update tests
[15:13:16] <jepler> wow, jmkasunich actually worked on the interpreter once?
[15:13:24] <SWPadnos> and only a year ago
[15:13:52] <jmkasunich> once
[15:14:08] <alex_jon1> you only have to slip once
[15:15:12] <jepler> I wonder how old an emc stuart could possibly be running on the cinci
[15:15:35] <jmkasunich> it seems like a good question to ask
[15:16:02] <jepler> the arc test looks unchanged since 2006
[15:16:07] <jepler> 4d0dfc2ee67937975c19a54ac3bf68bf583e6a66
[15:16:13] <jepler> - CHK(((half_length / abs_radius) > (1 + TINY)),
[15:16:13] <jepler> + CHK(((half_length - abs_radius) > tolerance),
[15:16:14] <jepler> NCE_ARC_RADIUS_TOO_SMALL_TO_REACH_END_POINT);
[15:16:54] <jmkasunich> I wonder where "tolerance" comes from?
[15:17:03] <jepler> it comes from two calling levels up
[15:17:18] <jepler> I haven't finished assuring myself that's not changed yet; there are a lot more changes to that file (interp_convert.cc)
[15:17:38] <jepler> ooh I should be using 'git gui blame', not 'gitk'
[15:18:26] <alex_jon1> I see his cinci emc.nml is using 10240 for emcStatus
[15:18:31] <alex_jon1> I think that's post 2.2
[15:19:35] <jepler> blame tells me those lines in Interp::convert_arc2 date to 2004
[15:19:44] <alex_jon1> hmm.. nope
[15:19:51] <jepler> and the commit message indicates that change was possibly due to PC running indent
[15:19:53] <alex_jon1> it was in 2.1 too
[15:21:48] <jepler> is it a problem with offsets? coordinate system rotation? having a tool loaded?
[15:22:02] <jepler> oh well
[15:22:08] <SWPadnos> he's got a GEOMETRY= line in the ini file, which is a 2.3 thing (isn't it?)
[15:22:59] <SWPadnos> I'm reasonably sure he's using a git checkout from <6 months ago, but I don't have proof
[15:23:58] <cradek> jmkasunich: I used absolute arc centers just the other day. it's nice.
[15:24:24] <jmkasunich> I forget whose idea that was
[15:24:26] <jmkasunich> not mine
[15:24:39] <skunkworks_> it couldn't be the gcode being created?
[15:24:41] <jmkasunich> I think you guys talked me into implementing it to get my feet wet in the interp
[15:25:08] <cradek> it's just C - how bad can it be
[15:25:16] <alex_jon1> ha
[15:25:16] <jepler> skunkworks_: If I understand correctly, stuart says the same gcode is accepted on one PC in sim but not on another PC running the cinci
[15:25:31] <cradek> ... gcode which we do not have
[15:25:35] <skunkworks_> eww
[15:25:38] <cradek> has anyone tried generating it with one of those images?
[15:25:43] <jepler> but nobody's seen the gcode except him at this point, and it's gcode generated by image-to-gcode and maybe he's generating it on each system
[15:25:53] <jmkasunich> is it 100% clear that he is running image2gcode in one place, and then trying the resulting gcode in two places?
[15:26:00] <cradek> not clear
[15:26:26] <jepler> image-to-gcode is not much of a moving target, though
[15:26:44] <jepler> iirc it uses some serious nastiness to generate its arcs
[15:29:13] <jmkasunich> the kind where you wouldn't be astonished if it made a bogus arc on the third tuesday after a full moon?
[15:29:32] <jepler> wellllllll
[15:30:57] <cradek> we need the gcode or the i2g settings
[15:31:32] <jepler> yes we do
[15:31:40] <jmkasunich> so send the email already ;-)
[15:31:51] <cradek> 'extend image border' gives a traceback about arrays with incompatible shapes
[15:31:55] <CIA-62> EMC: 03micges 07joints_axes3 * rd352fbf0249d 10/src/emc/motion/command.c: Remove unused global variable
[15:32:01] <jepler> cradek: so I've heard
[15:32:51] <SWPadnos> I wonder if this is the G-code:
http://www.mpm1.com:8080/kansaslogo.ngc
[15:32:56] <jepler> 07:54 <alex_joni> jepler: might be interesting
http://www.linuxcnc.org/component/option,com_kunena/Itemid,20/func,view/catid,21/id,1304/lang,en/#1306
[15:32:59] <jepler> 08:38 <jepler> yeah, there's a bug. somebody should fix it. I'm too tired.
[15:33:01] <SWPadnos> someone mentioned an arc on line 12, and this has one
[15:35:55] <cradek> +0.120,-0.0534 to 0,0; R0.125
[15:36:15] <cradek> dist = 0.1313
[15:36:18] <SWPadnos> strangely, all the ngc files in that directory have the same arc on line 12
[15:36:30] <SWPadnos> but not from the same starting position defined on line 11
[15:36:31] <cradek> it's an entry arc
[15:37:29] <cradek> I see it
[15:37:44] <cradek> I bet the G49 on line 3 "moves" Z
[15:37:58] <cradek> makes the arc invalid but only if you have a tool length offset
[15:38:06] <cradek> so he doesn't see it on sim
[15:38:30] <SWPadnos> funny. I guess I would have assumed that Stuart would test with the same tool tables, but I shouldn't do such things
[15:38:31] <cradek> (good thing it aborts - probably would have crashed a real tool)
[15:39:22] <jepler> rs274/author.py class Gcode def begin
[15:39:42] <jepler> the initial "move to safety height" should come after G49, then
[15:40:13] <cradek> there should not be a G49
[15:40:20] <cradek> that's just crazy
[15:40:40] <jepler> oh, hm
[15:40:50] <jepler> oh that is "cancel"
[15:40:53] <jepler> wtf
[15:40:59] <cradek> yeah, reproduced
[15:41:16] <jepler> is i2g just broken if you want to use a tool, then?
[15:41:33] <cradek> yes
[15:42:30] <jmkasunich> who would ever want to use a tool?
[15:43:03] <SWPadnos> hmmm
[15:43:23] <jepler> cradek: anything else in the author.py gcode prologue that should be reamed while I'm there?
[15:43:23] <SWPadnos> if we assume that tools are unnecessary (and dangerous), I bet there's a lot of code that can be removed
[15:43:28] <jepler> or do you want the glory for fixing it
[15:44:00] <cradek> I'd take out G54 as well
[15:44:08] <cradek> take out the G4 delay for spindle start
[15:44:58] <jepler> thank you
[15:45:00] <jmkasunich> the G4 seems harmless
[15:45:20] <cradek> jmkasunich: unneeded in our modern era with spindle-at-speed
[15:45:20] <jmkasunich> people using it as a filter don't have the option of editing in stuff like the G4
[15:45:39] <jmkasunich> cradek: you assume everyone has spindle-at-speed hooked to something
[15:45:40] <SWPadnos> not everyone has spindle-at-speed feedback
[15:46:07] <cradek> I think that way lies madness, but I defer to the group
[15:46:10] <SWPadnos> well I'll be:
http://www.imagetogcode.com/
[15:46:12] <jmkasunich> I suppose they could hook it to a delayed copy of spindle-run
[15:46:42] <jepler> SWPadnos: well it is a slightly obvious name for the program
[15:46:47] <SWPadnos> heh
[15:46:53] <jmkasunich> you are probably right about madness, but in this case, not changing an existing behavior unrelated to the bug seems right to me
[15:47:01] <jepler> I should have called it "secondhand suspenders" just so its name as unique
[15:47:13] <jepler> jmkasunich: I'm convinced
[15:47:38] <jepler> Take out G49 and G54, they can be actively harmful
[15:47:55] <jepler> G4 is not ever going to be harmful
[15:48:11] <SWPadnos> it does add a few seconds to the run time though
[15:48:13] <SWPadnos> :)
[15:48:38] <jmkasunich> anyone running the resulting g-code over and over can edit it to tweak whatever they want
[15:49:03] <jmkasunich> anyone running it as a filter is only running it once (per invocation of i2g anyway)
[15:49:14] <cradek> heh, estimated runtime on that program is 336 minutes
[15:49:25] <jepler> yeah but who believes that estimate anyway
[15:49:29] <cradek> for a 3" engraving
[15:49:35] <SWPadnos> I'll bet the cinci could do it faster
[15:49:38] <cradek> I bet it's close for this
[15:49:50] <jmkasunich> I'll be the cinci could NOT do it faster
[15:49:54] <cradek> nah, that machine is sloooow
[15:49:59] <SWPadnos> heh - true, accel is a bitch with a 12 ton head
[15:50:05] <cradek> jr could do it faster :-)
[15:50:19] <SWPadnos> a person with a dremel might be able to do it faster
[15:50:19] <skunkworks_> expecially if you turned your accel back up...
[15:50:34] <cradek> I drilled a circuit board with it - it was truly amazing how fast it went from hole to hole
[15:51:09] <cradek> would be cool to have a super high speed spindle for it. I should rig one.
[15:51:23] <jmkasunich> what would you use?
[15:51:34] <skunkworks_> and damn it! a video!
[15:51:48] <cradek> maybe the one I already have that's like jeff's zenbot spindle
[15:51:55] <cradek> I forget the guy's name who made it
[15:52:02] <skunkworks_> wolfgang or something
[15:52:03] <jmkasunich> wolfgang
[15:52:07] <cradek> right
[15:52:24] <cradek> heyyyy I know just how to do it
[15:52:31] <jmkasunich> mount it to the side of the quill or something?
[15:52:47] <skunkworks_> jmkasunich: any advancement on your gantry machine?
[15:53:01] <jmkasunich> no, I've been a total sloth lately
[15:53:23] <skunkworks_> that't ok :) sounds like you have been go go go for a while.
[15:53:25] <cradek> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=300358505742
[15:53:36] <cradek> the pic is wrong - ER40 is bigger around
[15:54:01] <cradek> cut one side of this away, stick the wolfgang spindle in a 3/4" collet in here, belt sticking out the side
[15:54:22] <skunkworks_> cradek:
http://cgi.ebay.com/Pibomulti-CAT-50-Spindle-Speeder-speed-multiplier_W0QQitemZ280375933010QQcmdZViewItemQQptZBI_Tool_Work_Holding?hash=item4147b53852
[15:54:24] <jepler> and if you want it to go even faster you can turn the main spindle and add 6000RPM
[15:54:27] <skunkworks_> you need something like that..
[15:54:41] <SWPadnos> huh. Wolfgang says he's liquidating, and possibly going out of business
[15:54:50] <cradek> yeah, except for the $3500 thing
[15:55:02] <cradek> jepler: for as long as the power cord lasts, yeah
[15:55:08] <jmkasunich> and the 50 taper, isn't jr a 40
[15:55:15] <jepler> cradek: *nose gesture*
[15:55:16] <cradek> yes
[15:55:18] <skunkworks_> yah - only one I could find..
[15:55:18] <jepler> it was a jooooke
[15:55:21] <jmkasunich> slip rings!
[15:56:07] <skunkworks_> http://cgi.ebay.com/TECNARA-CAT-40-SPINDLE-SPEEDER-SPEED-MULTIPLIER-1-5_W0QQitemZ370267528319QQcmdZViewItemQQptZBI_Tool_Work_Holding?hash=item5635aa1c7f
[15:56:28] <jepler> SWPadnos: that's too bad; I am happy with the product I have from him
[15:56:42] <SWPadnos> yeah. his stuff looks very good
[15:56:48] <cradek> skunkworks_: wooo that's neat
[15:57:03] <SWPadnos> he's got a high speed spindle on sale for $150. maybe I should get it :)
[15:57:06] <cradek> skunkworks_: if it were BT, I'd be in more pain for not wanting to spend that much
[15:57:17] <SWPadnos> you know, for when I have time to work on machines
[15:57:56] <jmkasunich> like me
[15:58:02] <SWPadnos> yeah
[15:58:03] <jepler> (only I wish it were less loud)
[15:58:17] <SWPadnos> I thought I'd have a little time over the holidays, even just to clean my office
[15:58:30] <SWPadnos> but it turns out all those jobs we thought we had lost came back
[15:58:34] <jmkasunich> yeah, I had three weeks off, and all kinds of ambitions
[15:58:55] <jmkasunich> I still haven't finished all the "must do" chores, let alone the "wanna do" projects
[15:59:04] <SWPadnos> (which is great, except that we had already started "slow boat" manufacturing, and now we need to speed things up while in progress)
[15:59:07] <SWPadnos> yeah
[15:59:15] <SWPadnos> at least I got the heater pilot lit down here
[15:59:22] <SWPadnos> and changed a couple of light bulbs
[15:59:23] <cradek> 3 weeks!?
[15:59:30] <jmkasunich> yeah
[15:59:33] <cradek> wow
[15:59:36] <SWPadnos> and a cold, if I remember correctly
[15:59:42] <jmkasunich> flu actually
[15:59:46] <SWPadnos> ah. me too
[15:59:50] <cradek> yuck
[15:59:50] <SWPadnos> lovely week that was
[16:00:36] <jmkasunich> 18 year = 19 or so day vacation, plus we had one unpaid day per month this year
[16:01:35] <jmkasunich> so I had something like 28 total vacation days for 2009
[16:01:52] <cradek> wow.
[16:01:53] <jmkasunich> used some for wicheta, and some in october, but still had a lot left
[16:02:55] <jmkasunich> this year the unpaid days are ending - I think I would prefer the time to the money, but they don't give us that option ;-)
[16:17:12] <CIA-62> EMC: 03jepler 07master * r5e8a820081f3 10/src/hal/components/wcomp.comp: improve documentation
[16:17:13] <CIA-62> EMC: 03jepler 07master * rcc00bd100849 10/lib/python/rs274/author.py: respect the current TLO and fixture settings
[16:17:15] <CIA-62> EMC: 03jepler 07master * rc06a4f7d9e65 10/src/emc/motion/command.c: Remove unused global variable
[16:20:02] <CIA-62> EMC: 03jepler 07v2_3_branch * r87869ac63e0f 10/lib/python/rs274/author.py: respect the current TLO and fixture settings
[16:50:00] <cradek> jepler: did you find a problem with those arc tests anyway?
[16:52:40] <jepler> cradek: no, just unsureness about that "nearly a semicircle" test
[18:02:35] <cradek> bizarre. I thought the point of making pid tuning parameters into pins was so you could tune using gui widgets. but, I notice they are I/O pins for some reason, making it so you can't hook a writer to them
[18:05:13] <SWPadnos> I wonder why they're IOs
[18:06:24] <jmkasunich> I can't think of any good reason
[18:06:49] <cradek> just a mistake?
[18:07:28] <SWPadnos> params are more or less IO, so making them IO might have been an attempt to keep them as close as possible to params
[18:07:29] <jmkasunich> likely
[18:07:47] <cradek> I hate to touch it again - it was such a swirl last time
[18:08:06] <jmkasunich> actually, params had a couple flavors as well
[18:08:35] <jmkasunich> read only and read/write IIRC
[18:08:56] <SWPadnos> yes, though even "read-only" could be changed by the component - like limiting stepgen rate based on thread period
[18:09:00] <cradek> "fix alex's fix to my fix to his param-to-pin changes"
[18:09:28] <cradek> only 1yr ago - the sting is not gone yet
[18:09:40] <jmkasunich> SWPadnos: the "read only" aspect was with regards to outsiders - the component can always change things
[18:09:46] <SWPadnos> right
[18:09:51] <SWPadnos> that's what I was saying :)
[18:10:06] <cradek> - retval = hal_param_float_new(buf, HAL_RW, &(addr->maxcmd_dd), comp_id);
[18:10:07] <cradek> + retval = hal_pin_float_new(buf, HAL_RW, &(addr->maxcmd_dd), comp_id);
[18:10:24] <cradek> alex's original change p-to-p change was from RW to RW so I bet he didn't even think about it
[18:12:28] <jmkasunich> typedef enum {
[18:12:28] <jmkasunich> HAL_IN = 16,
[18:12:28] <jmkasunich> HAL_OUT = 32,
[18:12:28] <jmkasunich> HAL_IO = (HAL_IN | HAL_OUT),
[18:12:28] <jmkasunich> } hal_pin_dir_t;
[18:12:34] <jmkasunich> typedef enum {
[18:12:34] <jmkasunich> HAL_RO = 64,
[18:12:34] <jmkasunich> HAL_RW = 192,
[18:12:35] <jmkasunich> } hal_param_dir_t;
[18:13:07] <jmkasunich> using a param_dir value for a pin is simply wrong - they are different bits
[18:13:26] <cradek> it was fixed in the many subsequent changes
[18:13:32] <jmkasunich> ok
[18:13:37] <cradek> swirly swirl swirl
[18:13:47] <jmkasunich> I'm also looking at a copy of hal.h that is close to a year old
[18:14:11] <cradek> how can you use an emc that's so old it doesn't have polar coordinates!?
[18:14:15] <cradek> haha
[18:15:00] <jmkasunich> I think I updated the shoptask to 2.3, but its turned off right now
[18:19:05] <skunkworks_> hey
http://cgi.ebay.com/Bryant-Grinder-CNC-PCB-Mesa-Elec-6M20-Circuit-Board_W0QQitemZ390111208735QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item5ad470a51f
[18:19:13] <skunkworks_> :)
[18:20:07] <cradek> whoah, is that some kind of archaeological artifact?
[18:20:23] <jmkasunich> hey!
[18:22:20] <skunkworks_> isa baby
[18:22:40] <jepler> 6M20 Disk Emulator
[18:22:58] <cradek> sweet
[18:23:11] <cradek> I bet that's FAST considering those eproms...
[18:23:28] <jepler> http://www.patentstorm.us/patents/6523132.html "Flash EEprom system" refers to it
[18:25:08] <skunkworks_> he still manufactures a 4M22 DISK EMULATOR
[18:25:36] <cradek> oh it's really from the mesa we know?
[18:25:52] <skunkworks_> just assumed..
[18:26:11] <jmkasunich> I'm not surprised
[18:26:17] <skunkworks_> http://mesanet.com/diskcardinfo.html
[18:26:17] <cradek> cool.
[18:27:44] <jepler> is the white and orange component a capacitor? a battery?
[18:27:49] <cradek> battery
[18:28:32] <jepler> the earliest copy archive.org has (1999) isn't old enough to list a 6M20, but it's new enough to list 4M22
[18:29:15] <jmkasunich> it's quite possible that some of his products were only sold to OEMs
[18:30:05] <jmkasunich> are those flash chips on that board? they look like windowed EEPROMs with stickers to me
[18:30:18] <jmkasunich> sell board to OEM, OEM flashes their firmware
[18:30:34] <SWPadnos> s/flashes/burns/
[18:30:37] <jmkasunich> yeah
[18:30:44] <SWPadnos> old skool
[18:30:46] <SWPadnos> :)
[18:31:08] <jmkasunich> I still have a prom eraser UV light - I suppose I could get rid of that one of these days
[18:31:32] <SWPadnos> call it a "Vitamin D light" instead
[18:32:13] <cradek> I have a fancy one that does 4 proms at a time...
[18:32:13] <jmkasunich> wrong kind of UV isn't it?
[18:32:20] <SWPadnos> probably is wrong
[18:32:23] <SWPadnos> but they don't know that
[18:32:34] <jmkasunich> until they burn out their eyes and sue
[18:32:39] <SWPadnos> heh
[18:44:54] <alex_jon1> boost the power ;)
[18:45:04] <alex_jon1> at least then they won't sue
[18:45:17] <jmkasunich> next of kin will sue
[19:06:45] <skunkworks_> I hate analog things..
[19:07:20] <jmkasunich> why?
[19:08:09] <skunkworks_> hmm - so on the mesa servo interface board - the +/-10v output is ground referenced. the input to the amc servo is a op amp +/-. Do I need to ground the - side at the drive?
[19:08:55] <jmkasunich> if the amp input is differential, the best way is to take a twisted pair from the amp input to the source (the mesa board)
[19:09:06] <jmkasunich> connect - to ground at the mesa board, and + to the mesa output
[19:10:09] <skunkworks_> http://www.a-m-c.com/download/datasheet/b15a8.pdf
[19:11:10] <jepler> and probably you want to use the adjacent GND -- e.g., pin 12 GND to go with pin 11 AOUT0
[19:11:34] <jepler> or AOUT0 10/GND 11 on the terminal block version
[19:11:35] <skunkworks_> jepler: thanks - I remember reading that in one of peters emails
[19:59:21] <cradek> jepler: looks like that was it...
[20:00:09] <skunkworks_> you guys are great!
[20:00:47] <skunkworks_> now - all you have to do is impliment jog while paused... Everyone will love you then - even maybe steve.
[20:00:55] <skunkworks_> ;)
[20:01:11] <cradek> jog while paused is easy
[20:01:21] <cradek> what to do after that is the hard part
[20:02:38] <micges> if error shows up in motion after shmem is open, does the emc script close and free it ?
[20:03:00] <jepler> micges: no clue, read the source
[20:03:29] <cradek> ouch
[20:03:36] <jepler> if you mean the shared memory between task and motion, I suspect that it is the shutdown of the component / removal of rtapi that is supposed to free the shared memory area
[20:03:52] <jepler> if that was too harsh, I apologize
[20:08:27] <micges> so something could not works, after few motion errors I've got ENOMEM in rtapi_shmem_new
[20:08:41] <micges> in sim mode
[20:09:23] <cradek> see Cleanup in emc.in
[20:09:45] <micges> yes I'm looking
[20:10:08] <cradek> ipcrm
[20:14:02] <micges> http://www.pastebin.ca/1732204
[20:15:41] <jepler> the emc runscript prints that?
[20:16:00] <micges> yes I remved redirections
[20:16:11] <cradek> I bet that's relevant
[20:16:17] <jepler> "2>/dev/null" is the redirection
[20:16:23] <jepler> it means 'Redirect stderr to /dev/null'
[20:16:29] <jepler> you removed >/dev/null but left the 2
[20:16:46] <cradek> oh
[20:17:43] <micges> ok now it's: ipcrm: invalid key (1001)
[20:18:25] <micges> still not quite ok
[20:18:51] <jepler> you said that the error is ENOMEM from rtapi_shmem_new, but the Cleanup function is cleaning up nml (not rtapi) shared memory.
[20:19:20] <micges> I know that
[20:22:57] <micges> just saw that output from Cleanup() isn't quite ok
[20:23:20] <jepler> no, it's just fine for ipcrm to not find a shared memory area to remove
[20:23:30] <jepler> emcsvr is supposed to free them when it exits normally
[20:23:38] <jepler> Cleanup's removal of the segments is for the "abnormal exit" case
[20:23:45] <micges> I see
[20:23:51] <jepler> that's why the 2>/dev/null is there
[20:24:02] <jepler> anyway, as for rtapi_shmem_new under --enable-simulator
[20:24:05] <micges> do you know how to check shmem use in kernel?
[20:24:48] <jepler> it can fail with ENOMEM if the rtapi list of shared memory regions fills up, or if shmget fails, or if shmat fails
[20:25:07] <jepler> possibly erroneously it returns ENOMEM for any failure; for shmget and shmat it should return the underlying errno instead
[20:26:00] <jepler> this (untested) will get the underlying unix error if it's shmget or shmat failing:
http://emergent.unpy.net/files/sandbox/sim-report-shmem-errno.patch
[20:27:50] <micges> Thanks I'll try track it
[20:28:57] <jepler> updated (but still untested) to rtapi_print_msg the source of the failure
[20:51:42] <micges> rtapi_shmem_new failed due to shmget()
[20:51:42] <micges> MOTION: rtapi_shmem_new failed, returned -22
[20:52:00] <micges> EINVAL
[20:54:24] <jepler> EINVAL A new segment was to be created and size < SHMMIN or size >
[20:54:28] <jepler> SHMMAX, or no new segment was to be created, a segment with
[20:54:31] <jepler> given key existed, but size is greater than the size of
[20:54:35] <jepler> that segment.
[20:56:18] <micges> mhm
[20:57:00] <micges> thx
[20:58:00] <jepler> probably the latter is most likely: you ran version 1 of emc which created a shm segment of N bytes and then crashed without removing it; then you ran version 2 of emc which tries to create a shm segment of N+M bytes, which fails
[20:58:21] <micges> exactly
[20:58:52] <jepler> if you can determine the number of the segment you can remove it with ipcrm just like the cleanup script does
[21:01:24] <CIA-62> EMC: 03jepler 07master * r73e85857af0e 10/src/rtapi/sim_common.h: report errors in rtapi_shmem_new better
[21:02:35] <micges> jepler: those rtapi prints needs \n
[21:04:36] <jepler> doh, I wish you'd told me that a minute ago :(
[21:05:16] <micges> I didn't know you add it so fast
[21:05:46] <jepler> it's ok
[21:05:50] <CIA-62> EMC: 03jepler 07master * r11f09ec3cf9b 10/src/rtapi/sim_common.h: without newlines, errors don't print right
[22:07:59] <micges> jmkasunich: around?
[22:08:20] <micges> I have some question to your teleop-notes