where are the tarballs of 2.0.0? Of the 3 "ways" linked from http://linuxcnc.org/index.php?option=com_content&task=view&id=22&Itemid=6&lang=en
one is some rambling page, one is to a tarball on viewcvs, and the other is instructions on CVS.
there should be a definitive place to download emc2, and it should probably not be my relatively slow dsl connection.
(not that I've noticed a problem, but this is the first weekday after the release)
jepler, can you add a script to the cvs server that dumps a new tarball on www.linuxcnc.org when there's a new checkin?
then we can link to the copy
jepler: ok, I'll upload one to Sourceforge
Hi guys. Off reading mail.
I'm getting a lot of interest in halui.
Several calls asking how to do it and if it has a specific command yet.
[13:32:43] <alex_joni> http://sourceforge.net/project/showfiles.php?group_id=6744
SWPadnos: I can't add scrips on the CVS server
Any of the commands like those issued by a tk button.
run, pause, abort,
manual, auto, mdi
One guy said he's been waiting years to connect a hard wired control panel
rayh: why didn't he say anything :D
rayh: manual, auto, mdi already work
but the problem is to follow the NIST way (multiple places of control), that means momentary pushbuttons
Yes but halui can easily handle these.
no, I mean that halui NEEDS to work like that in order to make it fit well into emc
there are some things which are HARD to implement as momentary controls
like the feed override slider
if it's a hardware slider, I would use a rotary knob (resistor)
For all of these, I'd like to see a rotary encoder.
but that doesn't follow the NIST way, as the value set by a GUI (tkemc) won't update it
rather than a fixed voltage in.
right, I can see that
easier .. not necessarely (setting up I mean)
rayh: definately something to talk about later today if you care
* alex_joni is still caught up at work right now
I'm writing on emc, baking bread, making soup, and packing stuff for fest.
So I'll be around.
cool.. I just finished doing the release at Sourceforge
jepler: please let me know if www.linuxcnc.org is still somehow unclear, or if you have an idea how to improve it
alex_joni: yeah, it was hard in axis to get the slider to work (be manipulable, but also reflect emc's idea of the feed override if it was changed in some other way)
much easier with software - you don't need motors to move the sliders around ;)
Tkemc still has a goofy slider thing left over from something Fred P did.
SWPadnos: the problem was that the slider would jitter back to the last setting seen in the stat buffer until the set command was acted upon
right - "user experience" issues
those are always annoying
If the "scale" variable was stubbed into HAL, we could/could we use an instance of the encoder counter module to read a rotary encoder and set the value of that pin.
I think that part is pretty easy now. it's things like switches that are harder to deal with
any hardware UI device has to have either a display device for feedback, or powered controls
otherwise there's no indication of current settings
In ladder we could make toggles into one-shots.
But we would need ways to tell the operator that was the case.
but the toggle switch is still sitting in the "up" position, even if something else changes the setting to "down"
seems like you'd want a center-off toggle that's momentary in both directions, along with an indicator
lighted pushbuttons are probably the easiest control/indicator
yeah or that
yep - or a mom-off-mom + lights
or the optimus keyboard ;)
just get a touchscreen sheesh
These are good solutions.
optimus is way cooler
IMO this is an integrator issue.
emc2 is "more customizable than you can shake a stick at"
If an integrator wants/needs to violate the NIST ideal, we should allow that.
they can do what they want, but it 's hard
Hell I had a guy call frustrated the other day cause his axes wouldn't move.
you need mux2's for everythijng, and a way of changing the selector
He even tried a battery box on the servo dynamics cards and nothing.
estop, was pulled and he didn't even see it on the display.
heh - oops
I didn't have the heart to send him a bill.
PEBCAD - Problem Exists Between Chair And Screen
Yep. Probably tension with his switch to emc2.
so rayh how do your customers find out about you? i mean i've never seen any ads for emc2 consulting or anything :)
word of mouth or just dumb luck.
pay no attention to emc2sa.com
that's the other emc2 only it's emc superscript 2.
* alex_joni heads home
rayh: still around?
and not typing very well.
no biggie :)
I had a couple of people screaming at me for the last 3 hours.. so you're excused
yell yell YELL!
err... hi ;)
yuck. irc or for real?
* alex_joni just came home from the opera ;)
but they sang as loud as they could :D
I'd have to bring a walkman or something
SWPadnos: it's really nice, if you can get in the mood to appreciate it
oh the opera.
hasn't happened yet, but I suppose it's possible
I was once. (in the mood)
so.. wanna talk about halui?
let's start with an existing set of signals.
ok, got anything specific on your mind?
Let me get a copy running.
what do i put in [HAL] to do that?
* alex_joni goes look..
these things slip my mind easily :D
HALUI = halui
I think :)
sounds like it.
this isn't fully decided yet, that's why I tend to forget it
because all make sense: [IO] [HAL] and even [DISPLAY]
okay I don't see any parameters for it.
there are no parameters
but quite a few pins.
right.. simple push-button thingies
08 bit -W FALSE halui.flood.is-on
08 bit R- FALSE halui.flood.off
08 bit R- FALSE halui.flood.on
Okay the is-on is the status pin right.
momentary buttons to start & stop flood, and feedback to tell it's on
now I could connect a signal to flood-on
you could.. and you should :D
and make that signal true.
what happens then if tkemc turns flood off.
and it should turn on (and you'll see it on all the GUI's connected), and the iocontrol.0.... should turn on
then is-on will turn false
* rayh tries it.
but remember .. you shouldn't keep the signal = true (although that won't affect the is-on to turning false)
the state of the halui data is changed on a false->true transition, and only then
Right that is exactly my point.
If you wanted a toggle flood on off switch outboard. It would need to turn either on or off
with hal_speaker you sure hear the decel at the joining of colinear moves
but the hardwired switch would not necessarily reflect the state of the third pin.
rayh: you need a lamp for that
and a momentary push-button, that goes to either on or off (based on the state)
you can do that easily in CL
or a simple mux2 will do
or a switch that is centered whenever that signal is false.
I think you would want a button for on and a button for off, or a momentary-off-momentary toggle switch
the toggle would be nicest
cradek: a simple momentary is enough too (toggle is nicest), with a lamp to tell you what's happening
That is easiest, but the point is that a hard wired, hard positioned switch does not violate the nist principle all by itself.
then you connect that to a mux (selection by is-on), and outputs to both on and off
rayh: a hard positioned switch doesn't really fit into the NIST principle.. unless I'm missing something
The nist idea is that a system's state can be read or changed from any of several locations.
The hard wired switch does not show the state properly.
but it does not latch it either.
and it can't be changed
Sure it can. It is only the edge from false to true that is seen on the emc side of halui.
no, I mean you can't physicly change the position of the switch
so an operator looking at it has no way of knowing if that's the state or not
not unless you put an actuator out there that does that when the state pin changes.
to move a switch?
True enough but wait. This is not an emc or hal problem.
I didn't say it was
The fact that the switch does not reflect the true state of emc is an integrator or panel maker problem.
I just said that to confirm with the nist principle, the best choice is to use momentary pushbuttons
that doesn't mean you can't use other buttons
So I don't see why what you have done is not perfectly acceptable to the emc community.
it is.. who said it's not?
Right but that doesn't affect what you have done designing halui.
It affects the way that I might interface to it.
you can interface any way you like :)
The jmk discussion the other night, if I remember it right
he said basicly the same thing.. but with other words
had to do with whether halui had to be written a different way.
oh, probably missed that one..
I think that halui is off to a great start.
I'd like to see active axis for manual mode settable there.
I'd like to see jog increment settable there.
active axis & jog increment are a bit tough..
If I had those two things, I could implement the handwheel for the mazak while at fest.
those aren't global to emc, but they are implemented in the GUIs
That's why I picked on them.
ok, those need to get implemented as a state inside halui
That would certainly be one way.
or extend emc to take care of that, which would complicate the hell out of task, which I'd rather not do
I don't see any reason to complicate task
the jog canon interface is currently so simple, I'm with jepler on that
jepler: as in keep the stuff in halui?
right, that's what I was saying
we all agree
it wouldn't really add much..
so now alex_joni shall implement it
I thought we just agreed I shouldn't do that
oh I'm so confused
* jepler crawls back under the rock where he was snoozing
jepler: busy day ? ;)
too much snoozing?
* alex_joni is about to add another config to HEAD.. hope you guys don't mind
at some point we might want to get choosy about the ones we install as examples
but beyond that I don't care
I don't either
and jmk isn't here
I know he's going to raise an objection about configs in cvs one of these days
cradek: maybe we should group/rename them (trivial_foo, simple_foo, extended_bar)
it's not clear to me how you would use the jog api with a jogwheel.
each pulse from the handwheel implements an incremental jog of xxx distance.
Most of the handwheels I've used do that increment at rapid.
ideally the handwheel would go into emc as position-feedback
I think that's one of the reasons jmk wanted the "delta" output
and then moving it will make emc track it
for the canonical encoder
yeah, I'm not sure you can stack up a bunch of EMC_AXIS_INCR_JOG and get what you want
but if the wheel would count independently, and you poll that count and use INCR_JOG for the difference between this and the last polls, it would probably work fine
that's where the jogwheel software (probably halui) needs to be a little smart - it should change to continuous jog at some velocity
no I think it should always use INCR_JOG
(velocity = pulse rate from the handwheel)
I disagree, the handwheel should be absolute positioning
for instance two spins around = 2 inches
No commercial handwheels don't vary rate of motion based on delta between command and actual.
or whatever scale you want
rayh: I don't understand, are you agreeing or disagreeing with me?
Absolute positioning is my preference but we are working in software here and a single parameter could select the mode for us.
ok I think that's agreeing :-)
Yep. It's late in a days worth of contract reading.
and my head is really heavy right now.
One other thing I'm thinking of is a toggle pin for things like flood.
so I think that's the algorithm, poll the count, and periodically issue an incr jog for the differences
If such a pin existed pressing it would swap state.
incr jog does give soft limit protection.
all jogs do
which a simple x follows handwheel doesn't
I think any movement does
I'm imagining a hal only implementation.
rayh: even the motion controller checks for limits before outputting movement
hal only might be trouble
cradek: you might get lucky and get away with it.. if you're carefull
but you certainly can violate all of the machine constraints
e.g. start moving the handwheel during a move & so on
crash into a wall
motion has a nice scheme for getting to a destination without violating constraints - if we need to add a canon call to update the goal position, we can
but I think we can get by with only incr jog (updates the goal position relatively, which is what we get from an encoder anyway)
cradek: I think halui should only take the delta from an encoder driver
then reset it
a long time ago an incr jog during an incr jog used the start of the second at the point of issue of the second.
that would be fine, the encoder drivers all have resets I think
or well.. make it calc a new delta since the next time
rayh: that's long fixed
rather than appending successive jogs.
(he says without checking)
np we'll get the chance to test it.
I think I might have even fixed it, I know I looked at it
mdi did the same sort of goofy thing.
rayh: what's urgent on halui?
start, stop, pause?
I'd like to implement some buttons on the mazak while there.
fenn: it does that
handwheel, perhaps remote jog buttons, and cycle start.
cycle start = run?
which in that case is a simple run
For now anyway.
Some makers use cycle start even for home.
but we don't need that now.
would you have an encoder per axis for jogs?
some even implement jogs in two steps. select the jog speed and distance and then cycle start.
yuck, that sounds terrible
cradek: or select axis
I think the simple pendant I'm thinking of is just jog buttons.
perhaps axis select
we can do any of those schemes I'm sure
I think halui needs to do the same as iocontrol does
export all kinds of things
and the user/integrator only takes the one he needs/wants
one wheel seems like it might be confusing - which way do I turn it again for the direction I want?
That is my thinking on it.
the maxnc software I used made you select the axis and then push one of the shift keys for +/-
clockwise is plus, counter is minus
I could never get the hang of it, it sucked
I drew arrows with a sharpie on the keyboard and I still would go the wrong way sometimes
although I'd think that could be hal connected as well
I know that feeling.
I *never* go the wrong way with emc's jog keys
sorry, just thinking out loud
ok, I have to go, be back late tonight maybe
rayh: I'll try to do cycle-start (aka run), pause, step & stop in a bit
What do you think of the toggle pin?
you mean for flood on/off ?
you can use it as halui is written now
say your toggle has: TON and TOFF (toggle on & toggle off)
with a block or two four rungs of ladder.
put TON, the flood will turn on
next you select flood off from tkemc
flood will be turned off, even if TON is still selected
I was imagining a single pin that changed the state of flood.
any time it went positive it swapped the state.
you can do that with a single mux2
single pin -> mux2 -> on & off
select on the mux2 from the state
okay you win.
and the repair guy wonders what all those blocks are doing in there.
gotta run to town for a bit. bbl
ok, catch you later..
the alternative would be to have a foo-toggle pin from halui which does that
but that would mean quite a bit more pins
That can wait for 4.2
Hi, I'm a beginner in linuxcnc. My goal is to use it for basix xy stepper table, no problem with this, bur for practice a little more I want to try to command a stepper robot arm. I understand the kinematics definition is in the source code, but I don't really understand the way to redefine it. Is there a documentation that I can start with? Sorry for my english.
globoudou: 1. your english is fine
i believe it uses standard denavit hartenberg notation
2. the kinematics gets implemented in emc2/src/emc/kinematics/
3. you need to port the robot arm kinematics code from emc1
if you want a stepper robot arm, then you probably want to look at the puma kins (those are in emc1, but no reason why they won't work in emc2)
fenn: port=move & adapt makefile
well thats easy eh
i was wrong, it doesnt have a way to change alpha
erm.. *scrambles around looking for a picture*
you mean R ?
[21:18:13] <fenn> http://www.ee.unb.ca/tervo/ee4353/dhxform1.gif
i wonder how well that code works with different tool lengths
globoudou, We could put a french section on linuxcnc.org and give you access if you'd like.
Thanks, it's a good idea. I need to work a little bit on linuxcnc before, and when I've few pages, I'll contact you, I think in few weeks.
rayh: run works from halui ;-)
but pause/resume won't.. investigating now
wow that was quick
ok, I have an idea what's wrong ..
how do you feel about an abort button?
there is no program.stop afaik
Yes I think abort is of real value.
i use abort all the time :)
ok, this works ok.. as long as you don't try to break it
In mini i implemented feedhold/resume using "scale 0" and "scale $oldscale."
it's pretty alpha.. not very rugged
I know a guy who can break most anything.
that's why I said that...
so when you are ready for a real test, I'll show him how to do it.
oh, there is a guy? I thought you were talking about yourself :D
you've gotten to know me pretty well.
yep. but there are a couple of fellows that are even better than I am.
ok, the halui stuff goes in now.. if anything is not 100% .. 'I told you so' :)
thanks for that alex.
I'll get it in a bit and test.