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