Back
[00:10:42] <SWPadnos> andypugh, do you know for sure that the float is in the range (-1 .. +1)?
[00:10:56] <SWPadnos> you can always clip to that if necessary
[00:14:15] <jepler> maybe something like this?
http://emergent.unpy.net/files/sandbox/to8.c
[00:15:09] <jepler> well, except for how my code is wrong, anyway..
[00:16:28] <SWPadnos> here's my wrong code: u32_var = ((u32)((int)(float_var * MAXINT))) << 16
[00:16:57] <jepler> er, maybe it's right. 0x8001 as a 16-bit signed integer is -32767 which seems to jibe with the 8i20 docs
[00:17:21] <SWPadnos> yep. the actual range is [-32768:32768]
[00:17:23] <SWPadnos> err
[00:17:25] <SWPadnos> yep. the actual range is [-32768:32767]
[00:17:54] <SWPadnos> so it's a PITA to make that symmetric, to get that last little bit (no pun intended) of negative range
[00:18:47] <jepler> MSW = QSETPOINT current, signed 16 bit number, 32767 sets current to
[00:18:47] <jepler> +MAXCURRENT and -32767 sets current to -MAXCURRENT
[00:18:52] <andypugh> I _think_ I got it by defining some hal_float_t consts to multiply by, then casting to int and bit-shifting
[00:19:38] <andypugh> machine->show hal config hates my naming scheme though.
[00:22:23] <andypugh> I think I need to swap some "." for "-" (or "_" ?) to make it easier for it.
[00:30:10] <andypugh> http://imagebin.ca/view/tVIvqw90.html
[00:30:41] <jepler> halshow is halshowing its halage
[00:30:42] <andypugh> It seems to stop expanding the tree at 4 levels?
[00:31:30] <SWPadnos> huh. interesting
[00:31:41] <SWPadnos> I know it splits only on the '.'
[00:31:56] <SWPadnos> to get the different levels
[00:32:37] <jepler> maybe something to do with the 'switch $i' in halshow.tcl:makeNodeP
[00:33:10] <SWPadnos> argh
[00:33:14] <andypugh> What you can't see is that I clicked on "0" to get that view, and all the sub-nodes (which aren't, actually) show nothing.
[00:33:30] <SWPadnos> is that in scripts, tcl, tcl/bin, src/hal/utils ...
[00:33:36] <SWPadnos> (found it finally, but still)
[00:35:10] <SWPadnos> eww. that is one gross function
[00:37:43] <andypugh> Is this better?
http://imagebin.ca/view/cSGHFE0.html
[00:37:55] <andypugh> It parses the tree correctly now.
[00:38:22] <andypugh> (though I am unclear on whether "-" or "_" is preferred)
[00:39:23] <SWPadnos> does your module actually know that an 8i20 is there? (is there some way of detecting that specific serial device)?
[00:39:42] <jepler> andypugh: . separates parts, - in names that are more than one word
[00:39:58] <jepler> max-velocity, not max_velocity
[00:40:25] <SWPadnos> I think it was more correct in the original form, ssderial-0 isn't right, since there could be sserial 1 and 2 (etc) as well
[00:40:32] <andypugh> Yes, if you look at the -comms register, the leading 0x80 indicates it has found an 8i20 (74 means 7i64)
[00:40:33] <SWPadnos> vs. pin.00-in
[00:40:47] <SWPadnos> err.in-not or whatever
[00:40:57] <SWPadnos> ok
[00:41:03] <andypugh> Well, yes. But that broke halshow...
[00:41:14] <jepler> don't worry about halshow right now
[00:41:21] <SWPadnos> there is clearly an error in halshow. it's hard coded to 5 levels (including the root, I think)
[00:42:36] <SWPadnos> oh no, it's showing 5 levels, but it really screws up the last name (kind of gets confused between all the remaining parts of the name)
[00:43:20] <andypugh> port-0 is probably correct. I don't think that any word other than "port" is likely to follow the sserial instance number
[00:44:11] <SWPadnos> if there can be more than one sserial, then sserial.0. is OK. if each sserial can have more than one port (which it seems to), then port.0. is also OK
[00:44:52] <andypugh> OK, I will change it all back then
[00:45:10] <SWPadnos> as jepler said, don't sweat halshow for now. it correctly did 4 levels, then munged everything left into the 5th level
[00:45:11] <andypugh> There can be 4 sserials and each can have up to 8 ports
[00:45:36] <SWPadnos> ok, so leave it as it was. I think that fits the naming convention the closest
[00:45:37] <andypugh> and each port can have a 24-pin IO card.
[00:45:45] <andypugh> That's a _lot_ of IO!
[00:45:47] <SWPadnos> that's sure a lot of pins/ports
[00:45:50] <SWPadnos> indeed
[00:46:10] <SWPadnos> especially if you start adding in multiple 3x20 cards (with 6 connectors each) :)
[00:46:31] <SWPadnos> oh crap. got to order that stuff tomorrow
[00:46:59] <andypugh> I think there is a hard limit of 4 sserials, not due to connectors, but due to Regmap space.
[00:47:23] <SWPadnos> per card, right?
[00:47:28] <andypugh> Yes, per card
[00:47:48] <SWPadnos> ok, so you can still have a heck of a lot more than a heck of a lot of I/O
[00:47:49] <andypugh> So with multiple cards you can have thousands of pins.
[00:47:58] <SWPadnos> like a *real* PLC
[00:48:11] <SWPadnos> (though those slow down a lot when you have a lot of I/O
[00:48:13] <SWPadnos> )
[00:49:35] <andypugh> Anyway, I think we now have an 8i20 driver. I need to apply the big volts and connect a motor to be sure, but I think it will work now.
[00:49:44] <SWPadnos> cool
[00:50:17] <andypugh> My plan then is to modify the bldc_sine and bldc_hall components to add suitable angle/current pins, and then we are in business.
[00:50:47] <andypugh> (it is basically a case of breaking out some signals at an earlier stage in the calcs, so trivial)
[00:55:05] <SWPadnos> huh. wouldn't current remain more or less constant, with angle changing for rotation?
[00:55:22] <SWPadnos> (unless more torque is needed, of course)
[00:56:39] <andypugh> Yes, the current is just the PID demand.
[00:57:36] <andypugh> It's a direct input to the bldc_XX components as it is used to calculate the three PWM signals. I guess it doesn't actually need to pass through them to get to the 8i20 driver.
[00:58:08] <SWPadnos> that's what I was thinking
[00:58:44] <SWPadnos> it seems like you'd have to tune the bldc component, since it would basically be controlling a torque loop
[00:59:09] <SWPadnos> PID outputs velocity to bnldc, which outputs torque/angle to the hardware
[00:59:24] <jepler> andypugh: perhaps you'd like to try this for size:
http://emergent.unpy.net/files/sandbox/0001-halshow-permit-an-unlimited-number-of-levels.patch
[01:00:00] <jepler> but don't let me interrupt your real work
[01:00:50] <andypugh> At the moment the bldc components don't do any PID type stuff, just convert an encoder or hall-sensor signal to a required phase-angle, then convert that to three PWM signals.
[01:01:34] <SWPadnos> oh right, it's about commutation
[01:01:38] <andypugh> They are over-complex for the job (except perhaps the hall-sensor one) but I prefer not to expand the number of HAL components too far.
[01:01:50] <SWPadnos> anyway, good luck with it. I'm headed to bed (and you should be too :) )
[01:02:00] <SWPadnos> but don't let that stop you from getting things done
[01:02:06] <andypugh> Cripes! when did it get so late?
[01:02:43] <jepler> contrary to your perceptions, it doesn't happen all at once
[01:03:25] <andypugh> I guess I need to create a branch for that patch?
[01:04:10] <willburrrr2003> Good evening all, is this the correct channel for general EMC2 discussion?
[01:04:24] <jepler> willburrrr2003: #emc is better for that
[01:04:36] <andypugh> More people there, too.
[01:04:48] <willburrrr2003> ok thanks :) will switch there
[01:05:00] <willburrrr2003> #emc
[01:05:33] <qq-> try /j #emc
[01:05:37] <jepler> andypugh: at a minimum you have to commit all your changes before applying that patch with 'git am', so that's one reason it's better to wait until you're at a good stopping point with other work before trying it out
[01:06:46] <andypugh> OK, I will wait until I have at least tested this driver withhardware.
[01:07:09] <jepler> huh, there are some scary warnings when I try to run the java irc client
[18:39:30] <CIA-112> EMC: 03cradek 07segmentqueue * rc59d415c04ef 10/src/emc/ (kinematics/tp.c kinematics/tp.h motion/motion.c): clean tp api a bit
[18:39:31] <CIA-112> EMC: 03cradek 07segmentqueue * re50bcdd5d1e0 10/src/emc/ (6 files in 2 dirs): Regularize API and make it run
[18:39:33] <CIA-112> EMC: 03cradek 07segmentqueue * rf0b1b4b6b125 10/src/emc/kinematics/segmentqueue.c: monkey with diagnostics
[18:40:24] <skunkworks> segmentqueue?
[18:41:52] <cradek> an experimental trajectory planner that was in emc1
[18:42:19] <skunkworks> oh - I didn't see that it was emc. Interesting
[18:42:38] <cradek> a lot of neat features that our current one doesn't have -- a lot of features missing that our current one does have
[18:43:11] <skunkworks> for example?
[18:43:30] <cradek> missing: abc, uvw, tapping, threading, etc
[18:43:56] <skunkworks> I meant the other way. neat features it has. :)
[18:43:57] <cradek> present: planning lots of segments together to not have to slow down for short ones
[18:45:05] <micges> cradek: nice
[18:45:19] <cradek> well so far, it barely runs
[18:45:23] <cradek> ... but it does run
[18:45:55] <cradek> it also has a kind of jerk limiting
[18:46:46] <micges> I need this feature, sadly I don't have time to help/test
[18:47:01] <skunkworks> You like trajectory planning - don't you :)
[18:47:02] <jepler> almost all open source projects need jerk limiting sooner or later.
[18:47:23] <cradek> hahaha
[18:47:34] <skunkworks> heh :)
[19:00:27] <skunkworks> cradek: does it do the 1/2acc during constant velocity like the current planner? (iirc)
[19:01:21] <cradek> I don't know if that's necessary or not
[19:34:13] <cradek> http://timeguy.com/cradek-files/emc/jerk.png
[19:35:24] <cradek> this is sure pretty
[19:36:08] <cradek> (but there's some really wrong behaviors in there too)
[19:38:59] <skunkworks> heh. (I don't know what I am looking at) but yes - it looks pretty.
[19:39:48] <micges> cradek: nice
[19:39:56] <micges> it is from your branch?
[19:40:02] <cradek> yes
[19:40:37] <skunkworks> how would that work in the future? would you have an ini setting for each planner?
[19:40:46] <cradek> skunkworks: I don't know...
[19:40:49] <skunkworks> heh
[19:40:59] <awallin> we need to see the following-error...
[19:41:30] <cradek> awallin: it's sim - there is none
[19:41:31] <awallin> well this is just sim I guess
[19:43:03] <cradek> hahaha
[19:43:05] <jepler> hm, I thought we had a variety of sim that would actually continuously check velocity and acceleration for constraint violation..
[19:43:20] <jepler> (so that you could trigger on it in halscope)
[19:43:49] <cradek> MaxAcc limited violated on motion -2147483645
[19:43:57] <cradek> there's some checking here already
[19:44:14] <cradek> http://timeguy.com/cradek-files/emc/wtf.png
[19:44:22] <cradek> this one is not so pretty
[19:44:35] <cradek> what's fascinating about it is it's one segment: g0 x2
[19:44:51] <skunkworks> yowzer
[19:44:53] <cradek> it overshoots to about 2.5 and then goes back
[19:45:12] <Jymmm> cradek: Are those two downward facing green lines where the signal dropped out?
[19:45:39] <cradek> Jymmm: sort of the spikes are bugs where it does a really wrong thing
[19:45:55] <Jymmm> cradek: ah
[19:46:36] <Jymmm> the accel just spikes in the direction of velocity.
[19:46:37] <jepler> where Xvel steps, Xacc is a very huge number. a change of +2 units in 1ms means the acceleration is 2000in/s^2 during that 1ms..
[19:47:58] <Jymmm> Terminal Acceleration! lol
[19:48:37] <NTU_live> Hello again everybody! I have a problem with my live cd image, but directly EMC related. latency-test wont start due to some pyvcp syntax error.
http://pastebin.com/43s6mwCQ
[19:48:37] <jepler> fg
[19:48:40] <jepler> argh
[19:49:03] <NTU_live> so my guide is faulty
[19:49:30] <NTU_live> i could have SWORN this worked a few days ago on my live image..
[19:49:53] <jepler> what's the first line of /usr/bin/pyvcp?
[19:49:56] <Jymmm> NTU_live: Is this development related? Might be best to ask in #emc instead. (just to keep the two seperated)
[19:50:48] <NTU_live> #!/usr/bin/python is live 1 but first uncommented line is """ Python Virtual Control Panel for EMC
[19:50:59] <NTU_live> *line
[19:51:18] <jepler> OK, what version of python is /usr/bin/python? '/usr/bin/python -V' will print i.
[19:51:40] <jepler> s/print i/print it/
[19:51:40] <NTU_live> i have python3 and 2. 2.7 and 3.1.2
[19:52:04] <NTU_live> default pythin version is 3.1.2
[19:52:08] <NTU_live> *python
[19:52:12] <jepler> yes, many systems have more than one version of python installed, but I'm asking the version of the one called /usr/bin/python
[19:52:42] <NTU_live> /usr/bin/python is v 3
[19:53:15] <NTU_live> i can easily change that in the overlay filesystem to make it version 2 :)
[19:53:17] <jepler> all emc's python files are python2 compatible
[19:53:27] <NTU_live> oh thanks! ill fix that
[19:54:46] <jepler> in principle you can specify configure --with-python=/usr/bin/python2.7
[19:55:34] <NTU_live> oh i could do that too, instead of modifying the /usr/bin filesystem
[19:55:35] <jepler> I'm a bit surprised that with /usr/bin/python being python3 your build succeeded, since the build process is supposed to check the syntax of each executable program that is written in Python, and check it against the configured python interpreter..
[19:56:13] <NTU_live> the live image does goofy things ive noticed
[19:56:37] <NTU_live> anyway, thanks jepler so much, now hopefully that will be the last of my problems
[19:57:47] <jepler> in fact configure does give an error when python is python3, albeit a confusing one!
[19:57:50] <jepler> http://pastebin.ca/1967258
[19:57:50] <jepler> bbl
[19:58:53] <NTU_live> ill bbl too :)
[20:15:28] <NTU> ok well the Arch devs decided to do some python library updating which is fine and all but EMC doesnt like it apparantly.
http://pastebin.com/rSdsR8jV --with-python=/usr/bin/python2.7 is set
[20:16:09] <NTU> python was recently updated today or yesterday from 2.6 to 2.7.. maybe that broke EMC
[20:16:48] <NTU> a newer version of python 3 was also updated recently but that shouldnt matter
[20:26:03] <jepler> I have no idea if python2.7 creates problems. ubuntu 10.04 has python2.6.
[20:26:24] <NTU> fixed it. but new problem.
[20:26:55] <NTU> http://pastebin.com/rM6dnvXE
[20:27:13] <NTU> i dont know python syntax very well..
[20:27:39] <psha> SystemExit(....)
[20:27:40] <jepler> looks like that makefile rule is hardcoded to run python (i.e., /usr/bin/python) and not $(PYTHON)
[20:28:00] <NTU> oh
[20:28:42] <psha> jepler: right, just python
[20:28:48] <psha> and python3 complains about exception with commas
[20:29:03] <jepler> something like
http://emergent.unpy.net/files/sandbox/0001-use-correct-python-for-building-rbf-firmware-images.patch
[20:29:20] <jepler> (untested)
[20:29:37] <NTU> i was going to do that.. you beat me to the punch :(
[20:29:49] <jepler> easier for you to just excise python3 from your system, or at least make /usr/bin/python be python2.x.
[20:31:51] <NTU> * NTU tests patch
[20:38:33] <NTU> well it fixed that.
http://pastebin.com/vHEn1Lm5 i wonder how many more of these there will be. :/
[20:39:34] <NTU> moving stuff around on an arch system in /usr/bin is never a good idea..
[20:40:14] <jepler> please send patches
[20:41:24] <jepler> hm, though the case of modsilent isn't as easy .. there's no provision to generate it
[20:41:42] <NTU> :/
[20:42:46] <jepler> well, can specify the interpreter explicitly instead of through the #!-line
[20:43:22] <jepler> untested again:
http://emergent.unpy.net/files/sandbox/0001-use-correct-python-for-modsilent.patch
[20:43:54] <NTU> you're very quick :)
[20:45:30] <jepler> it's kind of you to say.
[21:08:43] <NTU> ugh why did the arch guys do this...
http://pastebin.com/eN6X39ZM
[21:09:39] <NTU> wait. i think i fixed it
[21:11:41] <NTU> yup fixed
[21:11:50] <NTU> ok hope there will be no more..
[21:12:43] <NTU> yay no more. now to update EMC package on archlinux.org..
[21:19:29] <seb_kuzminsky> hey look! we just broke 1000 package downloads from the buildbot :-)
[21:19:31] <seb_kuzminsky> http://emc2-buildbot.colorado.edu/~seb/billions-served/
[21:20:04] <cradek> cool!
[21:20:27] <CIA-112> EMC: 03cradek 07segmentqueue * r812c881f8e16 10/src/emc/kinematics/segmentqueue.c: fix integer overflow that caused crazy overshoot
[21:21:17] <CIA-112> EMC: 03cradek 07segmentqueue * rf3a3f8b86764 10/src/emc/motion/command.c: also set vmax
[21:21:42] <CIA-112> EMC: 03cradek 07segmentqueue * ra8155e710137 10/src/emc/kinematics/segmentqueue.c: we can print doubles directly in sim
[21:22:05] <SWPadnos> ok, I thought that looked like some wraparound problem
[21:22:07] <CIA-112> EMC: 03cradek 07segmentqueue * r350d38d42899 10/src/emc/kinematics/segmentqueue.h: much bigger queue
[21:25:09] <cradek> funny how many things I see wrong with it, now that I have halscope
[21:25:18] <cradek> back in emc1 I thought it was working pretty well :-)
[21:25:35] <jepler> cradek: actually, %f "works" in realtime for anything that goes through rtapi_vsnprintf (rtapi_print_msg does)
[21:25:52] <cradek> oh really? cool. does %g as well?
[21:25:54] <jepler> master only, maybe
[21:26:04] <jepler> well, it prints a hex dump of the number :/
[21:26:06] <skunkworks> cradek: is it something you started in emc1?
[21:26:18] <cradek> (I can't imagine debugging anything in rt)
[21:26:46] <cradek> skunkworks: I didn't write it, but back in the old days I did flog it into "working" in emc1
[21:27:27] <skunkworks> neat
[21:29:25] <cradek> mostly in Dec 04, looks like
[21:30:17] <cradek> I still suspect the linking code. It didn't seem to match what the
[21:30:17] <cradek> paper says. I think this is closer. I don't have the hardware to
[21:30:18] <cradek> really test this, but it sure seems to run smoothly (and doesn't
[21:30:18] <cradek> bomb, which is certainly good).
[21:30:55] <cradek> bbl
[21:32:29] <CIA-112> EMC: 03cradek 07segmentqueue * rdfd1f387bc78 10/configs/sim/axis.ini: lower accel config for testing
[21:35:39] <NTU> ok package updated and so was guide :)
[21:37:15] <qq-> NTU, url ?
[21:38:22] <NTU> package:
http://aur.archlinux.org/packages.php?ID=40145 guide:
http://neo-technical.wikispaces.com/livecd
[21:38:30] <NTU> guide is messy
[21:38:32] <NTU> :S
[21:38:49] <NTU> qq- do you use arch?
[21:39:04] <qq-> NTU, no
[21:48:11] <NTU> ok im going to test it now.. brb
[22:26:18] <NTU> jepler: do you have a git diff on the pci_get/pci_find_device patch? i was wondering what motion control cards would be effected. anything by mesa?
[22:28:05] <jepler> NTU: hal_motenc.c, hal_vti.c, opto_ac5.c
[22:28:14] <NTU> thanks!
[22:28:20] <jepler> no cards from mesa, just rare and superrare
[23:30:39] <andypugh> I am confused by gitweb. It shows "last commit 116 minutes ago" but the summary starts 5 days ago.
[23:31:42] <andypugh> Ah. I need to scroll down further
[23:32:27] <jepler> andypugh: the summary is of master only, I think
[23:32:48] <andypugh> Yes, so it seems. Head is a seperate section further down the page
[23:44:23] <jepler> the "heads" section shows information about all branches (which I guess are technically called "heads")
[23:53:07] <NTU> i think gitweb _always_ follows head in the big window thing
[23:53:20] <NTU> every tree on git.kernel.org does that
[23:56:00] <NTU> btw i think "head" and "branch" both mean different things to some degree, considering that inside of a "head" there are commits like "Merge branch 'whatever'"
