Back
[00:02:04] <alex_joni> ok, think I found the change that caused his
[00:02:06] <alex_joni> this
[00:02:31] <SWPLinux> cool
[00:02:53] <jmkasunich> back from dinner
[00:03:05] <SWPLinux> another strangeness - the first synched move took 4 seconds, later moves are only taking 1 second
[00:03:08] <SWPLinux> rouhly
[00:03:13] <SWPLinux> roughly
[00:03:20] <jmkasunich> spindle accel maybe?
[00:03:37] <SWPLinux> no, the spindle is on throughout
[00:03:49] <jmkasunich> different starting location?
[00:04:09] <SWPLinux> Z0-Z1 and back, same speed in both directions
[00:04:42] <alex_joni> I'm fairly confident it's this:
http://cvs.linuxcnc.org/cvs/emc2/src/emc/task/emccanon.cc.diff?r1=1.122;r2=1.123;f=h
[00:04:50] <SWPLinux> the first move was 4+ seconds, all later ones are 1- seconds (in the 0.96-0.98 range)
[00:04:56] <alex_joni> "more battle with tiny moves"
[00:05:19] <SWPLinux> that looks promiing
[00:05:40] <alex_joni> you can check by commenting " if(vel && acc) {"
[00:05:47] <alex_joni> in flush_segments(void)
[00:06:02] <SWPLinux> vel there should be from the synched calculation, not from the programmed feed rate
[00:06:16] <alex_joni> how about acc?
[00:06:40] <SWPLinux> acc should be calculated from the appropriate vel value, I'd say
[00:07:02] <alex_joni> nope, acc is never calculated in canon
[00:07:22] <alex_joni> I think.. but it's 2am, so take it with a pinch of caution
[00:07:34] <SWPLinux> heh
[00:08:05] <SWPLinux> canon has an acc value there, so it must have access to or calculate acc itself
[00:09:04] <SWPLinux> ok, that is a problem
[00:09:11] <alex_joni> what is?
[00:10:17] <SWPLinux> well, the vel calcs above those lines in the patch just use "well known" values such as currentLinearFeedRate
[00:10:30] <SWPLinux> and of course synch happens in the RT code
[00:10:53] <SWPLinux> I guess just having if ((acc && vel) || synch) might do it
[00:11:01] <SWPLinux> werever the synch var is
[00:11:16] <alex_joni> I think it's feed_mode
[00:11:38] <alex_joni> if(feed_mode == 0) STOP_SPEED_FEED_SYNCH()
[00:12:23] <alex_joni> as you said above: if ((acc && vel) || feed_mode) ..
[00:14:13] <SWPLinux> ok, I can try that
[00:17:21] <SWPLinux> hmmm. that if statement is in several places
[00:17:40] <SWPLinux> like STRAIGHT_PROBE, RIGID_TAP, etc.
[00:18:05] <SWPLinux> do you think it should be replaced everywhere, or just in STRAIGHT_TRAVERSE and flush_segments?
[00:18:52] <SWPLinux> and ARC_FEED
[00:20:15] <SWPLinux> silly question - for RIP/sim, do you need to make install or make setuid?
[00:20:26] <jmkasunich> no
[00:21:33] <SWPLinux> ok - just wanted to be sure I'm executing modified code
[00:21:50] <SWPLinux> well, that didn't work. I wonder if I have the polarity of feed_mode wrong
[00:22:20] <SWPLinux> interestingly though, now I can see a change in speed during the move
[00:22:31] <jmkasunich> during which move?
[00:22:36] <SWPLinux> probably from the ends, where it's blending
[00:22:42] <SWPLinux> g33k0.03z1
[00:22:46] <SWPLinux> g33k0.03z0
[00:22:58] <SWPLinux> after setting F1
[00:23:09] <jmkasunich> where do you see the change?
[00:23:27] <SWPLinux> near the end of the move, just looking at the axis backplot
[00:23:37] <SWPLinux> (not halscope yet)
[00:24:03] <jmkasunich> you are running with MDI? (so each move finishes before you enter the next one)
[00:24:14] <SWPLinux> yes
[00:24:31] <jmkasunich> so its not a move-to-move transition thing like the bobble that started this
[00:24:56] <SWPLinux> nope
[00:25:12] <SWPLinux> though move-to-end may be similar, there's sill accel/decel
[00:25:50] <jmkasunich> I'm a little confused at what you are seeing
[00:26:02] <jmkasunich> if you are doing isolated moves, every one starts and ends at zero velocity
[00:26:07] <SWPLinux> the cone on the axis backplot changes speed visibly
[00:26:25] <SWPLinux> sure, there's got to be accel and decel, but it looks "worse" now )
[00:26:27] <SWPLinux> :)
[00:28:57] <alex_joni> SWPLinux: where did you change the if?
[00:29:03] <alex_joni> in flush_segments() ?
[00:29:35] <SWPLinux> flush_segments, STRAIGHT_TRAVERSE, ARC_FEED, maybe others :)
[00:30:47] <alex_joni> oh
[00:30:54] <alex_joni> there's another place in RIGID_TAP
[00:31:14] <SWPLinux> I think I did that one too, but I'm not sure that makes sense
[00:31:36] <alex_joni> right
[00:31:41] <alex_joni> I'm looking at this:
[00:31:46] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/emc/task/emccanon.cc.diff?r1=1.129;r2=1.115.2.4;f=h
[00:31:59] <alex_joni> TRUNK on the right
[00:32:03] <alex_joni> latest 2.2 on the left
[00:33:31] <alex_joni> can you check out emccanon.cc 1.115.2.4, and try that?
[00:33:42] <alex_joni> that will tell us if it's in emccanon or elsewhere
[00:33:48] <alex_joni> although I'm confident it's here
[00:34:25] <SWPLinux> can you tell me the CVS incantation to get that version of the file?
[00:35:00] <jmkasunich> I'd be tempted to download it from the cvs server webpage
[00:35:04] <jmkasunich> (webcvs)
[00:35:08] <alex_joni> cvs up -r1.115.2.4 emccanon.cc
[00:35:13] <alex_joni> iirc
[00:35:18] <SWPLinux> heh - that is the easy way :)
[00:35:33] <SWPLinux> and then -A or -C or something to reset it to "normal version"?
[00:35:38] <alex_joni> yeah
[00:35:42] <SWPLinux> ok
[00:35:45] <alex_joni> -A
[00:35:48] <alex_joni> START_SPEED_FEED_SYNCH(block->k_number, 0);
[00:35:48] <alex_joni> STRAIGHT_FEED(end_x, end_y, end_z, AA_end, BB_end, CC_end, u_end, v_end, w_end);
[00:35:50] <alex_joni> STOP_SPEED_FEED_SYNCH();
[00:35:55] <alex_joni> that's the code for G33..
[00:38:55] <jmkasunich> it seems like you shouldn't stop sync until you get something that isn't a G33
[00:39:12] <SWPLinux> that version of emccanon doesn't compile wth TRUNK
[00:39:18] <jmkasunich> if there are 2 of them in a row, you'd want to do START_SYNC, STRAIGHTFEED, STRAIGHTFEED, STOP_SYNC
[00:39:44] <alex_joni> SWPLinux: bummer
[00:39:54] <alex_joni> try 1.122
[00:39:57] <SWPLinux> h
[00:40:00] <SWPLinux> heh
[00:40:21] <SWPLinux> nope
[00:40:28] <alex_joni> no compile?
[00:40:37] <SWPLinux> Compiling emc/task/emccanon.cc
[00:40:39] <SWPLinux> emc/task/emccanon.cc: In function ‘void WAIT(int, int, int, int)’:
[00:40:41] <SWPLinux> emc/task/emccanon.cc:2727: error: new declaration ‘void WAIT(int, int, int, int)’
[00:40:43] <SWPLinux> emc/nml_intf/canon.hh:662: error: ambiguates old declaration ‘int WAIT(int, int, int, int)’
[00:40:49] <alex_joni> yeah, that too
[00:40:52] <alex_joni> and W stuff too
[00:41:12] <alex_joni> can you checkout -d2007/11/15 ?
[00:41:20] <alex_joni> but you need to do that from src/ at least
[00:42:30] <SWPLinux> hmm
[00:42:49] <SWPLinux> co -d blah creates a dir named blah. is d overloaded for update?
[00:43:03] <SWPLinux> is that -r2007/11/15 ?
[00:43:27] <alex_joni> -D then
[00:43:32] <SWPLinux> heh, ok
[00:43:39] <SWPLinux> -d is one of the only things I remember ;)
[00:44:12] <SWPLinux> about CVS
[00:52:57] <SWPLinux> heh - funny to listen to the fans change speed on this laptop while doing a full EMC2 compile :)
[00:53:16] <alex_joni> heh
[00:54:05] <SWPLinux> ok, no motion with -D2007/11/15 (assuming that worked right)
[00:55:02] <SWPLinux> same issue - no STRAIGHT_FEED between the synch on/off
[00:55:08] <alex_joni> check what version is emccanon.cc
[00:55:12] <alex_joni> in CVS/entries
[00:55:58] <SWPLinux> 1.123 ;)
[00:56:04] <alex_joni> darn.. 11/15 is after the commit I was after
[00:56:07] <SWPLinux> I guess I needed a little earlier
[00:56:14] <alex_joni> ok, now you should be able to get -r1.122
[00:56:26] <alex_joni> (the rest should be ok to compile the version..)
[00:56:34] <SWPLinux> yep
[00:56:57] <SWPLinux> yes, I get motion with that version
[00:58:27] <SWPLinux> I don't know enough about the queueing of segments - are you sure that feed_mode is correct for the currently being interpreted line? (vs. currently executed)
[00:59:24] <alex_joni> canon shouldn't have stuff about currently executed
[00:59:42] <alex_joni> unless it's specifically supposed to
[01:01:08] <SWPLinux> ok
[01:07:01] <alex_joni> SWPLinux: so it's that commit .. can you test only that change on the TRUNK code?
[01:07:31] <SWPadnos> I can probably accomplish that
[01:08:09] <alex_joni> commenting out the if (vel && acc) in flush_segments()
[01:08:18] <SWPadnos> oh, just that - sure
[01:12:41] <SWPLinux> yep, that works
[01:18:18] <alex_joni> ok, so the issue was with feed_mode
[01:18:46] <SWPLinux> feed_mode = 0, even with synched moved
[01:18:53] <SWPLinux> at least, that's what I've seen so far
[01:19:00] <alex_joni> right
[01:19:13] <alex_joni> I think it gets set for those strange feedmodes
[01:19:27] <SWPLinux> like CSS/FPR?
[01:19:40] <alex_joni> yeah
[01:19:49] <alex_joni> and there was another
[01:20:34] <alex_joni> I don't see any other flag we could use..
[01:22:14] <SWPLinux> yeah - the {START,STOP}_SPINDLE_SYNCH_MODE functions get a velocity_mode parameter, but I don't see it available anywhere
[01:23:31] <SWPLinux> uh - ...SPEED_FED_SYNCH that was
[01:23:34] <SWPLinux> +E
[01:23:49] <SWPLinux> damn, it's hard enough to type without being on a laptop keyboard
[01:41:54] <alex_joni> off to bed for me
[01:41:57] <alex_joni> good night all
[01:42:01] <skunkworks_> night alex
[01:42:04] <alex_joni> SWPLinux: maybe you can bug cradek about this..
[01:42:21] <skunkworks_> * skunkworks_ thinks cradek is hiding... ;)
[01:42:29] <SWPLinux> someone else should remember to do that - I'll be on the road tomorrow and Monday
[01:42:50] <alex_joni> I'll bug him too
[01:42:54] <SWPLinux> I can help though, if I'm around :)
[01:47:45] <SWPLinux> oh, the problem is in STRAIGHT_FEED, not flush_segments
[01:48:20] <SWPLinux> let me test that
[01:49:29] <SWPLinux> hmmm
[07:52:08] <alliancemetal> hi is anyone alive in here?
[07:53:40] <alliancemetal> I'm wondering if anyone has run EMC with a PlasmaCAM system
[07:54:36] <alex_joni> morning
[07:54:56] <alex_joni> alliancemetal: this is the development channel (talk about emc internals)
[07:55:03] <alex_joni> we also have an #emc channel with users..
[07:55:10] <alliancemetal> well
[07:55:15] <alex_joni> maybe you get more lucky there
[07:55:28] <alliancemetal> considering that interfacing with specific controllers would be a development issue...
[07:58:05] <alliancemetal> I dont' think this program will work for me
[07:58:28] <alex_joni> alliancemetal: emc is a software which interprets g-code
[07:58:37] <alex_joni> if PlasmaCAM outputs g-code then it might work
[07:58:51] <alex_joni> but I don't know PlasmaCAM, so I can't comment
[07:58:57] <alliancemetal> yeah.. see
[07:59:05] <alliancemetal> PlasmaCAM software controls the controller
[07:59:21] <alex_joni> that is a quite generic statement..
[07:59:34] <alliancemetal> I can do everything from the computer... move the gantry anywhere I want.. set any setting
[08:00:10] <alliancemetal> alex_joni, I think EMC does a little more than interpret g-code.. unless I'm completely reading this site wrong
[08:00:53] <alex_joni> well, interpret the g-code, convert the stuff to motion commands, and move motors, etc
[08:00:54] <SWPadnos> is there some deficiency in the PlasmaCAM system that you're hoping to find a solution for?
[08:01:05] <alliancemetal> SWPadnos, it only runs in windows
[08:01:29] <SWPadnos> ok
[08:01:39] <alliancemetal> wondering if this program might work
[08:01:50] <SWPadnos> "this program" being EMC?
[08:01:51] <alliancemetal> the fact is.. with the plasmacam software.. it's CAD/CAM
[08:02:00] <SWPadnos> ok, that's the part that EMC doesn't do
[08:02:05] <alliancemetal> ok however
[08:02:24] <SWPadnos> there are applications that let you convert some types of design files to G-code that EMC can run
[08:02:48] <SWPadnos> it's likely that the machine can be made to run with EMC, but it's a big question as to how much of it you'll need to replace
[08:03:03] <alliancemetal> hahaa
[08:03:15] <alliancemetal> so in other words you're telling me this program is worthless
[08:03:32] <SWPadnos> it's likely that the mechanics and motors can be left alone, also probable that the motor drives can be kept, if they're not some proprietary type
[08:03:37] <SWPadnos> no, I didn't say that at all
[08:03:41] <alliancemetal> well
[08:03:49] <alliancemetal> you just said somethign about replacing parts
[08:04:00] <alliancemetal> not gonna happen ever in a million years
[08:04:07] <alliancemetal> that's ridiculous to even suggest it
[08:04:16] <alex_joni> alliancemetal: no point in beeing rude
[08:04:17] <SWPadnos> sure. if you have proprietary hardware that only works with your propprietary software, then there's nothing we can do to help you
[08:04:50] <SWPadnos> since you seem to want to move to a free/open source product (or at least off of Windows), EMC is your best bet
[08:04:52] <alliancemetal> does the site have a list of tested systems and hardware that can be controlled by this program?
[08:05:14] <alliancemetal> alex_joni, ok so don't be rude
[08:05:15] <alliancemetal> :P
[08:05:16] <SWPadnos> any motor drive that accepts a "standard" control signal will work with EMC
[08:05:45] <alliancemetal> so let's say I have a bridgeport prototrak
[08:05:49] <SWPadnos> standard being +/-10V, step/direction, PWM, PWM_riderction, PDM, up/down
[08:05:54] <alex_joni> http://www.plasmacam.com/faq.php#software
[08:06:02] <SWPadnos> you also need an acceptable form of feedback, if you have servos
[08:06:13] <alex_joni> " Our software can create program files in DXF, G-Code or HPGL/2 format."
[08:06:31] <alliancemetal> alex_joni, any reason you're pasting stuff that I already know?
[08:06:34] <SWPadnos> if the machine you have has all these standard parts, then interfacing to EMC should be pretty easy
[08:07:01] <SWPadnos> alliancemetal, you haven't really asked a question except whether we can tell you with absolute certainty what you'll have to do to make EMC run your hardware
[08:07:11] <alex_joni> alliancemetal: I just told you earlier that emc need g-code to run
[08:07:16] <SWPadnos> and we can't do that, because we don't know about that hardware
[08:07:22] <alliancemetal> alex_joni, ok.. look
[08:07:31] <alliancemetal> stop talking about g-code please
[08:07:40] <alliancemetal> because you're talking about EVERY SINGLE CNC/NC machine out there
[08:07:53] <alliancemetal> anything that's worth spending money on anyway
[08:08:18] <SWPadnos> so what is it you're looking for, exactly?
[08:08:34] <alliancemetal> when I go to cut parts..
[08:09:04] <alliancemetal> the plasmacam software not only controls the speed of the X/Y
[08:09:16] <alliancemetal> it controls the Z axis ..digital height control
[08:09:27] <alliancemetal> there's arc tolerance.. and torch trigger control
[08:09:34] <alliancemetal> in other words..
[08:09:43] <SWPadnos> torch height control
[08:09:48] <alliancemetal> right
[08:10:03] <alliancemetal> which is directly related to the arc tolerance setting..
[08:10:06] <SWPadnos> did you look at the EMC wiki?
[08:10:15] <alliancemetal> no.. I didn't
[08:10:18] <SWPadnos> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Torch_Height_Control
[08:10:33] <SWPadnos> start there, then come back if you have more specific questions
[08:11:15] <SWPadnos> and please, try to assume that we aren't idiots - I'll say for myself that you haven't exactly set out on the right foot here
[08:11:23] <alliancemetal> well
[08:11:29] <alliancemetal> you can blame alex for that
[08:11:37] <SWPadnos> Alex is also not an idiot
[08:11:48] <alliancemetal> his repeating stuff about g-code is frustratign
[08:12:01] <SWPadnos> as is your insistence on not actually describing your problem
[08:12:16] <alex_joni> alliancemetal: unless you start describing what you really want, I can only assume things
[08:12:17] <alliancemetal> do you guys have a problem with conversations?
[08:12:21] <SWPadnos> let's all take a breather here. you have reading to do, and I need to get to sleep, it's 1 AM here
[08:12:32] <SWPadnos> no, we're fine
[08:12:46] <alex_joni> oh, we've been discussing in here for over 3-4 years
[08:12:55] <alex_joni> so I'd say _we_'re fine
[08:13:01] <SWPadnos> heh
[08:13:04] <alliancemetal> well why does it always seem that people on IRC have an issue with someone asking questions
[08:13:25] <alex_joni> anyways, by looking at that awfull site a bit, it seems that they sell a couple of things (together called PlasmaCAM)
[08:13:43] <alliancemetal> no need to be rude
[08:13:46] <alex_joni> that involves a GUI for CAD/CAM (not sure if it's a single thing, or 2 different softwares)
[08:13:52] <alliancemetal> considering that the EMC site is horrible
[08:13:58] <SWPadnos> IRC is like fast email, you have no way of jusging the mood of the person on the other end, and you can't see how your phraseology impacts them
[08:14:02] <alliancemetal> and yes the PCAM site is crap
[08:14:19] <alliancemetal> alex_joni, it's a single program
[08:14:21] <alex_joni> alliancemetal: why do you feel offended if I say that site lacks details?
[08:14:27] <alliancemetal> you didn't say that
[08:14:41] <alliancemetal> those aren't the words you used
[08:14:42] <alex_joni> ok, I worded it poorly, I'm sorry
[08:14:48] <SWPadnos> well, I'm headed to bed - night all
[08:14:50] <alliancemetal> you called it an "awful site"
[08:14:52] <alex_joni> night SWPadnos
[08:14:56] <alliancemetal> thanks SWPadnos
[08:15:24] <SWPadnos> it is pretty bad - no real information, strange test that's the same font as the links next to it ...
[08:15:33] <alex_joni> alliancemetal: ok, the website (graphics & layout and all) is ok to me, I just can't find anything specific (something I would like to read on a sales webpage)
[08:15:34] <SWPadnos> but then again, there's a lot of that around
[08:15:46] <alliancemetal> there's a ton of that around
[08:15:50] <alex_joni> describing the product, etc
[08:15:53] <alliancemetal> alex_joni, yes the pcam site is quite nebulous
[08:15:55] <alex_joni> but let's skip that
[08:15:55] <SWPadnos> like the cost, or how to use it, or the speed of the table, or the work envelope ...
[08:16:04] <SWPadnos> oops, I'm going to bed :)
[08:16:16] <alliancemetal> the DHC model is $9000
[08:16:20] <alex_joni> besides the program (which you said is only 1) I think they sell some hardware
[08:16:30] <alliancemetal> yes they sell the table
[08:16:38] <alex_joni> which is the actual cutting table (with servo on X and Y, steppers on Z)
[08:16:55] <alliancemetal> yep ..very powerful servos on X/Y
[08:17:02] <alex_joni> and some control box (which I see in the pics), probably connected to the PC with the GUI via serial?
[08:17:02] <alliancemetal> stepper on Z
[08:17:09] <alliancemetal> ugh.. LPT
[08:17:13] <alex_joni> ok..
[08:17:18] <alliancemetal> I wish they'd go to ETH
[08:17:31] <alex_joni> that is actually the info we would have needed initially
[08:17:36] <alliancemetal> then I could put the computer somewhere not within 10 feet of the system
[08:17:49] <alex_joni> now, what is the thing you want to accomplish?
[08:17:57] <alliancemetal> well
[08:18:00] <alex_joni> replace PlasmaCAM (the GUI)? or the control box?
[08:18:06] <alex_joni> or not replace anything at all?
[08:18:18] <alex_joni> I don't see where emc can fit in that scenario..
[08:18:19] <alliancemetal> actually what I was hoping to find were my Xandros 3.0 discs
[08:18:30] <alliancemetal> came wtih CrossOver Office...
[08:18:35] <alliancemetal> maybe I could run PlasmaCAM in that
[08:18:48] <alliancemetal> I'm just goddamn sick of running Windows
[08:19:03] <alliancemetal> I was one of the founding members of Linux.com for christ's sake
[08:19:11] <alex_joni> hmm.. the question to that depends on what travels through the LPT port
[08:19:16] <alliancemetal> now I'm forced to use Windows just to work
[08:19:42] <alex_joni> if windows controls motors directly through LPT, then I don't think Wine or CrossOver or any other solution will be good enough
[08:19:50] <alex_joni> s/windows/PlasmaCAM/
[08:20:13] <alliancemetal> I want to try.. see if I can initialize the machine
[08:20:14] <alliancemetal> make it move
[08:20:25] <alliancemetal> however I'm afraid of breaking the brain
[08:20:37] <alliancemetal> which would put me in dire straits
[08:20:37] <alex_joni> alliancemetal: before you even think about doing that, you need to know what is sent through the LPT connection
[08:20:57] <alliancemetal> I'm pretty certain that it's gcode
[08:21:13] <alliancemetal> I'll call them on monday and ask
[08:21:15] <alex_joni> that is one thing that PlasmaCAM's website should say, but doesn't
[08:21:36] <alliancemetal> but I can tell you this
[08:21:58] <alliancemetal> the ver that I have does NOT work with an older brain a friend of mine has
[08:22:20] <alex_joni> alliancemetal: my guess is that it's a bit more than simply g-code
[08:22:31] <alliancemetal> well
[08:22:37] <alex_joni> and I bet it's a proprietary protocol, which they won't give you the specs to
[08:22:50] <alex_joni> and reverse-engineering it will probably too much of a job for this
[08:22:53] <alliancemetal> I know another guy that re-rigged his plasmacam to work with a torchmate controller
[08:23:03] <alliancemetal> but that was just for the THC
[08:23:24] <alex_joni> the THC is a simple part (it gives you an up/down signal)
[08:23:52] <alex_joni> if you want to run this with emc2 I would *guess* that the scenario would be the following:
[08:23:58] <alliancemetal> would it help if you had a plasmacam file?
[08:24:28] <alex_joni> 1. hack the machine to some extent (see where the motors are commanded/ where feedback comes from the encoders), and connect emc2 directly there
[08:24:42] <alex_joni> 2. use PlasmaCAM (under wine or VMWare) to create g-code
[08:25:06] <alex_joni> 3. use the g-code to run emc2 (with an additional converter if their g-code is a different flavour)
[08:25:29] <alex_joni> #1 is tricky, especially if you're still <3 yrs (and the machine is covered by warranty)
[08:25:54] <alliancemetal> I *am* going to upgrade to their new DHC2
[08:26:00] <alex_joni> otoh, you need to have some clues about motor control, and electronics for attempting that
[08:26:02] <alliancemetal> which would leave the old brain
[08:26:18] <alliancemetal> I have some clues about that stuff
[08:26:37] <alliancemetal> and an entire army of engineers at school that would love to rip it apart
[08:27:02] <alex_joni> alliancemetal: my _guess_ is that it's using some motor drives which take step/dir input, and command a servo + encoder feedback
[08:27:04] <alliancemetal> if I send you a plasmacam made drawing would that help you to understand better what's being sent down the popes
[08:27:10] <alex_joni> similar to the G340 from geckodrives
[08:27:32] <alliancemetal> brb
[08:27:40] <alex_joni> alliancemetal: I doubt it.. the only thing that *might* help is looking at the parport with a scope
[08:27:50] <alex_joni> same here.. bbl
[08:32:40] <alliancemetal> yeah y'know the plasmacam software also has a vector conversion deal in it
[14:32:17] <fenn_> fenn_ is now known as fenn
[16:43:35] <alex_joni> jepler: hope that bug description is clear enough..
[16:50:32] <christel> [Global Notice] Hi all! I am about to take down services for a tiny while to update it to the latest revision, while it's gone there will be NO services (nickserv, chanserv etc) -- downtime should be, er, hopefully a few minutes only, I will let you know when services are back up! Thank you for using freenode and have a great day!
[16:52:27] <jepler> alex_joni: for stepconf bugs it is also helpful to attach the .stepconf file
[16:52:51] <alex_joni> I'll keep in mind for the future..
[16:53:04] <alex_joni> it was a user reporting in #emc this morning
[16:53:21] <jmkasunich> alex_joni: how far did you guys get on the "F0 causes G33 to be skipped" bug?
[16:53:42] <alex_joni> jmkasunich: I figured out what the commit was that broke it
[16:53:48] <alex_joni> but nothing after that
[16:53:57] <alex_joni> maybe cradek can look at it .. it was his commit :P
[16:54:03] <jmkasunich> ;-)
[16:54:13] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/emc/task/emccanon.cc.diff?r1=1.122;r2=1.123;f=h
[16:54:14] <cradek> bah
[16:54:55] <alex_joni> cradek: if (vel && acc) in flush_segments causes the linear feed to be dropped if F0
[16:56:28] <CIA-22> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: fix SF#1910452: write axis number, not stepgen number, for limit and home switch connections
[16:56:39] <cradek> 0-velocity moves are usually bad news
[16:56:47] <alex_joni> cradek: this is for G33
[16:57:03] <cradek> I understand
[16:57:04] <alex_joni> so the F word is not required
[16:57:13] <alex_joni> and the vel is not really used in motion.. is it?
[16:57:19] <cradek> guess not for g33
[16:57:21] <jmkasunich> this was found by accident, when I was writing the minimal program that demonstrates the bobble we were talking about the other night
[16:57:34] <jmkasunich> that minimal program didn't have an F word - only G0 and G33
[16:57:52] <alex_joni> the second part of it is that 2 G33 will not work with the same synchronisation
[16:58:00] <jmkasunich> it worked on my lathe with 2.2.4, but not in trunk
[16:58:00] <cradek> sure they do
[16:58:03] <alex_joni> each G33 sends: SYNCHON, LINEAR_FOO, SYNCHOFF
[16:58:16] <cradek> yeah, that doesn't matter though
[16:58:21] <alex_joni> ah, ok..
[16:58:37] <alex_joni> gotta run for a bit
[16:58:42] <cradek> it's true the number of messages could be optimized but the interp would have to be more complex
[16:58:44] <jmkasunich> my vid is proof that it works, at least in 2.2.4
[16:58:44] <CIA-22> EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: Fix SF#1910452: write axis number, not stepgen number, for limit and home switch connections
[16:58:44] <CIA-22> EMC: 03jepler 07v2_2_branch * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: Fix SF#1910452: write axis number, not stepgen number, for limit and home switch connections
[16:58:55] <jmkasunich> that thread has 26 G33 moves in a row
[16:58:59] <alex_joni> nice
[17:00:21] <jmkasunich> I have to go dig out (snow)... back in a bit
[17:00:24] <jepler> alex_joni: it was another trivial bug .. easy to fix
[17:01:03] <jepler> "Please note: passwords should contain only letters and numbers. Inclusion of other characters in your password may result in inability to access some SourceForge.net systems."
[17:01:19] <cradek> funny
[17:02:45] <jepler> 13 bugfixes on the 2.2 branch
[17:02:49] <jepler> maybe a release should go out soon
[17:03:00] <alex_joni> time for a new release?
[17:03:14] <alex_joni> I think lerman had some fixes recently
[17:03:15] <jepler> it's been about 6 weeks since the last release
[17:03:19] <alex_joni> are they noted in the changelog?
[17:03:20] <cradek> I'll be out for a few hours but could help later afternoon/evening
[17:03:28] <jepler> I don't think he put those on 2.2, or if he did he didn't note them in debian/changelog
[17:03:32] <alex_joni> I'm busy for 2-3 hours
[17:03:40] <jepler> I don't think I'm ambitious enough to take this on today, but maybe next weekend?
[17:03:58] <alex_joni> sounds good to me
[17:04:32] <jmkasunich> that might give us a chance to address the G33 bobble
[17:04:40] <alex_joni> was it on 2.2 too?
[17:04:41] <jmkasunich> yes
[17:04:42] <alex_joni> m'kay
[17:04:58] <jmkasunich> it happens with _some_ cases of consecutive G33s
[17:06:16] <jmkasunich> http://jmkasunich.com/pics/threading-bobble.png
[17:06:26] <jmkasunich> note the velocity weirdness above the 7 and 8 buttons
[17:10:22] <jmkasunich> program that makes it happen on sim-lathe:
http://jmkasunich.com/pics/thread-bobble-1.ngc
[17:10:49] <jmkasunich> (the halscope trace is a different program on my lathe)
[18:30:46] <christel> [Global Notice] Hi all! Re-routing appears to have fixed the problem, we may however be experiencing a slight bit of lag while the affected side catches up! Again, thank you for your patience and for using freenode.
[20:04:43] <micges> I have config dir to add to emc with Beam Shape Compensation module, but It must have some modification/extention on AXIS by .axisrc
[20:05:11] <micges> and I don't know how to make It unviersally and correctly
[20:05:35] <micges> I asked few times for this but there was no answer..
[20:05:45] <micges> maybe now ?:P
[20:08:16] <micges> the question is: how to add some commands before start and after stop in AXIS ?
[20:08:34] <micges> without modify axis.py
[20:08:45] <micges> modifying*
[20:14:05] <alex_joni> what does before start and after stop mean?
[20:14:10] <alex_joni> start and stop of emc2?
[20:14:19] <alex_joni> or start/stop of the program?
[20:14:57] <micges> ee start stop of the program
[20:15:26] <alex_joni> don't know if you can do that
[20:23:32] <micges> cradek: around ?
[20:23:47] <micges> jepler: around ?
