Back
[01:19:13] <skunkworks> cradek: thanks for goofin around with the axis clamp/unclamp. (I don't know if I said that earlier.)
[01:30:42] <morfic> i never realized that SWPLinux was a chatty one
[01:36:43] <SWPLinux> indeed
[01:37:04] <Jymmm> no comment
[01:38:22] <SWPLinux> oh hey Jymmm, we'll take them
[01:38:27] <SWPLinux> all the lights
[01:38:38] <Jymmm> ok, and the cords?
[01:39:07] <SWPLinux> what was the deal on those again? $60 for how many?
[01:39:13] <Jymmm> 5
[01:39:36] <SWPLinux> suer, I'll take 5. I didn't ask my friend about the cords, I'll do that tomorrow
[01:39:39] <Jymmm> 5x 50ft 12/3 sjoow (?) with the locks
[01:39:39] <SWPLinux> sure
[01:39:44] <SWPLinux> yep
[01:39:57] <Jymmm> how much were the lights, $20/ea?
[01:40:03] <SWPLinux> I think si
[01:40:05] <SWPLinux> si
[01:40:07] <SWPLinux> so
[01:40:08] <SWPLinux> sos
[01:40:15] <Jymmm> ok 13 lights + 5 cords.
[01:40:35] <SWPLinux> I'll check on more cords tomorrow, I'm pretty tired now, and about to go to bed
[01:40:43] <Jymmm> Bah, I'll look at the logs
[01:41:03] <SWPLinux> I just don't know if he wanted cords too
[01:41:04] <Jymmm> SWPLinux: You want to just mail a check when I get the total?
[01:41:11] <SWPLinux> sure, that'll work
[01:41:14] <Jymmm> k
[01:41:18] <SWPLinux> thanks
[01:41:39] <Jymmm> FedEx GROUND to your acnt number?
[01:41:58] <SWPLinux> probably, but I'll check into another account which may have better discounts
[01:42:03] <Jymmm> ok
[01:42:06] <SWPLinux> I'll let you know
[01:42:16] <Jymmm> I'll let him know so I can pick them up.
[01:42:36] <SWPLinux> ok. do you know how many cords he's got?
[01:42:42] <SWPLinux> it was a lot, IIRC
[01:42:44] <Jymmm> So 10 complete + 3 missing some parts ?
[01:42:50] <Jymmm> It's 5 cords
[01:42:56] <SWPLinux> and 1 burnt out bulb
[01:43:11] <Jymmm> burnt bulb was part of the 3 iirc
[01:43:12] <SWPLinux> oh, 5 is what he's got - in that case I'll take them all ;)
[01:43:14] <SWPLinux> yep
[01:43:45] <Jymmm> 10+3 @ $20/ea + 5 cords for $60
[01:43:58] <SWPLinux> $320
[01:44:27] <Jymmm> k
[01:45:11] <SWPLinux> I'll let you know about shipping tomorrow or more likely Friday - I'm traveling tomorrow
[01:45:36] <Jymmm> Yeah, np. I just needed to make sure they were wanted before he moves
[01:45:43] <SWPLinux> yep
[01:45:52] <Jymmm> I can store them till ready to ship.
[01:45:57] <SWPLinux> ok, cool. thanks
[01:45:58] <Jymmm> no rush there
[01:46:06] <Jymmm> Buenos Nachos
[01:46:10] <SWPLinux> I'll have to buy you dinner again some time ;)
[01:46:16] <SWPLinux> see you, nighty night
[12:31:25] <CIA-2> EMC: 03jthornton 07v2.4_branch * rf6eb24834185 10/docs/src/code/Code_Notes.lyx: fix some spelling
[12:31:28] <CIA-2> EMC: 03jthornton 07v2.4_branch * ra9ed62ca7de5 10/docs/src/hal/rtcomps.lyx: add to description latency
[12:31:30] <CIA-2> EMC: 03jthornton 07v2.4_branch * r176ab760c3f2 10/docs/src/code/emc2-motion-joint-controller-block-diag.png: try and get the image to display better in the pdf
[17:09:05] <azurra> Hello, I intend to use the EMC to control my robot. Being a robot with nom trivial kinematics, I developed a .c file with kinematics and now I need to compile this to a .ko file, someone could help me in this direction? Compilling, setting a parallel port and configuring the steppers? Thank-you.
[17:09:48] <azurra> Just to know, I am developing a robot-type delta. It`s a variation of a tripod type mechanism (which from what I saw, there is a SIM type configuration for EMC). This robot works in Cartesian space X, Y and Z and has three joints, as well as the tripod. I plan to use the SIM tripod configuration that exists in the EMC to control this robot delta, only updating its kinematics (for the delta kinematics that i have .ko) and configuring the parallel port to
[17:09:48] <azurra> drive the stepper motors.
[17:21:45] <SWPLinux> it's possible that the tool "comp" can help you compile your kinematics module
[17:22:32] <azurra> yep, comp --compile (.c file)
[17:22:47] <azurra> thanks
[17:22:51] <SWPLinux> sure
[17:24:36] <SWPLinux> there's also "comp --install", which will compile and install in one step
[17:30:30] <azurra> good
[17:30:31] <azurra> but
[17:30:41] <azurra> I'm using the default configuration SIM tripod, and now I want to change the kinematics of this configuration, how to proceed? Should I replace only the component (HAL. Ko) with the old by the new kinematics? If yes in which one or what files I should shake?
[17:31:10] <azurra> this command comp --install can do that for me?
[17:33:15] <SWPLinux> no, comp --install will put your kinematics module where it needs to be so that EMC2 can load it
[17:33:28] <SWPLinux> you need to create a new configuration to actually use it
[17:33:53] <SWPLinux> choose the config you want to start with, and you should be given the option of copying the config to your home directory
[17:34:06] <azurra> ok
[17:34:07] <azurra> /home/andre/emc2/configs/sim/tripodsim.hal
[17:34:22] <SWPLinux> once you have the config in a place where you can edit the files, you'll need to change the KINEMATICS line in the ini file to use your own module
[17:34:34] <SWPLinux> and you'll need to make any other changes necessary as well
[17:34:38] <SWPLinux> :)
[17:35:45] <azurra> this changes that u mean its like stepper, parallel port and others configs?
[17:36:07] <azurra> other changes *
[17:37:17] <SWPLinux> you may want to make a vismach model of the machine, so you can see what the motor positions are
[17:39:34] <azurra> ok
[17:40:46] <azurra> the steps i think that i need to go is (correct me if im doing something wrong)
[17:41:07] <azurra> download ubuntu with emc (lol) and install
[17:41:19] <azurra> open emc2
[17:42:16] <azurra> select SIM config with Tripod (because my machine have 3 joints, works in cartesian X Y Z too and have similar non-trivial kins)
[17:43:19] <azurra> change this Tripod SIM config kins to my kins (change the .ko file of this config to my .ko file)
[17:44:00] <azurra> config the parallel port (its nedded in SIM configs?)
[17:44:00] <SWPLinux> you forgot "copy this configuration to my home directory", so you can edit the files and not lose your changes when you update emc2
[17:44:07] <azurra> config the steppers to work with my reductions
[17:44:10] <SWPLinux> nope, sim uses no hardware
[17:44:29] <azurra> run my g code? : )
[17:44:38] <SWPLinux> it still loads the realtime kernel modules, but doesn't load any hardware drivers
[17:44:44] <SWPLinux> yep, that's it in a nutshell :)
[17:45:21] <azurra> good, backup is always good!
[17:45:46] <SWPLinux> plus you don't normally have write access to the sample configs
[17:45:50] <azurra> if i do that i will have signals flowing in my parallel port?
[17:46:00] <azurra> it will work?
[17:46:01] <SWPLinux> not with sim
[17:46:13] <azurra> damm : /
[17:46:41] <SWPLinux> since your machine uses 3 axes, just like a "normal" machine, you could create a 3-axis configuration with stepconf, then modify that one
[17:47:15] <SWPLinux> but you won't see much difference on the screen unless you make a vismach simulation or something like that
[17:47:34] <SWPLinux> the AXIS display shows you a cartesian plot, not the motor positions
[17:48:19] <azurra> cartesian is good
[17:48:30] <azurra> at this time
[17:48:47] <azurra> if i use the stepconf
[17:48:56] <azurra> my hardware will be "ready"?
[17:50:07] <SWPLinux> that's a hard question to answer :)
[17:50:11] <SWPLinux> it kind of depends on you
[17:51:36] <azurra> lol ok
[17:52:09] <SWPLinux> gotta run. good luck with it
[18:58:31] <skunkworks> http://bbs.homeshopmachinist.net/showthread.php?t=41845
[19:13:14] <cradek> saw that. that sucks.
[19:13:22] <cradek> I wonder how ray's doing. He's invisible lately.
[19:13:44] <skunkworks> yes - he has been.
[19:34:16] <andypugh> Is "comp" available on a standard installation, or is it part of emc2-dev?
[19:41:16] <cradek> dpkg -S comp
[19:44:38] <andypugh> Odd, that did a lot of things, but I still get comp: command not found.
[19:45:10] <cradek> ah, now we come to the actual question
[19:45:22] <jepler> cradek's command lists any files from any packages that contain the letters "comp", which is probably not too helpful
[19:45:45] <jepler> but yes, you need emc2-dev to get emc's 'comp' command
[19:46:32] <andypugh> That's fine, I just wanted to check that I wasn't being stupid. Well, no more so than I am comfortable with anyway.
[19:47:08] <andypugh> comp seems like the easiest and tidiest way for Vistieurs to compile his kinematics.
[19:47:54] <cradek> yep
[19:49:05] <andypugh> In fact, can we just plonk some pin in float A-offset statements and a ;; at the top and have pins magically appear? (perhaps renaming it as a comp?)
[19:51:14] <jepler> andypugh: on another note, is there a reason you chose to have value and dir for bldc_sine.comp? Is it useful for value to have both positive and negative numbers, or can't the sign of value be used for direction like it is for traditional pwm?
[19:51:31] <jepler> V = fabs(value); dir = (value < 0);
[19:51:49] <jepler> maybe you made a common new-to-C mistake of trying abs(value) and having it not work right?
[19:52:35] <andypugh> No, I didn't even think about it
[19:53:19] <andypugh> But, the module is fairly generic to any motor control, and you might want speed and direction for a spindle, say?
[19:54:10] <jepler> actually emc's spindle speed output is signed as well, with the direction indicated by the sign
[19:54:39] <jepler> there are also separate -on, -forward, and -backward bits but -forward and -backward are mostly for systems with direction control but no velocity control
[19:55:10] <andypugh> I am trying to remember how I drive my VFD, not that it matters.
[19:55:39] <andypugh> I did end up using the pin, as it seemed neater than a negative P-gain
[19:56:10] <jepler> am I right in thing that as written the alignment procedure takes about 1.2 seconds for a 1ms servo thread, and will take different times for different servo periods?
[19:56:25] <andypugh> Yes, that is entirely correct
[19:56:54] <andypugh> I could claim it was based on the assumption that faster servo threads will have faster motors, but was actually laziness.
[19:57:52] <andypugh> The whole alignment thing is a little ad-hoc anyway. It works, and I am confident it should always work, but could probably be faster, swing through a smaller angle, etc
[19:58:12] <jepler> do you have a link that explains what it's actually doing? is the method your own idea, or one that you have seen/read about elsewhere
[19:58:14] <andypugh> But it is very easy to change by anyone with comp installed ;-)
[19:58:16] <jepler> ?
[19:58:36] <jepler> it looks like it turns to 0, then to -90, then to 90, then back to 0
[19:58:46] <andypugh> It is based on a procedure described in the SoftDMC manual
[19:58:52] <jepler> ah
[19:59:26] <andypugh> With a tweak to cope with the problem of the rotor being at exactly 180 electrical degrees, so there being no nettorque.
[20:00:33] <andypugh> The thing is that the available torque with an out-of-position field is rather lower, so I wanted to ensure that even if the motor is marginal to move the axis it still can "grab hold" of the magnets and move them to home.
[20:02:33] <andypugh> A much clever scheme would be to run very rapidly through all the phase combinations, se which moves the encoder furthest, and home to that one. Or, in fact, to interpolate the actual position from how far the encoder moves for a slowly ramping voltage when dancing through the phases at 1ms at a time.
[20:03:51] <andypugh> But with at least one user on the forum with a 5i20 and two 7i39s I wanted something out there and working without going through a full motor alignement R&D program.
[20:04:26] <jepler> why did you choose to use a counts input instead of a position input?
[20:05:17] <jepler> I suppose that the scaled position of the motor encoder is unlikely to be related to the motor revolutions..
[20:05:19] <andypugh> Because the counts per electrical revolution is not the same as per physical revolution.
[20:06:05] <andypugh> And I wanted to be able to subtract the home-counts with no worry about cumulative rounding errors over thousands of revolutions.
[20:06:55] <jepler> hal "floats" are doubles so there really aren't rounding errors anymore
[20:06:55] <andypugh> (consider a 6 pole motor with a pesky divide-by three of integer counts...)
[20:07:06] <jepler> in fact they have more bits of precision (52) than signed numbers in hal (31)
[20:07:11] <jepler> bbl
[20:16:23] <micges> andypugh: very cool stuff you're doing, maybe soon I'll have chance to test it
[20:19:06] <andypugh> The component effectively gives you torque-mode control. I wonder if perhaps it would be better to have the PID loop running on axis.N.velocity-cmd than position-comd?
[20:20:11] <micges> I think it will be no difference
[20:20:32] <andypugh> Or, alternatively, to have two PID loops, one running velocity with feedback from the endoder velocity pin, with it's input from a second position PID
[20:21:30] <andypugh> I might try that second idea some time.
[20:22:20] <andypugh> The current config works OK, but steady-state error is a bit high. (0.05mm). I doesn't help much, but I want to try a high I-gain with a limit.
[20:22:27] <micges> I have brushes dc motors, pwm amplifier and two pids in emc. it works fine
[20:22:48] <andypugh> PID feeding PID you mean?
[20:22:53] <micges> yep
[20:23:07] <andypugh> OK, glad to see it isn't a stupid idea :-)
[20:23:18] <micges> :)
[20:24:06] <andypugh> I know that at work, if you look at it in enough detail, we often have PID loops 4 deep (once you include the speed loop in the controlled device)
[20:26:19] <Martinp23> [Global Notice] Our webchat is experiencing big changes! Channel ops: you may need to fix some of your bans or quiets as a result. All the details can be found at
http://bit.ly/ckfqLh and you can get help at any time in #freenode. Thanks for using freenode and have a great day!
[20:26:49] <micges> here we had current, vel, pos pids in driver (baldor), now we designing only current loop in device , vel + pos pid are in emc
[20:27:07] <micges> for small servo
[20:38:28] <andypugh> Does anyone know of a good link for setting up [TRAJ] AXES and COORDINATES? I am rather puzzled by which data belongs to an axis, and which to a joint. Especially for a 5-joint XYZA machine...
[20:39:52] <micges> where is 5 joint?
[20:40:53] <andypugh> OK, I think I have found it
[20:41:58] <andypugh> It's Viestur's waterjet. It actually has 6 joints and 4 axes. Gantry X is normal, but there are two motors in the head to create a single angle.
[20:44:09] <skunkworks> This is bad - isn't it.
http://pastebin.ca/1880716
[20:44:33] <micges> andypugh: have you any pics? I'll check how it can be properly defined in jointaxes3 branch (where advanced configs are properly parsed)
[20:45:21] <andypugh> No, I think it largely only exists in his head at the moment (well, the main machine is working and making him a living, the 2-motor head is a WIP)
[20:45:57] <andypugh> skunkworks: Graphics problem?
[20:46:25] <skunkworks> I assume. must be because I am running the ati closed source video driver?
[20:47:26] <micges> andypugh: WIP ?
[20:47:37] <skunkworks> work in progress?
[20:47:37] <andypugh> work in progress
[20:47:57] <micges> ah yes :P
[20:48:25] <alex_joni> ja3 would be nice to test with all kinds of crazy machines
[20:50:20] <andypugh> Argh! It won't let me do anything without homing all the joints, but it only shows me 4 of the 6. I wonder how I home an invisible joint?
[20:51:29] <micges> alex_joni: today I was on machines exhibition, there was MANY crazy machines, got some test cases for ja3
[20:51:36] <alex_joni> cool
[20:51:48] <alex_joni> did you also get some time to do it?
[20:52:16] <andypugh> ja3?
[20:52:40] <micges> on monday gantry servo should be ready for tests
[20:53:48] <andypugh> Test it on this?
[20:53:50] <andypugh> http://www.deansmithandgrace.co.uk/icms_assets/files/Travelling_Gantry_Machine.pdf
[20:54:32] <micges> for some more advanced tests I don't have any crazy machines now
[20:55:18] <micges> andypugh: how small :)
[20:55:56] <andypugh> I was stunned to find that a machine like that would be made in the UK nowadays.
[20:58:31] <alex_joni> andypugh: ja3 = jointsaxes3
[20:58:46] <alex_joni> a special branch in the emc2 code where joints really are joints, and axes are axes
[20:59:05] <alex_joni> and the two aren't quite as mixed up as they are in the regular emc2 code
[20:59:30] <andypugh> Shouldn't we (or, rather, you) just beat the main branch into shape?
[20:59:34] <alex_joni> micges: I don't remember, is AXIS untangled in ja3 ?
[20:59:42] <alex_joni> andypugh: nope, this change is really intrusive
[20:59:56] <alex_joni> and the "fix" has been in the works for 2 years or so now
[21:00:10] <alex_joni> having the main branch out of order for 2 years is not acceptable :)
[21:00:22] <alex_joni> recently jogging started working again on ja3
[21:00:23] <andypugh> Arguably it is out of order now.
[21:00:27] <cradek> we will eventually merge it
[21:00:46] <alex_joni> yes, when it's in good shape it'll get merged into master
[21:00:56] <alex_joni> around now would be a good time
[21:01:02] <cradek> "out of order" is relative to the type of machine you want to run, so it's silly to argue about it
[21:01:07] <alex_joni> I mean shortly after a stable release
[21:01:13] <andypugh> (See my message earlier about not being allowed into teleop because a joint that wasn't displayed wasn't homed)
[21:01:29] <alex_joni> that's a misconfiguration ;)
[21:01:43] <alex_joni> but I'm not saying you can configure it better..
[21:02:01] <alex_joni> in ja3 num_joints != num_axes
[21:02:02] <ries_> ries_ is now known as ries
[21:02:06] <andypugh> alex_joni: I agree, but I want an XYZA machine with 6 joints.
[21:02:30] <alex_joni> you always get 9 axes in ja3, and as many joints as you define
[21:02:36] <alex_joni> 9 = XYZABCUVW
[21:03:04] <alex_joni> UVW are still treated the same as in emc2/master
[21:03:33] <andypugh> Is the trick with the current 2.5 to create an axis for each joint, then have the kinematics module ignore the extras?
[21:04:10] <alex_joni> yeah, probably that's the best way to do it
[21:05:00] <andypugh> So COORDINATES = XYZAVW?
[21:06:04] <andypugh> (I will try XYZABC first, one thing at a time)
[21:06:48] <alex_joni> what are the axes you actually have?
[21:07:02] <alex_joni> XXYZAA ?
[21:07:17] <andypugh> Effectvely, yes.
[21:07:26] <andypugh> Is that a valid format string?
[21:07:48] <andypugh> It's valid for Gantrykins.
[21:08:18] <alex_joni> no idea :D
[21:08:29] <alex_joni> I lost track what is valid for what branch
[21:08:39] <alex_joni> nothing beats trying it out though
[21:13:15] <micges> gantry is valid in both branches
[21:14:20] <andypugh> [TRAJ] COORDINATES X X Y A B C gives you 5 joints
[21:14:43] <andypugh> Even though AXES = 6
[21:15:11] <micges> it gives you num_joints in loadrt motion line in hal
[21:15:44] <andypugh> I will just wander off and shoot myself.
[21:16:07] <alex_joni> try not to make a mess, will 'ya?
[21:16:29] <micges> alex_joni: what means untangled?
[21:16:32] <andypugh> No I won't, as the HAL file does read {TRAJ] AXES
[21:17:17] <andypugh> (As an aside, can I make that look for [TRAJ] JOINTS or does something else other than the hal file use that setting>
[21:17:26] <micges> andypugh: add [KINS]JOINTS to ini file and parse it in that hal line
[21:17:45] <andypugh> Makes sense
[21:17:56] <micges> better leave traj alone
[21:18:24] <alex_joni> micges: in master AXIS uses the usual errors in mixing axes and joints
[21:19:25] <micges> I managed to fix many Axis errors, runs quite normal
[21:19:30] <alex_joni> I know I tried to fix some parts of it, but at some point I got in too deep and my python skills weren't enough, so I gave up for the moment
[21:19:36] <alex_joni> I don't mean operation wise
[21:19:45] <alex_joni> the name of the variables internally
[21:19:54] <andypugh> I need to see if this is actually working invisibly.
[21:19:56] <alex_joni> and calling the proper task functions, etc
[21:20:12] <alex_joni> andypugh: now how do you plan to do that?
[21:20:15] <andypugh> (ie look at HAL pins, not Axis display)
[21:20:17] <micges> alex_joni: yes it's quite fixed
[21:20:26] <alex_joni> andypugh: see it if it's invisible ... ?
[21:20:33] <alex_joni> micges: cool
[21:20:43] <andypugh> My spider-senses, of course
[21:22:10] <micges> alex_joni: ja3 Axis almost runs lathe configs
[21:22:24] <micges> but it's still needs tuning
[21:22:44] <alex_joni> well, it needs to be 95% functional
[21:23:08] <alex_joni> after that we can merge it and people will complain/fix the rest :D
[21:23:31] <micges> alex_joni: I'm waiting after emc fest to make some deeper changes
[21:24:06] <micges> cradek and crew will heavly discuss some ja3 aspects
[21:24:50] <alex_joni> yeah, it would have been nice to give them a hand
[21:24:58] <alex_joni> at the workshop
[21:25:17] <micges> yes
[21:38:57] <andypugh> Do you get an f-error when forward and reverse kins don't agree?
[21:42:08] <jepler> andypugh: some (totally untested) changes to bldc_sine (first patch is actually the commit of the driver as you posted it on the mailing list):
http://emergent.unpy.net/files/sandbox/bldc.patches.mbox
[21:42:35] <jepler> bbl
[21:44:10] <andypugh> I seem to have supplied the wrong patch. How did that happen?
[21:45:01] <andypugh> That was my testing version
[21:45:12] <andypugh> Pointless pins and all
[21:46:21] <andypugh> I checked it out, edited it to remove the spare tabs, then seem to have submitted the wrong version to the mailing list
[21:50:06] <andypugh> How do we fix this?
[21:50:30] <Jymmm> You put your right foot in...
[21:54:53] <andypugh> jepler: Much of what you have there makes sense. However some bits were already fixed in the version I am using. I think I must have messed up a local commit or something.
[21:56:50] <andypugh> I am not sure about removing the dir pin. The function is still perfectly happy with negative inputs, the dir pin is just a handy way to reverse the motor sense. The alternative in case where a positive error spins the motor the wrong way is to use a negative Pgain scale. I think I prefer the dir pin.
[22:18:38] <alex_joni> good night gracie
[22:21:09] <micges> gn alex_joni
[22:30:18] <andypugh> What's the ettiquette here? I want to re-post my original patch as I intended (and the version that works) but also use jepler's simplified trig.
[22:33:21] <SWPLinux> what's the question again?
[22:34:01] <SWPLinux> make a patch that uses jeplers simplified trig, and mention his contribution in the patch notes
[23:11:10] <skunkworks> http://imagebin.ca/img/LFIQsXpj.png
[23:11:40] <skunkworks> once I got glx gears running - emc started.
[23:30:01] <skunkworks> cool - should be able to play with cl and everything now. :)
[23:42:14] <skunkworks> how come the demo_sim_cl in trunk doesn't automatically launch the CL gui anymore?
[23:42:41] <skunkworks> (I mean - I know why - but I was wondering why it was changed. - Although I do like that it now uses axis)
