jmkasunich: remember I talked in here about a german user with a puma-typed robot?
a couple months ago
it seems he finally got it to work as it should
jogging in joint and world view works ok
kins ok, etc
joypad for jogging
jmkasunich: I am back
jmkasunich: yea... 3 phase sounds interesting
I'm not entirely sure a .comp file is the way to go
like stepgen and pwmgen, this component will require more than one function, a fast one and a slow one
I think comp can do that, but I'd have to read up
the single/three phase variations would also have to export different pins for the different modes
I would not try to do this as an addition to pwmgen
looking at pwmgen, I thought it would be a good starting point....
copy pwmgen, gut it, and use it as a foundation, yes
for some value of "gut"
I was thinking that it could use the sync pulses to define the period of the output....
then its just a percentage of the number if pulses for on/off
the rate of the fast fucntion call would determine the resolution
no sync pulses, no output
I'm not sure I follow
I think pwmgen's core algorithm isn't appropriate for this tho
phase control is more like a bunch of one-shots
for 120hz sync, there is 8.3ms between sync pulses... that will be some number of fast fuction calls
sync pulse comes in - start timer A
timer A runs for 0 to 180 degrees, based on the control signal
when timer A times out, start timer B and turn on the output pin
I think it will need 2 stages of delay
timer B runs for a constant (programmable) time
180 deg for single phase, 60 deg for three phase
when B times out, turn off the output
one to align sync input with the actual zero crossing at triacs
then a holdof before firing gate
yeah, that would be an additional offset added to timer A
with 8.33ms period and a 20us fast call, there are about 417 counts/cycle
that should be plenty for phase control
how much have you worked with SSR's.... I am thinking of using one of the hockey pucks as an isolated triac, but I am not sure if they have extra logic inside the ssr whhich might prevent pwm control
they work fine for on/off, but they may have significant gate filtering
I haven't used SSRs much
I used to do a lot with hockey pucks - before my current job (AC drives) I worked on DC ones
your hockey pucks are SCRs, not triacs, right?
all my hockey puck experience was from before the time PLC's came popular for sequence control
I think it is a triac.... when one I get full output.... not 1/2 wave rectified a/c... could be back to back scrs
I'm not used to seeing triacs except at low current ratings - 10, 20 amps
I am just soldering together a zero crossing detector so I have an input to the pc to work with
optical isolation would be a good idea there ;-)
I am going to try a capacitivly coupled bridge recifier driving an optocoupler
to avoid a resistor that would get hot?
actually, why the bridge rectifier?
yea... the other though was to use a cheap ac wall wort as a signal source... then it could just drive a transistor into the PP
opto with a diode connected the opposite way across the LED (to avoid high reverse voltage, LEDs don't like that)
I want an input at each crossing 120hz
go for a 50% duty cycle square wave at 60Hz
and use both edges as your timing reference
for a triac it may not matter which edge you use (or you might want both) but for the general case where you have SCRs, you want to know which half-cycle you are on
I was thinking a short pulse at each zero crossing, but a square wave could still provide timing....
thats the way most DC drives do it
there might be significant timing variation when relying on risingand falling edges
need to build some samples and look at them with the scope
to be honest, most drives use two stages - first stage locks a PLL to the timing reference signal, which might be a single edge, or both edges
2nd stage uses the PLL output to generate the gate pulses
if you get some noise or such on the reference, the PLL filters it
without the PLL you risk strange behavior from line notching and other interference
not too hard to filter the sync input in software
a very crude non-PLL form of filtering would be to ignore any edge that isn't 360 +/-10 degrees from the last one
with the bridge and opto, there is some glitch filtering in hardware for short pulse
this is an interesting project - I think as soon as I finish up the stepgen work I'm doing at the moment I'll start the phase control component
LawrenceG: Hi there
tfmacz: Hi Ted... jmkasunich is the hal guru... been takijng over ideas for spindle controller
I have been looking back at the conversation, interesting...
jmkasunich: cool.... I will continue on hardware ideas and we can try them out as the software developes
I think I just finished the stepgen code changes - need to test, and write documentation
thats scary - compiled with no errors or warnings
LawrenceG: did you figure out how to create the .pyc for the changes chris made last night?
lsor do I have to wait for it to hit a release???
LawrenceG: or do I have to wait for it to hit a release???
tfmacz: you can remove the .pyc and put the updated .py in its place
I hope the next 2.1 release will be soon though
so you guys have actually used image-to-gcode?
my suggestion would be to checkout a cvs download... build for run in place and then move the 2 new files into your existing installed system
if so you're the first in the world for all I know -- I wrote it and I've still never milled anything with it :-P
jepler: put the image-to-gcode.py file where and the author.py in the RS274 directory???
tfmacz: the normal installation process puts image-to-gcode.py in /usr/bin/image-to-gcode (no extension) and makes it executable (chmod +x filename)
author.py goes in /usr/lib/python2.4/site-packages/rs274/ or something like that
hmmmm - that risks messing things up when you upgrade to 2.1.3
this really is not a good idea
jepler: OK, I was not sure how that would work...
jepler: the upgrade would over-write the updated .py file???
jepler: just have to make notes and do it again then...
tfmacz: no, it would leave the .py file there
tfmacz: I think that when Python finds both a .py and a .pyc file, and they don't match, it takes the .py file
tfmacz: so when you upgrade to later versions you'll still get that version of 'author' that you copied yourself, not an updated version with any bugfixes..
jepler: ok so need to remove the .py file after the upgrade?
tfmacz: yes if you remember to remove the .py all should be OK after the upgrade
I still recommend not doing it in the first place though
jepler: the new code will be in which release???
jepler: OK, I can live with that...
tfmacz: it will be in 2.1.3 which I hope will be released soon
[01:05:07] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/emc/emc2_2.1.3~alpha0_i386.deb http://emergent.unpy.net/index.cgi-files/sandbox/emc/emc2_2.1.3~alpha0.tar.gz
probably late tonight or tomorrow
actually I've just prepared a package that you could download and install if you really must try it now :)
(it's a slow download though since it's just on my dsl)
jepler: I can live with slow...
if you install this package, everything will go OK when you upgrade to the official, final 2.1.3 later
or just wait for Chris..
* alex_joni remembers that he needs sleep
good night all
did the tool profile updates get back ported into the 2.1.x for image-to-gcode?
LawrenceG: yes that is in there too
changes listed here: http://emergent.unpy.net/index.cgi-files/sandbox/emc/emc2_2.1.3~alpha0_i386.changes
I don's see the 'nice' change in there..
alex_joni: cradek didn't list all his changes in debian/changelog either
tfmacz: are you home for the night?
I bet the stepgen changes aren't listed either
LawrenceG: No, Heading to the firehall for our banquet
LawrenceG: in fact I am getting the evil eye so better go get ready..
tfmacz: have fun
jmkasunich: in the backport, the meaning of the steplen and stepspace pins -- is it the same?
the same as before, I mean
I'm gonna update the changelog
as soon as I check cvs and make sure I know what was actually backported
it's a pity that the branch name doesn't show in the emc-commit subject line
oops - just found a bug in stepgen, branch and head
fix coming soon
was that a "I see your bug too" doh?
no I haven't looked at it
I wish I could get 'cvs log' to do what I want
it is a "doh" kind of bug.....
why does 'cvs log -rRELEASE_2_1_2::' show information about revisions from the trunk?
hmm, cvs server is slow again
jepler: are you doing anything that might be loading up the CVS server?
it works fine from here
for about 20 minutes, it was slow enough that the compile farm checkouts were timing out (2 minute timeout)
15s for a full cvs up
I guess if all four slots were trying to do it at the same time my DSL might have been a bottleneck
jepler: thanks! I was thinking "boy it would be nice if the compiler could detect that error like it does for printf"
but had no clue how to make it happen
jmkasunich: you're welcome
you can blame me for adding _newf in the first place, without adding the __attribute__ turd to get the warning
I wish there was a "rmmod -f --I-really-mean-it-remove-the-damn-thing"
that's one thing that's nice about the simulator -- a little "kill -9" and "ipcrm" and all is well in the world again
I may have to reboot to get rid of it....
note to self - don't write a value to a hal pin unless you have exported the pin ;-)
hi again jmk
I figured out the problem the 2nd time I loaded the module and it crashed
so I got to reboot twice
[ 1206.742421] 391114, 394388, 392864, 391890, and 393924
[ 1206.742442] elapseThis time, there were 80022086 which is so anomalously
(aside from the message being all screwed up)
what system is that on?
my new PII
that I've cut many parts with reliably...
wonder what happened.
did you do anything?
plugging USB or such?
I added ram earlier
nope nothing like that
if it's a 400MHz machine, that's more like 200ms
yeah, it was real too - I heard it
where did the new memory come from?
* jmkasunich speculates wildly
ecc recovery times are probably nanoseconds, not milliseconds
find /, glxgears, etc don't mess it up
jepler: can you try to fix that realtime delay message?
cradek: I'll see what I can do
* jepler boots ubuntu in a vm
I thought I had it right :(
looks like it missed being backported
haven't actually built it yet though
strange - I got only the 2.1 message
oh I get it
what, for forgetting to backport it months ago?
no, for fixing it
I'll try to test it (somehow)
I think the same problem would show up with the step rate message
ok that's easy to try
argh I built without --enable-run-in-place
looks good to me -- I'm heading to bed
(I imagine so - pulling out hair trying to figure out latency)
yes and no, what's up?
I've almost done with the changes that let stepgen replace freqgen
on that I'm just running memtest for a while
I'm 99.9999% sure they don't break normal stepgen operation (all I did was put some code in an if)
was wondering if once I commit you can run it on max
sure, check 'er in, I'll try it
I don't have steppers set up, I have to test using scope, etc
I want to test the freqgen mode first, but I'll commit in an hour or so
feel free to defer the testing till tomorrow
[ 734.434514] Uhhuh. NMI received. Dazed and confused, but trying to continue
[ 734.446802] You probably have a hardware problem with your RAM chips
I can see how an NMI could cause latency problems
those rams are now in the trash can?
steve_stallings is now known as steves_logging
I took one of the new ones out
well I hope it was one of the new ones - I didn't keep careful track unfortunately
well, my kernel log is getting long
code was crashing, so I put a print in the RT function
then I fixed the bug, so it no longer crashes the first time it runs
printing 5 lines to the log every 1mS.....
for the last 10 minutes
do you need hardware output? if not, you could build for sim
so much nicer for debugging
sometimes I do, sometimes I don't
too much trouble to keep switching the entire tree around
(you have to do a clean if you switch)
damn - I keep finding bugs in the new stepgen
step type 1 was busted since I committed it earlier in the week
yay, figured it out (maybe)
figured out the bad memory stick?
good - I just committed the stepgen change - get busy testing
or sleeping, your choice ;-)
I'll at least run it now
it should work with no changes to the config, the default ctrl_type is p
runs and sounds right
tomorrow - man pages and lyx update, and a "deprecated" notice for freqgen (for 2.2, not 2.1.x)
now my monitor is going... :-/
that's how it goes when you use all recycled stuff
whats the monitor doing?
flowsnake ran fine...
some colors come and go (red I think?)
oh - it just need some percussive maintainence
I took it apart and can't find the loose thing by poking around
jmkasunich: yep, seems fine, I ran several things
* jmkasunich brings the farm back online
the realtime jogwheel sure works well
that inconsequential commit started new builds on the vms
oh heck, sorry
I have two of them started (and loaded 10M of updates)
you're never safe from my inconsequential commits!
getting ready to start the third one
no problem ;-)
I need to figure out how to make an incremental build more incremental
that commit should result in "nothing to be done" and return in about 5 seconds
but I run configure all the time, which in turn touches some files and results in them getting built
don't run configure - it will run when necessary
just haven't gotten around to changing the scripts
odd - the bdi slot (and only the bdi slot) is doing a build on the 2.0 branch
there haven't been any changes there in a while I thought
ok, this is weird
your change to /docs/man/man9/,cvsignore appeared in the bdi's 2.0 branch checkout!
hmm that doesn't seem right
that is the output from the CVS up
(ignore the last line, thats from my script)
what's the command it uses?
cvs -z5 -q up -dP
cvs stat docs/man/man9/.cvsignore
I bet it doesn't have the v2_0_branch sticky tag
looks like no files in that dir have the stick tag
wtf is going on>?
I don't know
easy to fix though (cvs up -rv2_0_branch)
I wonder if the fact that docs/man has no files, only directories, has anything to do with it?
in the CVS/ dir, tags only seem to be associated with the files
there were two directories that must have lost their tags somehow
docs/man/man9, and src/emc/usr_intf/axls/scripts
when I did the up with -rv2_0_branch, I got lines like:
cvs update: src/emc/usr_intf/axis/scripts/.cvsignore is no longer in the repository
that's normal, if those files are not on the branch you're changing to
but that means they somehow got into this checkout.....
the man9 directory postdates the 2.0 branch, I wonder if the regular cvs up gets head when it finds a new directory?
I bet if you don't have a -P (even just once), you'll get those new directories
src/emc/usr_intf/axis/scripts has one thing in common with docs/man/man9
no files in the dir that is above it
(I guess another thing in common - added after 2.0)
axis wasn't part of emc for 2.0 was it?
I did the up -rv2_0... again, this time with -dP, and the axis dir went away too
I may have done a manual cvs up at some point, trying to fix some other problem
yeah I bet it was something like that
I should probably take a look at the other branches, and the other slots
yep - the 2.1 branch had a lot of m5i20 firmware files that weren't supposed to be there
checking the other slots now
of the 8 branch checkouts, 3 had stuff that shouldn't have been there
all fixed now
I really wish my system wasn't at 25% load just sitting still
steves_logging is now known as steve_stallings
* jepler could use a nap
* jmkasunich didn't wake up until 11:30 ;-)
jmkasunich: same here ;)
but that was 8 hours ago
I woke up early today (11)
last call for checkins before I start making packages...
alex_joni: I thought you changed the tkemc Tools menu to Utilities
I just got some advertisement that says for $10/mo extra, I can get 1Mbit upload speed...
that would be nice sometimes.
steve_stallings is now known as steves_logging
jepler: I can't find your wiki page about offline updating
spoke too soon
cradek: it's just the last sentence of http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?InstallingUpdates
seems to be a bit one sided conversation
oops - spoke too soon
cradek: that was on TRUNK
cradek: thanks for making the release
cradek: I'll do SF & linuxcnc.org now
I tried to get the wiki stuff
jepler: cool, seems we're getting better/faster with each release
it'd still be nice if the version number was written in fewer places :-P
jepler: cvs seems a bit slow atm
I'm sorry to hear that
hmm.. seems ok now
just had a longer time till the download started
getting the .tar?
.gz .. yeah
the viewcvs is great for that
cradek: thanks again for setting that up so nicely
jepler: it finished, so I'd say it's OK
ok, sourceforge done, linuxcnc next
jepler: short question about using mdi
any reason for it to be slower than the mdi inside AXIS?
* alex_joni thinks maybe switching modes might take a while..
(background: a user wants to do teaching on his robot, he has some custom program, and I suggested him to use the mdi script to send commands to emc)
I never use the "mdi" script
certainly you could try modifying it so that only sets the MDI mode once, or if it detects the mode has changed
Hi Alex :)
how are things over there?
oh, it's quite warm here
we just got home to a foot or two of snow in the driveway (since Thursday night)
how was Germany?
it wasn't.. didn't make it, something came up
I know I asked this before.. how do you feel about mass mails about new releases from linuxcnc.org ?
I don't mind, but I'm not sure everyone would agree with me
I didn't get any reply that would indicate otherwise though
is there a significant number of pwople signed up at linuxcnc.org (that aren't also on the user/dev lists?)
about 400 people
wow - didn't know it was that many.
are there email settings in the personal profile setup there?
if so, then there should be no problem
(since people can turn it off if they like)
what kind of settings?
lots of online forums have settings for sending emails, not sending emails
that the users can set for themselves
I don't think so
"PS: please let us know if you don't want to receive announcements by email.
that's what I wrote in the last one
got one single reply ..
then I'd say it's OK :)
the reply said something like great to keep us posted .. or the like
hmm.. maybe I'll keep that only for major releases
jmkasunich: it seems clear to me.. the source stuff
but that's probably cause I wrote that :/
of course, you wrote it
I gotta look at an older version and see what it did in the delta=0 case