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