Back
[01:03:43] <jmkasunich> hi guys
[01:03:57] <jepler> hi jmkasunich
[01:04:12] <jmkasunich> reading back: I _really_ don't want to get into "building a distro to go with EMC"
[01:04:23] <jmkasunich> we already know someone who took that route
[01:06:06] <jepler> yeah me either
[01:14:05] <jmkasunich> I also saw a discussion about unified config data, probably using XML
[01:14:20] <jepler> I missed that one
[01:14:37] <jepler> if I was changing halcmd for "something better", I'd never choose xml in a billion trillion years
[01:14:38] <jmkasunich> it was eariler
[01:14:57] <jmkasunich> that long eh?
[01:15:02] <jepler> pretty long
[01:15:38] <SWPadnos> XML has the advantage of providing for multiple sets of data in a signle file
[01:15:47] <SWPadnos> it has the disadvantage of being butt ugly to look at
[01:15:53] <jmkasunich> right
[01:16:01] <SWPadnos> bbiab - SWMBO calls
[01:16:01] <jmkasunich> ( I was gonna say the same thing with more words)
[01:16:37] <jepler> I don't care to change from the .ini format to something else (though if it is API-compatible then I could choke it down)
[01:16:45] <jmkasunich> jepler: dunno about you, but I think XML beats the socks of of my homemade format for vcp
[01:16:47] <jepler> I would like to see halcmd get support for at least arithmetic, and maybe looping
[01:17:30] <jmkasunich> did you notice the message to emc-dev from Eric Johnson?
[01:17:36] <jepler> i haven't read emc-dev today either
[01:17:52] <jmkasunich> among other things, he talked about pulling the "do_<hal-command>" parts of halcmd.c into a library
[01:18:06] <jmkasunich> we could retain the existing parser and language, and let it call a lib
[01:18:07] <jepler> yeah
[01:18:20] <jepler> once that's done it's not much work to expose it to (say) tcl
[01:18:28] <jmkasunich> then some other parser (perhaps one that know all about emc and is not generic) could also call the api
[01:19:05] <jmkasunich> originally halcmd was just supposed to be a thin wrapper around the hal_lib api
[01:19:18] <jepler> give headroom to all step generators: for {set i 0} {$i < 3} {incr i} { setp stepgen.0.maxvel {1.1 * [getp axis.0.maxvel]} }
[01:19:24] <jmkasunich> but that api isn't adequate for configuring systems
[01:19:34] <jepler> otoh that's pretty gross
[01:19:37] <jmkasunich> its adequate for components (parts of systems)
[01:19:38] <jepler> my tcl example, I mean
[01:20:58] <jmkasunich> we've talked about adding "math and looping" to halcmd before
[01:21:16] <jmkasunich> (for some value of "we")
[01:21:51] <jmkasunich> the general thought was "why should we be writing a general purpose language that is unique to HAL"
[01:22:11] <jmkasunich> it makes more sense to put hal hooks into general purpose language(s)
[01:22:17] <jepler> yeah -- that's why I bring up tcl, but tcl is not a friendly language to beginners
[01:22:34] <jmkasunich> the simplest case right now is bash
[01:22:46] <jmkasunich> except bash doesn't do math
[01:22:47] <jepler> alias setp='halcmd setp'; alias ...
[01:23:15] <jmkasunich> I don't think you could do your example in bash, unless you get clever and invoke bc or something
[01:23:57] <jepler> yeah that gets ugly too
[01:24:22] <jepler> I *do* like that all the configurations are in one language, I wouldn't want to see a proliferation of languages for machine configuration
[01:24:53] <jmkasunich> ?
[01:24:55] <jmkasunich> they're not in one language
[01:25:04] <jmkasunich> at a minimum you have ini and hal
[01:25:07] <jepler> yes
[01:25:14] <jmkasunich> plus possible xml for pyvcp
[01:25:23] <jmkasunich> and don't forget ladder...
[01:25:26] <jepler> I mean, I don't want to see some people configure their hal in python, others in tcl, others in bash
[01:25:31] <jmkasunich> oh
[01:26:02] <jmkasunich> I think I agree with that
[01:26:36] <jmkasunich> in the earlier discussion, my name was mentioned as an obstacle to unified EMC configs, because I constantly harp on keeping HAL generic
[01:27:11] <jmkasunich> I would not be against EMC specific tools that either pipe commands to halcmd (in hal's language) or directly call the hypothetical halcmd api
[01:27:22] <jmkasunich> as long as we keep the generic language as well
[01:28:11] <jmkasunich> there are large classes of emc machine configs that don't need the full capability of hal
[01:28:14] <jmkasunich> and others that do
[01:28:59] <jmkasunich> we've _almost_ managed to let novices avoid editing hal files, by doing variable substitution from the ini file
[01:29:07] <jmkasunich> but it seems they still need to do it once in a while
[01:30:19] <jepler> without a gui configurator that is either massive or inflexible (or both) you can't avoid it
[01:30:27] <jepler> I don't plan to spend my development hours there
[01:32:04] <jmkasunich> I think I agree
[01:32:37] <jmkasunich> if I _was_ inclined to work on a gui configurator, it wouldn't be emc specific (of course), so it wouldn't be what rayh and others want
[01:32:49] <jmkasunich> (it would be the schematic->hal translator)
[01:34:13] <jmkasunich> btw, while I really appreciated the time you spend on hallejulia, I think the hal->schematic approach has "issues", and would rather go the other way
[01:35:16] <jmkasunich> and that probably means starting with an existing schematic editor (or at least an existing drawing program) because there is no reason to reinvent that particular wheel
[01:35:43] <jepler> having started from that direction and felt a roadblock when I wanted to 'output' back to HAL, I appreciate that point of view
[01:36:00] <jepler> the hallelujah direction, that is
[01:36:28] <jmkasunich> I think the reason for a schematic is that the layout on the page reflects the intentions of the human, and a hal->schematic translator can never get that information out of the human's brain
[01:38:01] <jepler> which message from Eric Johnson did you mean earlier? the one about a UI on a small text LCD?
[01:38:08] <jmkasunich> yeah
[01:38:16] <jmkasunich> last paragraph talked about the hal lib thing
[01:38:17] <jepler> python python python
[01:38:32] <jepler> that really doesn't sound like a HAL project to me -- more like nml
[01:38:58] <jepler> either way he can write it in python and stop his hand-wringing
[01:38:59] <jmkasunich> yes, the entire first part of the message is about the LCD and NML is the way to go
[01:39:14] <jmkasunich> the last paragraph is an aside into hal land
[01:39:26] <jepler> because of i2c and parallel?
[01:39:35] <jepler> he can do serial and usb-serial equally well from pyserial
[01:39:40] <jepler> not so sure about i2c and parallel
[01:40:02] <jmkasunich> I dunno either, and I really don't care ;-)
[01:40:20] <jmkasunich> I latched onto the last part because I think halcmd should not be a 4000 line C file
[01:43:33] <jmkasunich> anyway, I should probalby work on some more man pages - once 2.1 is released then it will be time to talk about this more abstract stuff
[01:46:44] <jmkasunich> oops, I just realized that the farm has been shut down since sunday
[04:04:06] <jmkasunich> arrggh
[04:04:22] <jmkasunich> I just realized that basically none of the HAL drivers have manpages
[17:48:54] <alex_joni> hi :)
[17:50:28] <fjungclaus> So, what channel has to be used for what sort of discussion!? #emc is in reality something like #emc-user?
[17:50:41] <alex_joni> not always
[17:50:52] <alex_joni> there are times when #emc is nothing related to emc
[17:51:11] <alex_joni> simply people talking about all sorts of crap
[17:51:50] <fjungclaus> alex_joni: And yes, I'm still fighting with my irc-client :-)
[17:54:35] <cradek> fjungclaus: sometimes we all hide in here if we want to talk about EMC
[17:55:00] <alex_joni> and we somehow manage to not keep it on topic even in here :D
[17:55:27] <cradek> we do ok...
[18:05:10] <fjungclaus> fjungclaus is now known as fjungclaus-away
[19:45:42] <cradek> skunkworks: if only jmk was here
[19:46:57] <skunkworks> rtfm?
[19:47:17] <skunkworks> or was this the whole adding printing to stepgen?
[19:47:48] <cradek> yes this is the problem that's supposed to help solve
[19:48:34] <SWPadnos> heh. maybe that's why he's opposed to it - he always misses the fun ;)
[19:49:01] <skunkworks> :)
[19:52:59] <SWPadnos> marley is probably a friend of Rafa
[19:53:12] <cradek> (he is rafa)
[19:53:13] <SWPadnos> ah
[19:53:20] <SWPadnos> well, I hope he likes himself :)
[19:55:27] <cradek> INPUT_SCALE = 9.657170449
[19:55:33] <cradek> OUTPUT_SCALE = 10.000
[19:56:06] <skunkworks> he is doing much better - english wise. (if it is rafa.)
[19:56:27] <cradek> haha, the scales on his 3 axes are 20, 40, 9.657170449, and 200
[19:56:30] <cradek> 4 axes
[19:57:51] <awallin> emc needs a cofig-wizard (or maybe cnc-machines should not be idiot-proof...)
[19:58:07] <SWPadnos> better idiots ...
[20:00:16] <cradek> for sanity's sake I have to sit this one out, sorry
[20:00:40] <SWPadnos> any idea on anonimasu's issue?
[20:01:09] <cradek> what was the question? I missed it in the noise
[20:01:48] <SWPadnos> way back, he mentioned that G28 causes following errors on Z
[20:01:59] <SWPadnos> in the course of debugging, he also found that G0 does the same thing
[20:03:22] <cradek> any reason to think it's not just bad tuning? the ferror is only 1mm
[20:03:42] <SWPadnos> it could be
[20:04:22] <SWPadnos> the weird thing is that it seems to work for Z-only moves, including G0
[20:05:04] <cradek> I agree that is odd
[20:05:38] <cradek> wonder what his ferror is (when it's not erroring)
[20:06:22] <cradek> seems I=100 is very brave - I don't think he's done any tuning since all axes (even the rotary) are the same
[20:06:46] <SWPadnos> good question. I hadn't looked that far
[20:07:02] <SWPadnos> I think he's using geckos and the USC in feedback mode, but I'll ask
[20:07:14] <jepler> what should we do about the ini and status buffer "scale"s during 2.2? seems like that's a HAL-only matter now, not used by the core at all
[20:07:45] <cradek> jepler: a few guis (barely) use it
[20:07:50] <SWPadnos> cradek pointed out that it's used by at least one UI to give single step jogging ability
[20:10:27] <jepler> yes, and I'd change that GUI to find the lowest desired jog rate in some other, more explicit, way
[20:10:56] <SWPadnos> sure - that makes sense
[20:12:08] <jepler> is this (wrong) comment still in 2.1? (too lazy to look)
[20:12:10] <jepler> # set output scaling from ini file
[20:12:10] <jepler> # note that these are using PWM_OUTPUT_SCALE - they should
[20:12:10] <jepler> # use OUTPUT_SCALE, but right now EMC2 re-writes that to
[20:12:10] <jepler> # 1 on shutdown for some reason. Once that is fixed, this
[20:12:13] <jepler> # should be changed
[20:12:33] <alex_joni> yes, it's wrong
[20:17:04] <cradek> just for kicks I checked G28 and it doesn't do anything untoward that I can see, just the equivalent of (one or) two G0 moves
[20:17:08] <cradek> SWPadnos: ^^
[20:19:20] <jepler> I can't test this patch:
http://emergent.unpy.net/files/sandbox/output-scale.patch
[20:19:31] <jepler> (against 2.1, probably against TRUNK)
[20:19:47] <jepler> but I'd prefer to have what I think is now disinformation removed from the sample configs
[20:23:56] <alex_joni> any reason for the patch to touch ladder?
[20:26:13] <jepler> nope that part is accidental
[20:26:18] <jepler> (oops)
[20:32:08] <alex_joni> jepler: was this a patch for TRUNK or 2.1 ?
[20:32:11] <alex_joni> or both?
[20:32:29] <jepler> alex_joni: I made it against 2.1
[20:32:39] <jepler> it may apply to both, and some form of that patch should probably be applied to both
[20:32:48] <alex_joni> ok, should I apply it, check it for sanity, then commit?
[20:33:01] <alex_joni> (minus the ladder stuff)
[20:33:38] <jepler> if it passes your sanity check, and your "good idea" filter, then I'd like to see it committed
[20:33:50] <alex_joni> good :)
[20:37:59] <rayh> Fascinating. Gedit has a .ini file highlighting mode. View->Others->.ini.
[20:53:19] <jepler> shouldn't the following move to x1y1z0 before moving to 'home'? g0 x1y1z1 / g28 z0 / m2
[20:53:34] <jepler> according to the spec anyway
[20:53:40] <jepler> http://www.linuxcnc.org/handbook/RS274NGC_3/RS274NGC_33a.html#1013246
[20:53:44] <alex_joni> yes, the spec says so
[20:53:49] <jepler> I don't see a move to x1y1z0 in axis
[20:53:52] <alex_joni> go to the position specified, then to home
[20:53:54] <jepler> (mdi'ing everything0
[20:53:58] <jepler> (mdi'ing everything)
[20:54:47] <cradek> that works for me
[20:54:57] <cradek> it goes down to Z0 and then diagonally to X0Y0
[20:55:00] <alex_joni> I wonder why the scale's are commented out in ppmc_motion.hal
[20:55:59] <cradek> jepler: (trunk)
[20:56:24] <cradek> jepler: maybe you have offsets? those are in un-offset coords I think
[20:57:26] <cradek> "The parameter values are in terms of the absolute coordinate system" but it doesn't say what system the XYZ words are in
[20:58:08] <jepler> no, I don't seem to have offsets
[20:58:33] <cradek> I tried twice - I know it works here...
[20:58:55] <jepler> oh -- I still had g91 in effect
[21:00:57] <alex_joni> core_axis.hal doesn't exist anymore.. right?
[21:01:28] <jepler> no, I don't think it exists anymore
[21:01:56] <jepler> it was used to set the "active jogging axis" signals before AXIS got the ability to create HAL pins
[21:02:25] <alex_joni> right.. that's what I remembere
[21:02:27] <alex_joni> d
[21:05:26] <alex_joni> when we do 2.2. we'll get TRUNK to the release status before we branch :D
[21:06:35] <cradek> yeah this has been a pain
[21:13:59] <fjungclaus-away> fjungclaus-away is now known as fjungclaus
[22:17:25] <A-L-P-H-A> rayh, get my memos?
[22:18:24] <rayh> I saw something A-L-P-H-A but didn't see what they were. How do I look at memos?
[22:23:03] <A-L-P-H-A> rayh /msg memoserv help read
[22:29:08] <SWPadnos> argh. you know - that's a good question bob just had - can you disable following error
[22:29:34] <SWPadnos> following error is useless for stepper systems, and causes lots of confusion (though it is one indicator of improper setup)
[22:35:46] <A-L-P-H-A> SWPadnos... boolean, flag.... and maybe a new feature... to create a testing mode... which would test for conditions of an improper setup.
[22:36:26] <SWPadnos> a setup checker was discussed some time ago, and jepler even made a web-based ini generator of sot\rts
[22:36:34] <SWPadnos> -t\
[22:38:42] <skunkworks> he's baackk
[22:51:35] <jepler> SWPadnos: just set ferror and min_ferror bigger than your total travel
[22:51:44] <jepler> (I think)
[22:51:45] <SWPadnos> sure
[22:51:53] <SWPadnos> or just FERROR, and leave MIN_FERROR out of it
[22:52:09] <cradek> if we would add that, people would use it to "fix" their stepper configurations
[22:52:57] <cradek> like rafa/marley/bob, for instance
[22:54:43] <SWPadnos> like I said. it's not useful except that it points out problems in their configs (sometimes, and only some kinds of problems)
[22:55:03] <cradek> or software bugs
[22:56:09] <SWPadnos> well, there is that
[22:56:31] <cradek> it's kind of nice to have a closed loop through stepgen to detect all kinds of software bugs and misconfiguration
[22:57:05] <cradek> if we can make misconfigurations give a better error message (which I think is already done) it should NEVER trigger except for software bugs
[22:57:51] <SWPadnos> I think the only misconfiguration it can detect is improper BASE_PERIOD
[22:58:10] <SWPadnos> (relative to max vel settings)
[22:58:18] <cradek> I think all the timing settings will trigger it too
[22:58:28] <cradek> like step duration: 1 second
[22:58:43] <cradek> (I think)
[22:58:49] <cradek> would have to look to be sure
[22:59:17] <SWPadnos> sure - the general problem is "max attainable step rate is lower than max requested (-able) rate"
[22:59:28] <cradek> yes
[22:59:44] <cradek> what else triggers the FE?
[23:00:37] <SWPadnos> FE set too low? :)
[23:00:47] <cradek> true
[23:00:53] <cradek> what are we arguing about again? :-/
[23:00:55] <cradek> I need a nap
[23:01:15] <SWPadnos> for a stepper system, I can't think of anything else that the ferrors help with
[23:01:15] <SWPadnos> heh
[23:01:32] <jepler> stepper + stepgen
[23:01:51] <jepler> stepper + hardware step generator + PID is another way to get following errors
[23:01:54] <jepler> .. apparently
[23:02:04] <SWPadnos> even stepper+USC, with feedback coming from the step outputs
[23:02:29] <cradek> you clearly want FE detection with an external step generator
[23:03:07] <SWPadnos> yeah, though you need PID as well, sort of (to make sure you reach the endpoint)
[23:03:13] <cradek> I guess I don't see any reason to disable it. I don't know why you would NOT want to know if you're off the path for whatever reason
[23:03:37] <jepler> I am inclined to think the USC HAL driver would benefit from a position-input mode (when its step outputs are looped to feedback inputs)
[23:03:38] <SWPadnos> sure - that's fair enough
[23:03:55] <SWPadnos> there are switches on the USC that do this
[23:04:35] <jepler> yes but the HAL driver still takes a velocity input
[23:05:20] <jepler> this new mode in the HAL driver would get rid of the PID component and have the same kind of tuned feedback that the stepgen component has
[23:11:28] <SWPadnos> ah - ok
[23:48:35] <fjungclaus__> fjungclaus__ is now known as fjungclaus-away