jepler: I think the shop is closed for the night but I will try them soon, thanks
cut a bunch of aluminum tonight and my coolant smells 'off' already - ack.
yuck .. ok
EMC: 03seb 073x20 * r99b4a214a515 10/docs/man/man9/hm2_pci.9: note that the 3x20 is now supported
EMC: 03cradek 07master * r8351f71227d3 10/src/emc/usr_intf/touchy/design.notes: remember that this might be nice to do sometime
What is the maximum move distance for EMC2 - ie if I do a number of incremental moves when does EMC2 finally have a problem with the position.
since emc2 uses double precision floating point throughout it really doesn't have that problem
the quantization of your encoder counts is a much larger error than the precision of the internal numbers
OK, good to know. I thought it might use single precision or something even different. Thanks!
in the old days, HAL was single precision. it is now double throughout.
EMC's internals have always been double.
I was really thinking of an application that drives a belt and would run in the same direction via incremental moves for a long period of time. Double precision is good for about 5x10**308 so I think the belt will wear out before they run out or they will rehome before they run out of number space! :-)
seems like you might still get encoder count rollover in that case - something to think about
Is the encoder count not a double precision #?
encoder count is not floating point at all
Is that just a 32 bit int?
I think that depends on the driver
OK... I had better look into that. I was thinking about rehoming it after each move anyway - without a search for the home switch - just to make things easier.
some or all of the drivers may handle rollover correctly - I don't know the details
It would be a nice option if I didn't have to worry about that ... but ..... The trick is that most people will never hit the limit ... so testing may be the only way to verify...
OK, I have more to think about... Thanks Mr. Cradek.. :-)
hm, hm2 appears to use 32 bit counts for encoders, so with a 4000 PPR encoder after only around 500k revolutions :(
it uses 48 bits for stepgen counts, so you don't run into trouble before 1.4e11 revolutions for a 2000 counts/revolution microstepping motor.
Well I was thinking about using stepgen so I might be all set. :-)
Different subject .. Is there a way to control an output during motion - ie turn it on at 10" and turn it off at 22.5" - without stopping motion?
It would be nice to be able to do this within Gcode but I don't think it is possible. What about at the hal level? Do some compares on the current position and turn a bit on and off based on the compares? Does that sound feasible?
Dave911: it sounds feasible, but there are some caveats
you need to take care of offsets, etc
the HAL positions are motor positions
g-code is a whole different thing
Is that motor position in encoder counts?
no, that's a double precision position
which is counts * scale for stepgens I think
but you still have backlash added and comp applied
and other calculations.. so it might be a bit off from what you expect
I would do it in g-code using Mxx
I thought that all motion had to stop before a Mxx was executed. Or am I missing something
no, there's a Mxx code that can be blended
for this exact reason
I didn't realize that..
M62 P1 (turn on output 1)
M63P1 (turn off output 1)
this move shouldn't slow down at all
... that is almost too easy! :-)
I missed those M commands entirely when I read through the manuals. Thanks Alex, I can test that very easily.
Dave911: you can blame me if it doesn't work
No, I'll just let you know if it doesn't work :-) I was going to make that problem really difficult. 4 or 5 lines of G code.. Geezz... way too easy.. :-)
well.. that's life sometimes
[15:16:31] <skunkworks_> http://groups.yahoo.com/group/mach1mach2cnc/message/115560
looks similar to the setup on one of your machines, if I remember right
yep. No 'blending' issues though.
well I remember having to fix it for you :-)
There where a few issues initially iirc - but you straitend them out.
[15:46:43] <skunkworks_> http://tech.groups.yahoo.com/group/turbocnc/message/19907
why does the G540 manual talk about EPP mode being required? that's just wrong isn't it?
maybe setting it to epp in the bios is more likely to work as a normal printer port. (no clue)