Back
[07:48:39] <CaptHindsight> skunkworks: any chance that you could run another comparison like
http://imagebin.org/293091 only using a sine and/or a circular pattern vs triangular??
[09:18:25] <awallin> these are tests of the new blending/lookeahead code? any good?
[09:53:13] <CaptHindsight> awallin: it was a comparison to mach
http://imagebin.org/293092
[10:02:50] <awallin> ah ok! this is the setup where mesa hardware is used to log step/dir pulses produced by mach?
[10:25:21] <skunkworks> yes
[10:26:34] <skunkworks> so far - the new tp looks good. I have been running a lot of stuff through it with no issues. (it only does look-ahead on some segment transistions - line-line, tangent line-arc and tangent arc-arc)
[10:27:03] <skunkworks> but he is working on non-tangent line-arc and I think arc-arc
[10:28:10] <Tom_itx> try cutting anything with it?
[10:28:13] <skunkworks> it is pretty impresssive. He falls back to current parabolic blends for unhandled transition...
[10:28:19] <skunkworks> no - maybe today..
[10:28:38] <Tom_itx> i wish he would keep his master current
[10:29:21] <skunkworks> We could mention it to him.. Although - I think it would be pretty painless as the stuff he is touching has not been changed in a long time
[10:29:53] <skunkworks> bbl
[11:02:54] <KGB-linuxcnc> 03Dewey Garrett 05master 56fdc0e 06linuxcnc 10lib/python/pyngcgui.py 10tcl/ngcgui.tcl ngcgui: normalize filenames for tilde expansion * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=56fdc0e
[13:47:22] <automata> TOM_ITX: who is working on the new TP?
[13:49:15] <automata> is there any proposal to use battery backed encoders ?
[13:49:28] <automata> i.e., absolute encoders?
[14:04:19] <pcw_home> I suspect Andy's absolute encoder driver could be made to work here if there were a
[14:04:20] <pcw_home> quadrature mode added (this would probably add ISI support as well)
[14:08:39] <pcw_home> (ISI encoders burst the absolute position out in quadrature when given a reset pulse)
[14:12:30] <pcw_home> and they signal when the burst is done so this is really similar to fetching the absolute count via modbus
[14:12:32] <pcw_home> (or querying a Yaskawa absolute encoder's initial position with a serial link)
[14:26:19] <automata> hi PCW...
[14:29:12] <automata> yup...
[14:29:42] <automata> the issue will be to set that absolute count as the home offset when the homing button is pressed...
[14:30:29] <mhaberler> pcw_home: Amit says this uses the PRU to bang ethernet:
http://www.ti.com/tool/tidep0001
[14:30:54] <mhaberler> if this is generally doable, this could be another axe to solve that fast UDP IO problem
[14:36:11] <pcw_home> anything that talks directly to the Ethernet hardware will be very fast
[14:36:13] <pcw_home> (but not very portable) I suspect packet_mmap will be sufficient
[14:36:14] <pcw_home> (going through the whole stack is actually usable as is but limits us to 1 KHz or so thread times)
[14:37:30] <mhaberler> just mustering the options
[14:37:31] <automata> pcw: about the homing issue with battery backed encoders, is there a way to specify the current motor position somewhere?
[14:37:53] <automata> i.e., specify the current motor position on press of the home button...
[14:37:58] <pcw_home> you would have to ask Andy
[14:39:36] <pcw_home> The thing with absolute encoders is that you don't need to home at all (just go through the initial song_and_dance_
[14:43:52] <automata> this is not true absolute encoder... if the motor is disconnected from the drive... i.e., battery is not connected.. then position is lost and we get an alarm when it is reconnected...
[14:45:03] <automata> also, on startup, we get the current axis position from the drive through modbus ... now how do we set this as the current motor position?
[14:45:35] <automata> without the pulser winding to that position...
[14:46:34] <automata> we need a method to set the home offset on press of a homing button...
[14:47:06] <pcw_home> seems like that should just be done automatically at startup
[14:47:07] <automata> i.e., a new homing mode maybe...
[14:49:43] <automata> if it is done at startup, then when the drive is manually disabled and the motor rotated (without drive power) how can the current position be set on the pos-cmd of the axis?
[14:50:30] <automata> cause pos-cmd also needs to reflect the current location of the axis...
[14:50:52] <pcw_home> why would you disable the drive?
[14:52:20] <pcw_home> and if you do you just need to go through the same absolute position acquisition as you normally do at startup (in the hal file)
[14:53:15] <automata> yes you are correct... we get the absoute position from the drive into HAL.. now the question is how to give it to the motion module?
[14:54:53] <automata> the position can be set for the motion pin axis.xx.pos-fb.
[14:55:14] <automata> But that will result in the motion module trying to generate a move to get there...
[14:55:26] <pcw_home> it probably needs to be fed to a absolute encoder comp (if its generic)
[14:55:28] <pcw_home> or the absolute encoder driver needs to allow external initial position inputs
[14:55:37] <automata> or maybe give a following error
[14:56:34] <automata> that is also correct... the question still remains about how to interface the absolute encoder driver to the motion module...
[14:57:28] <automata> further with an absolute encoder, the axis commanded position (axis.xx.pos-cmd) should also reflect the current position of the motor...
[14:57:44] <pcw_home> Im not sure about motion and homing and how its starts
[14:58:17] <automata> That is where this problem needs to be solved... motion + homing...
[14:59:56] <automata> One solution has been implemented by aschiffer at
https://github.com/aschiffler/linuxcnc/blob/add-hal-ethercat/src/emc/motion/homing.c
[15:00:19] <automata> but this breaks regular homing...
[15:00:33] <pcw_home> sounds like for absolute, motion should set its command to = fb at the start (maybe it does this already)
[15:00:36] <automata> he is doing ethercat with indramat drives..
[15:01:04] <pcw_home> are you sure motion does not set command to FB at the start?
[15:01:20] <automata> yes...
[15:02:53] <automata> The best option would be to add a homing mode... which takes this into account...
[15:02:56] <pcw_home> I suppose this could be handled by a absolute comp (that maintains the needed offset)
[15:03:46] <pcw_home> yeah the home where you are mode
[15:03:50] <automata> it cant be done in a comp... cause the motion module should also reflect the current position... or the absolute encoder is not of much use then!!
[15:05:29] <automata> it should not be done in comp...
[15:06:11] <automata> also in the motion module, there is an explicit place to put this offset... called home _offset...
[15:07:41] <pcw_home> OK then this needs someone brave enough to tackle adding a home mode for absolute encoders to motion
[15:08:35] <pcw_home> is the point of this to avoid having to do a home move?
[15:08:52] <automata> yes...
[15:10:03] <automata> We can have home on startup enabled which will get the current absolute positions from the drive and set them up .. without the motor having to move at all..
[15:10:20] <pcw_home> Yeah
[15:10:57] <automata> and if there were a drive error, press home again and motion knows exactly where you are again...
[15:11:30] <pcw_home> not sure why a drive error should effect the count
[15:12:00] <automata> the motor tends to move a few pulses when a drive is re-enabled
[15:12:24] <automata> so on EStop also you tend to loose position.. albeit by a few pulses...
[15:12:54] <pcw_home> (I would think the quadrature count would be nonvolatile unless you power down the control section of the drive)
[15:13:03] <automata> I disable the drives on estop... but I have also seen ppl cut the power to the drive...
[15:13:50] <automata> some drives tend to accept single power source.. (Case in point, fuji faldic W series)
[15:14:00] <pcw_home> well if you cut power to the drive/linuxcnc will fault so has to go through re-homing anyway
[15:14:04] <automata> also delta asda series
[15:14:13] <automata> panasonic liqi series
[15:14:50] <automata> all can use a single power source with the control supply derived internally from the motor power
[15:15:11] <pcw_home> so there still is a absolute encoder comp needed + mods to motion
[15:15:11] <automata> yup...
[15:15:55] <automata> yes... that is true... absolute encoder comp is needed.. but the home_offset needsto be maintained by motion
[15:16:14] <pcw_home> thats convenient but painful to lose position on estop
[15:16:41] <automata> the comp will take care of presenting the current location to the motion module...
[15:17:19] <pcw_home> so homing in this case means acquiring the initial position
[15:17:28] <automata> You also tend to loose position if you just disable the drive and re-enable on e-stop
[15:17:49] <automata> yes.. that is what homing will mean ...
[15:17:55] <pcw_home> that a problem with the drive IMHO
[15:18:24] <automata> no.. that is a physical problem...
[15:18:34] <pcw_home> no excuse for that if encoder and control power is not lost
[15:20:06] <automata> as soon as the motor shaft looses power, the shaft will tend to settle in some position.. on re-enable. the drive will set the commanded position to the current encoder position (which has already moved since the e-stop was pressed)
[15:20:43] <pcw_home> bad design...
[15:20:51] <automata> so you always loose a few pulses when a drive is disabled and enabled... it is more of a physics issue than a drive issue
[15:21:45] <automata> even on a motor with brake , this tends to happen...
[15:21:54] <pcw_home> not if everyone maintains their counts
[15:22:27] <pcw_home> only a design that lost encoder signals on estop should do this
[15:23:18] <automata> So again we come back to a method to tell the motion module the current encoder position after estop
[15:23:39] <automata> which is for most practical purposes homing...
[15:24:20] <automata> motion also has a setting where the axis can be un-homed on estop... so after estop, you have to re-home...
[15:24:53] <automata> this is especially a problem with stepper systems... and any setvo driven by pulse and direction...
[15:25:45] <pcw_home> a position mode drive with step and dir yes
[15:26:06] <automata> yup... position servos with step and dir...
[15:27:50] <pcw_home> if you could run them in velocity mode (and they didnt lose encoder output when disabled) then re-homing would not be required
[15:28:04] <automata> sure..
[15:28:38] <pcw_home> dont know if any drives do velocity mode step/dir
[15:28:42] <automata> but what if after estop, the axis was manually moved away...
[15:29:16] <automata> then what would happen on re-enable...
[15:29:54] <automata> will the axis try to go to the commanded position (which has not changed since before the estop)?
[15:30:08] <automata> that may give rise to following error...
[15:30:28] <automata> or will it set the commanded position to the encoder value...
[15:30:57] <pcw_home> Thats a good question, I think thats OK
[15:32:06] <automata> it the commanded position is set to the encoder value (uing an offset)... then that would be a good offset to store the absolute encoder offset!!
[15:35:37] <pcw_home> Pretty sure this is done otherwise you would always have a bang at drive enable
[15:35:59] <automata> yup...
[15:36:05] <automata> looking for that...
[15:43:09] <automata> found it...
[15:44:07] <automata> control.c (799) : tpSetPos(&emcmotDebug->queue, emcmotStatus->carte_pos_cmd);
[15:49:36] <automata> PCW any eta on 5i24?
[15:50:01] <automata> also, is there a 6i24 planned?
[15:55:55] <pcw_home> 5I24 is available except we don't have brackets yet
[15:57:01] <pcw_home> 6I24 is in progress (and 7I24 which is cabled PCIE version)
[18:53:55] <dgarr> seb_kuzminsky: is this a correct way to add a udev rules file to a deb package?
http://www.panix.com/~dgarrett/stuff/0001-xhc-hb04-udev-rules-file.patch
[21:13:14] <skunkworks> logger[mah]:
[21:13:14] <logger[mah]> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-02-16.html
[21:29:28] <micges> skunkworks: pcw_home: raw_sockets in hm2_eth works about 50% faster than normal
[21:30:13] <skunkworks> wow - quite an improvement
[21:31:16] <pcw_home> Sounds good, Are the large latency spikes reduced?
[21:32:23] <pcw_home> (hoping some of that is from traversing so many kernel functions with normal network stack)
[21:33:02] <micges> I'll check in a moment
[23:02:25] <KGB-linuxcnc> 03Dewey Garrett 05master aa05c93 06linuxcnc 10lib/python/pyngcgui.py 10tcl/ngcgui.tcl ngcgui: support tilde expansion in PROGRAM_PREFIX * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=aa05c93