Back
[01:50:33] <cradek> jepler: I think the shop is closed for the night but I will try them soon, thanks
[01:51:03] <cradek> cut a bunch of aluminum tonight and my coolant smells 'off' already - ack.
[01:55:23] <jepler> yuck .. ok
[02:07:22] <CIA-13> EMC: 03seb 073x20 * r99b4a214a515 10/docs/man/man9/hm2_pci.9: note that the 3x20 is now supported
[03:55:47] <CIA-13> EMC: 03cradek 07master * r8351f71227d3 10/src/emc/usr_intf/touchy/design.notes: remember that this might be nice to do sometime
[04:26:57] <Dave911> 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.
[04:37:04] <cradek> since emc2 uses double precision floating point throughout it really doesn't have that problem
[04:37:50] <cradek> the quantization of your encoder counts is a much larger error than the precision of the internal numbers
[04:38:51] <Dave911> OK, good to know. I thought it might use single precision or something even different. Thanks!
[04:39:12] <cradek> in the old days, HAL was single precision. it is now double throughout.
[04:39:23] <cradek> EMC's internals have always been double.
[04:43:03] <Dave911> 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! :-)
[04:44:56] <cradek> seems like you might still get encoder count rollover in that case - something to think about
[04:58:31] <Dave911> Is the encoder count not a double precision #?
[04:58:43] <cradek> encoder count is not floating point at all
[04:59:13] <Dave911> Is that just a 32 bit int?
[04:59:56] <cradek> I think that depends on the driver
[05:02:05] <Dave911> 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.
[05:02:52] <cradek> some or all of the drivers may handle rollover correctly - I don't know the details
[05:04:18] <Dave911> 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...
[05:04:20] <Dave911> OK, I have more to think about... Thanks Mr. Cradek.. :-)
[05:04:36] <cradek> welcome, goodnight
[05:04:49] <Dave911> goodnight
[12:53:29] <jepler> hm, hm2 appears to use 32 bit counts for encoders, so with a 4000 PPR encoder after only around 500k revolutions :(
[12:54:32] <jepler> 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.
[13:40:21] <Dave911> Well I was thinking about using stepgen so I might be all set. :-)
[13:40:22] <Dave911> 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?
[13:40:24] <Dave911> 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?
[13:40:59] <Dave911> Thanks!
[13:41:32] <alex_joni> Dave911: it sounds feasible, but there are some caveats
[13:41:40] <alex_joni> you need to take care of offsets, etc
[13:41:46] <alex_joni> the HAL positions are motor positions
[13:41:52] <alex_joni> g-code is a whole different thing
[13:42:24] <Dave911> Is that motor position in encoder counts?
[13:42:45] <alex_joni> no, that's a double precision position
[13:42:57] <alex_joni> which is counts * scale for stepgens I think
[13:43:12] <alex_joni> but you still have backlash added and comp applied
[13:43:24] <alex_joni> and other calculations.. so it might be a bit off from what you expect
[13:43:33] <alex_joni> I would do it in g-code using Mxx
[13:44:40] <Dave911> I thought that all motion had to stop before a Mxx was executed. Or am I missing something
[13:45:13] <alex_joni> no, there's a Mxx code that can be blended
[13:45:17] <alex_joni> for this exact reason
[13:45:54] <Dave911> I didn't realize that..
[13:46:56] <alex_joni> G1 X10
[13:47:04] <alex_joni> M62 P1 (turn on output 1)
[13:47:11] <alex_joni> G1 X22.5
[13:47:18] <alex_joni> M63P1 (turn off output 1)
[13:47:22] <alex_joni> G1 X30
[13:47:40] <alex_joni> this move shouldn't slow down at all
[13:49:33] <Dave911> ... that is almost too easy! :-)
[13:49:34] <Dave911> I missed those M commands entirely when I read through the manuals. Thanks Alex, I can test that very easily.
[13:58:09] <alex_joni> Dave911: you can blame me if it doesn't work
[14:02:21] <Dave911> 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.. :-)
[14:04:46] <alex_joni> well.. that's life sometimes
[15:16:31] <skunkworks_> http://groups.yahoo.com/group/mach1mach2cnc/message/115560
[15:18:12] <cradek> looks similar to the setup on one of your machines, if I remember right
[15:19:01] <skunkworks_> yep. No 'blending' issues though.
[15:19:03] <skunkworks_> ;)
[15:19:17] <cradek> well I remember having to fix it for you :-)
[15:19:29] <skunkworks_> There where a few issues initially iirc - but you straitend them out.
[15:19:31] <skunkworks_> heh
[15:46:43] <skunkworks_> http://tech.groups.yahoo.com/group/turbocnc/message/19907
[15:48:27] <cradek> why does the G540 manual talk about EPP mode being required? that's just wrong isn't it?
[15:53:01] <skunkworks_> maybe setting it to epp in the bios is more likely to work as a normal printer port. (no clue)