Back
[19:12:11] <jmkasunich> hi cradek
[19:12:36] <cradek> hi
[19:13:00] <jmkasunich> reading back I saw MichelG talking about another stepgen bug
[19:13:03] <jmkasunich> but no details
[19:13:07] <cradek> uh-oh
[19:13:19] <cradek> what time was it?
[19:13:49] <cradek> ah 10:33
[19:13:50] <jmkasunich> 11:32 my time
[19:14:10] <cradek> estop loses steps?
[19:14:15] <cradek> another abort problem maybe
[19:17:34] <jmkasunich> if the stepgen is disabled, stepping stops immediately without a decel period
[19:17:52] <cradek> ouch
[19:18:12] <jmkasunich> IMO, thats what the stepgen should do - the HAL disable pin in intended as an estop
[19:18:17] <cradek> well someone might argue that's a feature
[19:18:25] <jmkasunich> estops should be as quick as possible, and that means no ramping
[19:18:39] <cradek> yeah
[19:19:09] <jepler> new version:
http://emergent.unpy.net/index.cgi-files/sandbox/halgui.py
[19:19:11] <jmkasunich> if EMC considers abort to be something other than estop, then the motion controller should ramp the position command to a stop before turning off axis.0.amp-enable (or whatever its called)
[19:19:25] <jepler> saves and loads positions of components and wires, and reacts "sanely" if a signal changes over a reload
[19:19:35] <jepler> example postscript output:
http://emergent.unpy.net/index.cgi-files/sandbox/HALLELUJAH.ps
[19:19:59] <jmkasunich> ohh, postscript
[19:20:13] <jmkasunich> (one of my questions was gonna be "can the image be printed)
[19:20:55] <cradek> nifty
[19:21:42] <jmkasunich> what do I need to do to play with it?
[19:22:10] <jepler> download it. make sure 'halcmd' is in your path, and run it: python halgui.py
[19:22:31] <jepler> it saves the layout info to the file HALLELUJAH and postscript to HALLELUJAH.ps whenever you exit
[19:22:57] <jepler> left button for actions, control-left-button to undo bends on a signal
[19:23:58] <jepler> if you change some signals in hal (e.g., link*, unlinkp) then hit ctrl-r to "reload" and see the signal change in halgui
[19:24:21] <jepler> it doesn't see new components without an real exit/restart cycle
[19:25:20] <Skunkworks1> I would assume that an estop would lose steps. The abort should not. If I panic - I want the machine to stop (I don't care if Ihave to rehome it.) The abort sould be - non step loss.
[19:25:44] <cradek> Skunkworks1: I guess that's how I feel too
[19:26:35] <Skunkworks1> (turbocnc doesn't have an abort - just and estop. I love to be able to exit out of motion without losing steps.
[19:26:46] <Skunkworks1> in emc2)
[19:32:51] <jmkasunich> jepler: I managed to get a line that ends in the middle of nowhere
[19:34:15] <jmkasunich> doesn't seem to be repeatable though - ctrl-left deleted it, and when I did the same thing again it worked correctly
[19:34:23] <jmkasunich> forget I said anything
[19:34:30] <alex_joni> hi jmk
[19:35:16] <jmkasunich> is ctrl-left supposed to delete the corner I'm pointing at, or all corners in the line?
[19:36:14] <jmkasunich> hi alex
[19:36:33] <alex_joni> finished your meetings?
[19:36:43] <jmkasunich> yeah, I got back friday evening
[19:37:12] <alex_joni> nice..
[19:37:45] <jepler> jmkasunich: all the corners, for now
[19:37:53] <jmkasunich> ok
[19:38:09] <jepler> I've seen the "line to the middle of nowhere" thing too
[19:38:23] <jepler> it seems like it shouldn't happen...
[19:38:26] <jmkasunich> it seems painfull to have to invent the entire graphical editor from scratch
[19:39:26] <jepler> yes it is
[19:39:38] <jmkasunich> maybe less painfull than learning enough about another code base to use the parts we need?
[19:39:50] <jmkasunich> I had thought about using gEDA
[19:40:19] <jmkasunich> http://www.geda.seul.org/
[19:42:38] <alex_joni> * alex_joni remembers trying to get geda to run
[19:42:41] <alex_joni> painfull too
[19:46:33] <jmkasunich> another possibility:
http://www.lis.inpg.fr/realise_au_lis/kicad/
[19:48:20] <SWPadnos> gschem looks nice enough, but the main issue is how to figure out what to draw (especially on a machine that doesn't have the hardware you want to configure)
[19:49:19] <jmkasunich> there are two approaches to a hal gui
[19:49:24] <SWPadnos> schematic capture programs have the advantage of a predefined library of conponents (plus the ability to create new ones)
[19:49:28] <alex_joni> library or live
[19:49:30] <jmkasunich> one is to read the hal config and draw that, then modify it
[19:49:39] <jmkasunich> the other is to draw the config first, the load it
[19:50:03] <SWPadnos> right. in case 1, you can't look at components that represent hardware you don't have
[19:50:12] <jmkasunich> correct
[19:50:25] <SWPadnos> in case 2, you need a library, or a way of getting drivers to generate library components on the fly
[19:50:34] <SWPadnos> (or at make time)
[19:50:40] <jmkasunich> otoh, case 1 correctly deals with components that export different pins under differnt circumstances
[19:51:00] <alex_joni> I like jeff's approach
[19:51:12] <alex_joni> having a live system, augmented by additional info
[19:51:12] <SWPadnos> yes, though there's a solution I have in mind that would also povide another capability for emc/HAL
[19:51:23] <jmkasunich> I was originally thinking in terms of draw first, then load into the system (version 2)
[19:51:33] <SWPadnos> yeah - I think it's great - I'm just thinking about the future :)
[19:51:36] <jmkasunich> that is the traditional way - you create a schematic, then you build it
[19:52:28] <SWPadnos> right, and the problem is that you can't tell what pins the drivers will provide without library components
[19:52:53] <SWPadnos> the other problem is that there's no way to check a HAL config
[19:53:20] <jmkasunich> yet another possibility:
http://opencircuitdesign.com/xcircuit/index.html
[19:53:23] <SWPadnos> so having a mode that basically says "look for these items, and tell me what doesn't match"
[19:56:08] <SWPadnos> one thing I had considered was having all the detection code in userspace, and have it load kernelspace drivers with very explicit configurations
[19:59:45] <jepler> to get the configuration data from another source, you have to replace 3 functions: halcmd_show_pin, halcmd_show_param, and halcmd_netlist.
[20:00:51] <SWPadnos> those functions are in halelujah?
[20:01:14] <SWPadnos> err -halgui
[20:01:15] <jepler> yes
[20:01:47] <SWPadnos> ok. so that's the easy part, and implementing all the new code would be the hard part ;)
[20:02:35] <SWPadnos> what I'd like to see is documentation with each driver, which has a pin/parameter/function definition for eack functional item the driver can provide
[20:02:37] <SWPadnos> each
[20:03:05] <SWPadnos> so blocks would have many of these, parport would have ~3 (the port modes that are available)
[20:03:37] <SWPadnos> ppmc would have one for each type or product it supports (USC, UPC, servo drive ...)
[20:03:42] <SWPadnos> s/or/of/
[20:05:00] <SWPadnos> a userspace app like halgui could look at those definitions (sort of like the ones comp now generates), and can generate "library parts" from them
[20:05:57] <SWPadnos> so you might put 3 USC's on the canvas, and hope that's what is plugged in when the driver is loaded
[20:21:16] <jmkasunich> axis doesn't have an abort button does it?
[20:21:45] <alex_joni> Esc should work
[20:25:28] <jmkasunich> I don't know what MichelG is seeing
[20:25:41] <jmkasunich> esc stops the program, but it doesn't disable the axis
[20:26:03] <jmkasunich> machine off disables the axis, and _does_ result in commanded velocity going to zero instantly
[20:26:16] <jmkasunich> so machine off could result in lost steps
[20:30:18] <jmkasunich> guess I gotta try it with TkEMC
[20:30:29] <jmkasunich> that has a button specifically labeled "abort"
[20:30:33] <alex_joni> jmkasunich: don't bother
[20:30:39] <alex_joni> it does the same as Esc on AXIS
[20:30:52] <alex_joni> it aborts, no machine off, no disabled stepgens
[20:31:02] <jmkasunich> ok
[20:31:15] <jmkasunich> so we'll have to wait for him to come back and explain
[20:31:17] <alex_joni> only F1/F2 during a move could do that
[20:31:48] <jmkasunich> so abort on tkemc is basically the same as pause?
[20:31:59] <alex_joni> no
[20:32:05] <alex_joni> it works in mdi and manual too
[20:32:18] <alex_joni> it generates a TpAbort in the end
[20:33:24] <alex_joni> quick question..
[20:33:39] <alex_joni> how would you guys feel if I tackle the ini & mm/inch unit thing
[20:33:58] <SWPadnos> in what way?
[20:34:13] <alex_joni> I will need to check the code first, but I'm thinking about one single setting that can take a literal 'mm' or 'inch'
[20:34:17] <SWPadnos> I mean - I'd love it, but what's the problem? ;)
[20:34:23] <SWPadnos> ok
[20:34:29] <alex_joni> if it's not a literal, then an float value to set the units
[20:34:45] <jmkasunich> so no more "0.0395234203940918642908570965720938"
[20:34:49] <alex_joni> if this single setting does exist, then all the other can be missing
[20:34:53] <alex_joni> set it only once
[20:35:03] <alex_joni> if it doesn't exist, then do it like previously
[20:35:11] <SWPadnos> for hobbyist machines, it would be good to allow for axes that have different base units
[20:35:22] <jmkasunich> SWP: why?
[20:35:32] <alex_joni> SWPadnos: I'm thinking master setting, overrideable by any other possible settings
[20:35:33] <SWPadnos> in case ebay yields some metric and some imperial screws, for instance
[20:35:40] <jmkasunich> thats not a reason
[20:35:41] <SWPadnos> alex_joni, ok -that would be great
[20:35:45] <jmkasunich> scale numbers can be floats
[20:35:54] <SWPadnos> but they
[20:35:59] <jmkasunich> units should be consistent in an ini file
[20:36:16] <jmkasunich> in fact, the TP might get very unhappy if you mix units
[20:36:23] <SWPadnos> but the floats are checked for being close to one of the "standard" values, then the machine is set to inch or mm anyway
[20:36:29] <alex_joni> they do get converted anyways
[20:36:36] <jmkasunich> huh?
[20:36:46] <alex_joni> SWPadnos: not really
[20:36:48] <jmkasunich> we're talking about different things here
[20:37:06] <SWPadnos> I saw some code that did that, for one reason or another (I don't know why offhand)
[20:37:09] <jmkasunich> there is one thing called units that tells emc whether its using inchs or mm internally
[20:37:32] <jmkasunich> but its done in a weird ass way, to allow for insane people who use furlongs or angstroms or rch's
[20:37:47] <jmkasunich> then there are the scale numbers that convert steps per "unit"
[20:38:14] <jmkasunich> the scale numbers can be floats, so even if you have a metric screw, you can specify the scale in steps per inch (or vice versa)
[20:38:18] <SWPadnos> OT: are radians supported in G-code?
[20:38:31] <jmkasunich> no clue
[20:38:35] <SWPadnos> ok
[20:39:11] <SWPadnos> I wonder what happens if you specify different length units for different axes right now
[20:39:28] <jmkasunich> good question
[20:39:29] <alex_joni> SWPadnos: it works
[20:39:40] <jmkasunich> even for coordinated moves?
[20:39:40] <SWPadnos> what does that mean? ;)
[20:39:42] <alex_joni> they get converted to the [traj] units I think
[20:39:55] <alex_joni> during ini_axis I think
[20:40:04] <alex_joni> so further on it will use the internal 'units'
[20:40:19] <SWPadnos> ok. if that's so, then retaining that "feature" would be a good thins
[20:40:19] <jmkasunich> internal units == trag units ?
[20:40:25] <alex_joni> but.. I might be wrong
[20:40:27] <SWPadnos> which you plan to do, just making the setting optional for each axis
[20:40:29] <alex_joni> I need to study the code
[20:40:37] <alex_joni> SWPadnos: right
[20:41:10] <alex_joni> ok, so it's worth pursuing I guess
[20:41:12] <jmkasunich> the units that are used internally are the units that appear on the HAL pins
[20:41:26] <jmkasunich> and I can't see where any translation gets done - I think all axis uses the same units
[20:41:47] <alex_joni> jmkasunich: if that's true, I'll try to fix it with the same occasion
[20:42:38] <alex_joni> but for now I'm off to bed.. drove a bit this weekend
[20:42:40] <jmkasunich> I can't imagine why you'd want differnet units per axis
[20:42:40] <alex_joni> night all
[20:42:42] <jmkasunich> goodnight
[20:43:06] <SWPadnos> see you Alex
[20:43:11] <alex_joni> jmkasunich: can't see why either..
[20:43:37] <SWPadnos> the only possible reason I can fathom is the scrounged screws scenario
[20:43:45] <SWPadnos> but it's not necessary even them
[20:43:47] <SWPadnos> then
[20:43:52] <jmkasunich> when scale was an integer that might have made sense
[20:43:53] <jmkasunich> not now
[20:44:05] <alex_joni> was scale ever an int?
[20:44:10] <SWPadnos> right
[20:44:12] <jmkasunich> dunno
[20:44:20] <SWPadnos> before there were floats ;)
[20:44:21] <jmkasunich> I thought maybe it was in emc1
[20:44:23] <alex_joni> wonder how you express 0.03937007874016
[20:44:33] <alex_joni> and I know that was in emc1 too ;)
[20:44:34] <SWPadnos> 10/254
[20:44:40] <jmkasunich> thats not scale, thats units
[20:44:57] <alex_joni> jmkasunich: right
[20:45:08] <alex_joni> but I remember using floats for scale too
[20:45:15] <jmkasunich> ok, my mistake
[20:45:20] <alex_joni> maybe early emc1 was different though
[20:45:48] <jmkasunich> I'm no emc1 expert, it might have been a float
[20:52:04] <alex_joni> there are a few other things wrong in the ini too..
[20:52:24] <alex_joni> conceptually wrong I mean
[20:54:14] <SWPadnos> loike what?
[20:54:17] <SWPadnos> like
[20:54:38] <alex_joni> like mixing axes with joints ;)
[20:54:55] <SWPadnos> heh
[20:55:19] <alex_joni> we have axes in the ini , but for nontriv machines they are really joints
[20:55:30] <alex_joni> except the TRAJ which is for the carthesian space
[20:59:32] <alex_joni> also, we can specify if an axis is linear or rotary
[21:00:08] <alex_joni> however, there are places where it get assumed.. so it shouldn't really matter
[21:03:00] <SWPadnos> yeah - I noticed that there's no support for UVW axes
[21:03:51] <alex_joni> and if you have a XZC machine.. you're in trouble
[21:04:12] <alex_joni> you need to define that as a XYZABC machine, and simply not use YAB
[21:04:23] <SWPadnos> also, the sample line for AXES is wrong - X Y Z R P W isn't corerct in any case, AFAICS
[21:04:48] <SWPadnos> correct, either
[21:11:28] <SWPadnos> argh - I just screwed down this motherboard into the case, and I forgot to attach the CPU heatsink retainer
[22:50:25] <rayh> logger_devel, bookmark
[22:50:25] <rayh> See
http://81.196.65.201/irc/irc.freenode.net:6667/emcdevel/2006-09-24#T22-50-25