yay, I finally have a working microphone/headset
now I can continue to never use ekiga/skype, but not blame it on hardware
cradek: hi, I just wrote a small *dxf to *apt converter in python
it was easy in python
apt defines geometry doesn't it?
so now I can take Qcad files and convert them to the primitives in apt
for a quick sketch
(I know nothing about apt)
just circles and lines
I noticed my machinery's handbook has some stuff about apt - one day I'll read it
but, man python is great
you found a dxf-reading python module?
no, I just did a very simple parser from scratch and did a trial and error thing with Qcad output
it was very simple
probably not very robust, but heh, it works for me
good enough - you can replace it later if you want to support other dxfs
I thought it would be good to start with Qcad, since it's on eveyone's linux distro these days
you can't go wrong by supporting free software first
03alex_joni 07TRUNK * 10emc2/configs/puma/puma.ini: fix ini (widen limits, increase accels to sane? values, tilt joint5 at home)
just found an 800v 80a 3 phase bridge complete with heatsink :)
handle with care
as always :)
it was out of a plasma cutter iirc
that pretty much complete the power supply :)
that's a bad-ass power supply
well - the power supply will be a bit smaller than that ;)
but we don't have to worry about destroying the diodes I hope.
let me guess 40V, 2A
good night all
I have a motor driver with outputs for field and arm
will it only work for AC motors?
or can I use DC as well
[01:20:02] <jmkasunich> http://img237.imageshack.us/my.php?image=rednecktimeoutdd3.jpg
He's back :)
too late, you've been spotted
still in fla? or back in the frozen north?
though it got up to 40 or so today, I think
35 or so here
nah - it was getting monotonous in FL - sun, beach, hot ...
lightning storms, hurricanes
had a couple of those as well (lightning at least - I missed the tornadoes)
only 111 messages on the user list to read now (I'm catching up)
+ 74 Geckodrive, 42 CCED, and 82 commits left - quite a week, huh?
SWPadnos: welcome back
we have more traffic than CCED?
way more this last week
not even counting the dev list
and it looks like the monthly web bandwidth is in the 500GB range (~17GB/day)
things are picking up
what's that -- mostly .iso downloads?
dunno the distribution - I can probably check though
I can't imagine what else it would be
yeah. though the deb repos are there as well, aren't they?
yes they are
but that's only a few megs per download, rather than 600
though you only need one CD to do many installs, all of which will download updates
wow - 2213 hits from the browser "Debian APT-HTTP/1.3"
now find how many unique hosts
I wouldn't be surprised if the update-manager hits several times a day
yeah - divide by 30 (at least) for the number of users ...
default is once per day
plus whenever the user presses "reload"
though not all machines will be on every day..
5387 requests for an .iso file, representing 96.46% of bytes transferred
.pdf and .deb are the only others above 1% (1.31 and 1.33, respectively)
5000+ iso downloads in a month?
I'm not sure those all succeeded, but there were that many requests
yeah those can't all be complete -- 5000 * 7000 MB is 3500GB, a lot bigger than the monthly bandwidth
though that would jive with the total bandwidth used as well
err - what he said
except I had an extra zero when I transcribed it to IRC
based on the apt hits, we have about 60 installs that are on all the time
70*30 days = 2100
the disparity between 5000 download requests and 70 some installs seems really large
that would be 70 installs that are on continuously, or more that are intermittent
and would complete miss those that aren't net connectred
most people have so much bandwidth they will download OS installs they never bother to try
(yes, I speak from experience)
then there's Ray .... ;)
you must have more bw than I do then
i participated in at least 3 fedora core torrents that I never installed
even moderate DSL is enough for that - you just set up several CD downloads at night, and they're ready in the morning
I may have gotten casual about 1meg downloads, but I still don't grab 700M on a whim
roughly an hour each, so too much to wait for, but not too much to download when you have other things to do
I think chris is up to 6.0M download, that's just 15 minutes for a CD
the data transfer numbers that ifconfig prints are since the last time the interface came up, right?
jmkasunich: yes, though it used to wrap at 31 or 32 bits
I don't think that's true anymore
in the last 8 days, I've done 452M down, and 150M up
I tend to do 8-12GB/mo each direction
does that include the bw on cvs.linux.cnc? or just your main box?
that's everything -- it's the ISP's bandwidth report
unpythonic too? or is that hosted elsewhere?
[02:11:02] <skunkworks1> http://www.electronicsam.com/images/KandT/conversion/diodes.JPG
odd heatsink for those modules though
thats a hockey-puck extrusion
I assume it is original
could be the manuf bought lots of that extrusion for their big stuff, so they use it for the little ones too
this is some odd ratings. http://www.electronicsam.com/images/KandT/conversion/yservomaybe.JPG
whats odd about it?
missing units for torque
torque is 242 what?
and no rated amps
assuming I don't think its ftlbs
in-lbs I bet
not likely to be metric
dunno about oz-in - how big is the shaft
atleast an inch
its specd at 0 rpm - stall torque
in-lbs it is then
ft-lbs would put it at 100HP ;-)
what is the Ja-LB.IN.SEC^2 .294?
that is in-lbs so maybe that is the torque rating also
the torque rating has to be in-lbs
nothing else makes sense
242 oz-in would need a 1/4" shaft
and 242 ft-lb would be 100HP or more
RPM 0 ?
it has an integrated brake - might use it for the y axis
I know, in theory that means zero hp
ah - Max RPM is separate
I find it odd that they don't list rated amps
e-bay purchase ;)
amps at 242 in-lb can be computed from the given data, but not trivially
gives max pulse amps ;)
that is one shitload of amps
that the level that might demagnetize the magnets
85A = 242 in-lbs
hope you got some big FETs
that's quite a cont:max ratio
its not clear if 242 is a cont rating or not
the zero rpm makes me wonder
even tho it says duty cont
is that on a NEMA 56 frams?
would have to measure it. it is a little smaller diameter than our moster ones.
I guess it's a "SPINDLE MOTOR W/BRAKE FOR HARDINGE CHNC"
[02:27:36] <SWPadnos> http://www.uptimecorp.com/PartData.aspx?ID=61570
that is it
won't work for a servo though.. ;)
I'm waiting for another page to load - there may be specs for it
the guy was selling hardige lathe parts.. that would explain it.
I guess so
so it's a 2 HP motor or thereabouts
nope - no specs on the other page
SWPadnos: where do you get 2HP?
probably from faulty math, but here goes:
1 HP = 33000 FT-Lb/min
IF it did 242 in-lb at 3500 RPM, that would be 13HP
(unless I did funny math)
could be, but that sounds high for a spindle motor (and a 56 frame at that)
hence the IF
torque probably drops off with speed
33000 ~= 10x 3500 (RPM), so call it a factor of 10
and/or the 242 is peak, not cont
242 in-lb = 20 ft-lb
20 ft-lb / (factor of 10) ~= 2 HP
20 ft-lb * 3500 RPM / 5252 = 13.3HP
5252 = magic number
which happens to be 33000 / 2pi
you forgot the 2pi
ah - rads/min vs. revs/min
they way I look at it, 20 ft-lb means 20 lbs at a 1ft radius
but if you have a 1ft radius winch drum (2ft dia) it winds up 6.28 feet per rev
so it can lift a 20 lb weight at 3500 * 6.28 feet per minute
we find all the cool stuff - don't we? ;)
here are what the machine used originally for position feed back. http://www.electronicsam.com/images/KandT/conversion/accupins.JPG
what read it?
can't tell scale - how big are the pins?
it somehow induces a field and gets sin-cos out like a resolver for every pin
(each pin is broken into .0001)
that isn't very long if its only 0.1" pins
how much travel is there?
oh - they are mounted in a row. that is only a 10"
butted up against one another....seems like an opportunity for a thou or so of error
you would think. but that machine - when it ran - was very accurite
the spec was repeatability of .0005
they where dowl-pinned in.
I think once we get it running with encoders - I want to play with a resolver - encoder chip and see what the scales would do.
if there isn't 'any' backlash in the ball screws and such
that is the thought anyways.
anyone used these?
[03:25:49] <skullworks-PGAB> http://www.amtencoder.com/
they look neat
index channel is standard
was hoping it might be a cheaper alt to US digital - which gets expensive when you need the index channel
selectable resolution sounds neat (must have 2048ppr and built-in dividers)
what do they cost
I was just wondering that too
well - Keling started stocking them, and they were using the US digital before
comes with sleeves to fit most any shaft from 3mm to 8mm (including imperial sizes, like 1/4")
based in OR
SWPadnos: where did you see that price?
AMT-102 and AMT-103
now to make them work
goes down a little for 10 qty, quite a bit for 500-1000 qty
appears they'll just work, they're ttl
* skullworks-PGAB is not sure he could use up 500 units, in a timely fasion.
that is cool
[03:34:44] <jmkasunich> http://rocky.digikey.com/WebLib/CUI%20Inc/Web%20Photo/New%20Photos/AMT102-V.jpg
it does NOT seem to use a traditional disk
I think the black thing is the rotor (green/other colors are adapters for differnet shaft sizes)
gotta wonder if its a relatively low PPR sin/cos kind of thing and they interpolate for higher res
actually, I'm wrong
the datasheet isn't exactly bursting with useful information
the black thing is a splined hub
I know they mention the index channel is magnetic sense
and it mates with a splined rotor that is part of the electronic part
interesting - four different base pprs in one part
48, 100, 125, and 256
each then multiplied by 1, 2, 4, or 8
yeah i was just wondering at that too
there are no common denominators in those numbers
I expected to see powers-of-2 but then 16 divisors didn't make much sense
2^4 * 3, 2^2 * 5^2, 5^3, 2^8
from the ASIC datasheet: "As the quadrature output of these encoders is based on interpolations of an analog function, the accuracy characteristics are more comparable to a resolver than to an optical encoder."
do they actually spec the accuracy?
+/- 15, 30, or 60 arc-minutes depending on base resolution
(yes, arc-min, not arc-sec)
1/4 degree = 1 part in 1440
1 degree = 60 arc min, right?
so that's +/- 1/4 degree at best, 1/2 degree or 1 degree at worst ...
not gonna put us digital out of business, but will put a dent in the low end
sounds fairly crappy, but then again, that's equivalent to a 90-360 CPR encoder
I still want to get one of the automation direct low-end ones that supposedly has an index
too bad US digital won't make an E4P version with index.
Time for bed also
jmkasunich: thanks for running some number on the 'servo'
alex_joni anyway to search the logs?
Its been quite in her for hours
not at all ctually
* skullworks-PGAB thinks its time to clean the kyb again.
Toss it in the clothes washer on delicate =)
s u r e
I *FINALLY* go the crimpers today.
Actually, I got the ALST pair they had, they held them for me.
I saw a topic on cnczone where a guy seperated the step/dir driver from the power h-bridge of the uhu servo driver.
since the processor code on the uhu has not been released
still have to get them pre-loaded
so guy in germany made up a really powerfull servo driver - they call it the uhu
* Jymmmmmm shoves skullworks-PGAB into the OTHER window
I'll find a link
* Jymmmmmm shoves skullworks-PGAB into the OTHER window again
skullworks-PGAB look at the other window
[09:58:49] <skullworks-PGAB> http://www.uhu-servo.de/
what other window?
keep looking, it's there
skullworks-PGAB I just sent you a message
yes on the 2nd window?
I guess that really depends on what client you are using
crappy win prog - Icechat
the latest ver has been Vista sort of remodeled - makes me sick looking at it.
I was doing some cad/cam work earlier - hence windows/dos
I was doing some cad/cam work earlier - hence windows/dos Borland v3.1 compiler.
Oops - another feature...
I have Bornald C v3 full suite.
used to work for them
I had ver 4.52 IIRC
but that was like 96
or some such
Mine's still sealed. We get Borland Bucks, and had a friend order it for me.
never had time to use it.
yeager did CNCpro as part of his thesis
the motion portion was all done in assembler
clean tight code
whole exe file is 173K
including the UI
skullworks-PGAB /join #xyz
Dallur: Are you around?
meaning I should have gone to bed hours ago...
13:11 < alex_joni> morning
not quite morning.. but close ;)
0420 here - the alarm just went off...
ew.. hate it when that happens
guess you need to get up now
no - it just means that I will have to get up for work in less than 24hrs now.
don't remind me :(
time for ZZZZZzzzzzzzz - later all
03alex_joni 07rigid_tap * 10emc2/src/emc/motion/ (command.c motion.h): add G33.1 g-code, CANON call RIGID_TAP, NML function EMC_TRAJ_RIGID_TAP and motion command EMCMOT_RIGID_TAP, needs testing
03alex_joni 07rigid_tap * 10emc2/src/emc/nml_intf/ (canon.hh emc.cc emc.hh): add G33.1 g-code, CANON call RIGID_TAP, NML function EMC_TRAJ_RIGID_TAP and motion command EMCMOT_RIGID_TAP, needs testing
03alex_joni 07rigid_tap * 10emc2/src/emc/rs274ngc/ (interp_array.cc interp_convert.cc interp_internal.hh): add G33.1 g-code, CANON call RIGID_TAP, NML function EMC_TRAJ_RIGID_TAP and motion command EMCMOT_RIGID_TAP, needs testing
03alex_joni 07rigid_tap * 10emc2/src/emc/sai/saicanon.cc: add G33.1 g-code, CANON call RIGID_TAP, NML function EMC_TRAJ_RIGID_TAP and motion command EMCMOT_RIGID_TAP, needs testing
03alex_joni 07rigid_tap * 10emc2/src/emc/task/ (emccanon.cc emctaskmain.cc taskintf.cc): add G33.1 g-code, CANON call RIGID_TAP, NML function EMC_TRAJ_RIGID_TAP and motion command EMCMOT_RIGID_TAP, needs testing
03cradek 07rigid_tap * 10emc2/src/emc/sai/saicanon.cc: little cut/paste error
03cradek 07rigid_tap * 10emc2/src/emc/rs274ngc/ (rs274ngc_errors.cc interp_check.cc): require K word and forbid F word with G33.1; massage error messages accordingly
03alex_joni 07rigid_tap * 10emc2/src/emc/rs274ngc/gcodemodule.cc: add RIGID_TAP
Hi! trying Chatzilla
is PeterW the Peter Wallace from Mesa?
Had some hints for Xilinx meeting timing
I was gonna ask you about that
I've run the code you sent me thru the tools a couple times, and the best I get for the clock to output path is 24-16nS
One this is to give as much slack as you can... actually 25 ns after clock is ok and may result in better P+R
probably have some setting wrong somewhere
ok - I think the .ucf file I have here has 22 or 23nS for that constraint
A million setup options, one hour per test...
Yes I used that originally when design was small but 25 ns meets bridge chip timing
I'm trying to set up either a script or a makefile that runs thru the process
I don't like the gui at all
I've also been experimenting with data2mem, as a way to change ROM contents without re-running the P&R
got the stepgen driver pretty much working
plus you can add a wait state (probably easier in the bridge chip - 1 wait state for reads - 55 nS clock to PAD
I know about data2mem but i have been trying to use a few xilinx tools as possible
Whats the bug in stepgen?
not really a bug, but I want to tweak it
if you set steplen to 5uS, the step pulse is 5uS as expecetd
but it also means the space between pulses must be at least 5uS
Also wondering about your P&R runtime I have about 15 min (1 GHz PIII But Xilinx ISE 6.3)
20-30 mins (1.6GHz AMD Sempron, ise 8.2)
a few of my P&R runs happend while other things had my box loaded down
Yes stepcycle time is just twice steplen (simple hack) probably not optimum for some indexers
I'm gonna remove any hardware limitation on step spacing
the driver will limit the commanded frequency, such that period is never less than steplen + stepspace
so the HW doesn't need to worry about it
The step gen cycle time is really a leftover from the buffered version...
jepler are you there?
I'm also thinking of removing the master DDS and using straight PCI clock
whatever changes I make will wind up in EMC's cvs, and if you like I can send them direct to you as well
the EMC version will wind up diverging somewhat from your version, to meet our needs and plans
Straight PCI clock is fine with large DDS's
but of course you are welcome to use any of it that you want
I haven't done the math yet, but the 32 bit dds gives us a rediculous range
xemet: join #cam for a bit
PeterW: hope you don't mind me asking.. I heard about a new version of the 5i20
0 to 33MHz, in steps of less than 0.01Hz ;-)
One other minor thing to add (I already have a module) is a frequency counter using 50 MHz timebase
DanielFalk; how? I'm in the embedded java client in the website linuxcnc
PCI clock is not well controlled, might be 33.3333 Mhz might be 33 might be 32 etc etc
xemet: type /join #cam
PeterW: that explains why my outputs were about 1% high last night
there is a 50MHz clock on the board, right?
New version of 5I20 is 5I22 = 1.5 M gate FPGA 96 bits of 5V tolerant I/O bus mastering bridge (DMA capable)
PeterW: thanks, sounds like a big board :)
yes 50 MHz thats whats used for generationg the 100 MHz PWM refence clock
still a spartan 2, or something completely different?
(on the 5i22)
Spartan3 (with quickswitches for 5V->3V translation)
* jmkasunich makes a note - try to avoid Spartan2 specific FPGA codre
(Same physical size as 5I20 but can be .2" shorter)
using the 50MHz clock instead of / in addition to the 33MHz clock makes the bus interface a lot more "interesting" doesn't it?
Yep crossing clock domains and avoiding metastables...
although I seem to recall from the 9030 data that the "local bus" can be run on an independent clock
does the board support that?
but only the PWMs would use the 100 MHz reference and they are output only so its not too bad
another question - a couple of times you've mentioned burst reads and writes
I'm just wondering how to ensure that the bursts actually happen
I'm reading from C
how does the bus/cpu know to combine several reads (that may be separated by multiple other instructions) into a burst?
seem if I write:
The 5I20 is hardwired to use the PCI clock for local bus< ive though aboout an option but 50 MHz is tough
foo = ioread(some_addr);
bar = ioread(some_addr+4);
the second line won't execute until the first read is complete, so theres no way to burst the reads
to insure bursts, there are a few things you need
you need to read or write successive 32 bit aligned memory (not IO) locations
ioread is a linux function used to access memory that is being used as I/O (as opposed to regular, cached, memory)
I think on x86 ioread turns into a simple indirection:
plus you need to setup some bits in the PCI9030's. For reads you enable read-ahead
ioread(foo) --> *foo
so the 9030 will burst from the fpga, and cache the data for the cpu
Yes, in the 9030s FIFO
the cycle on the pci bus (cpu reading from 9030, not 9030 from fpga) will not be a burst I guess
but it will be a bit faster, because the 9030 doesn't have to talk to the fpga
right but the PCI bus cycle is not normally the speed bottleneck with the PCI9030
gotta re-read the 9030 manual again
More than a bit faster, amost twice as fast (in my tests about 250 nS per access instad of 450)
in general, caching reads for I/O devices is avoided, because each read might have some side effects, and caching could change that
but I think all the fpga stuff so far doesn't do things like that
still don't want to get stale data, but the 9030 doesn't cache for very long does it?
(flushes the fifo as soon as a non-sequential read happens I think)
Dont think its a problem because of the FIFO flushing
also gonna have to revisit how I do things in the driver
right now I do "for n = 0 to number-of-stepgens ; read_stepgen(n) ; n++
and read_stepgen() might access a couple of different things in the stepgen
which would throw things out of order
gotta decide if keeping the driver generic is worth the couple hundred ns per read
Ill get the exact bits to change in the PCI9030 for read and write burst support
don't spend much time on it - I may decide the penalty in driver messiness isn't worth the minor speed gain
I think keeping sequential read and writes is a good thing
Ultimately you may want to support DMA (10X faster)
the goal for us is not to wring the last ns out of the code
There sequential read and writes are required
its to come up with portable and flexible stuff that can be reconfigured as needed
I'll have to do some experimenting - like commenting out the actual hardware access and running the driver
I'm sure it will be faster without the pci cycles, but not so much faster that its worth it
our default cycle time is 1mS
Well if your I/O cycles eat a large portion of your free time (An issue with large # of Axis) The I/O time is an issue
I just started EMC
the servo thread is averaging about 40,000 CPU clocks
max 81000 (so far)
thats the calculations and such
adding a few hundred for I/O isn't gonna make a huge difference
neither is saving a few hundred
this particular configuration has a fast thread too, it is generating simulated encoder pulses (from a simulated motor/encoder combo) and then counting them in software
that thread is averaging 600 or so clocks, with a max of 25000
a 5i20 based system wouldn't have a fast thread - the fast thread is doing stuff that the 5i20 does in hardware
I guess Im used to faster PID update rates but 8 reads at 450 ns is 3600 1 GHz cpu clocks
CNC machining is usually 3 axis, almost never more than 6
and usually 1mS updates are plenty
(for non-exotic machines)
I can certainly see how things can get a lot more demanding in other applications
* alex_joni worked with an 18-axes robot system once..
OK we have people running 20 Axis, there the access time becomes a problem...
John - are you counting the spindle as an axis? - you might need to
so that makes 4
my point is that throughout the code, we have chosen to favor clarity and ease of use/understanding over tweaking performance
i say that because when we get to the point that we add constant surface speed each move wil add a target rpm...
if we needed to get more speed, there are all kinds of places where we might optimise
on the ppmc board set, we did some caching of accesses to the hardware
on that system, hw access costs about 1uS per byte
on the 5i20, unoptimized access costs 0.5uS per 4 bytes
and optimized costs 0.25uS or so per 4 bytes
even unoptimized, the 5i20 is 8 times faster than the ppmc
But it does not add much to the driver to prefer sequential read/writes...
it depends on how the driver is constructed
for example, the existing driver exports a function to read each stepgen, not one function that reads all stepgens
that decision isn't cast in stone yet
but with individual functions, somebody may choose to read some stepgens every 1mS, and others every 100uS
its hard to sequentialize that
if I did a "read all stepgens" function instead, it might be a bit faster
but if that means they have to read the all every 100uS, even if only one actually needs that speed, the net result is not a gain
My guess is that with a reasonably fast processor, all the read/writes done a particular time slot would get bursted anyway
as long as they are sequential and your code time is < several PCI clocks
for writes I can understand that - the code does a write, and continues on, if it does another write before the first one completes, the bus logic can burst them
but for reads, how can the code continue on to a 2nd read before the first one finishes?
some of us holdout use stoneage computers, a few steps beyond the basic transistor, like a pIII-450 :)
I guess the cpu can do some speculative execution, before it actually needs to use the result of the read
any hardware speed boost helps
I think (dont have the PCI9030 DB handy) that you would just have to be faster than the single read speed
I wonder if a ppmc style pre-read makes sense
Anyway It really doent matter that much at 1KHz but I think its good idea to keep the burstible register layout
yeah, I've come around on the register layout issue, its just a bunch of #defines, so no big deal
the overall structure of the driver is the area where I've got "issues"
right now, one function reads (or writes) one complete stepgen, or encoder, or whatever
if I change that so it reads all stepgens, then bursting is far more likely to do some good
that is an on-going issue - do you emphasize the ability to mix-and-match stuff, or do you optimize for the typical case at the expense of somebody who wants to do something wierd
(like read on encoder every 100uS, three every 1mS, and the rest every 10mS)
Thats what I was trying to explain before, as long as you dont have a lot of code in each function
and as long as each function doesn't touch more than one address
you may get the burst benefit without explicit low level changes (Processor cat do many inst per PCI clock)
if function 1 touches 100 and 200, and function 2 touches 101 and 201, they'll never burst
I get what you are saying though - if function 1 touches 100 and function 2 touches 101, then if they run in order, the accesses might burst even though I didn't change anything
jmk, I missed most of this, but are u guys talking about the 5i20 in general, or just for stepgen?
but the stepgen is the piece I'm working on right now
then wouldn't it be better to spend time on interrupt driven io first?
that would reduce sampling jitter
same would apply to encoder counters, pwm, and general I/O
that would be a major redo of the core of EMC
if HAL supported interrupts
the IO could be read every HW interrupt
right now, the RTOS timer interrupt sets the timing for everything
and then just retreived with HAL function
hmm, I thought each thread was run at it's own rate
is there some other interactions I'm missing?
what happens when board A is sampling every 1.000mS on its interrupt, board B is sampling every 1.001mS on its interrupt, and the thread is running at 0.999mS on its timer interrupt?
I would call that a poorly configed system
but I do see issue with multiple boards
I would think in a single board system, it wouldn't be too hard to make HAL use any interupt for master timing
each thread does run at its own rate, as determined by the RTOS
at the base of that is the timer interrupt
skullworks-PGAB is now known as skullworks-away
in a single board system, in principle it would work fine
so it's using an RTOS timer now, or does HAL wake the threads at the appropriate time?
HAL threads are RTOS tasks
yes, but how are they awaken?
the RTOS handles that
there is a scheduler
timer interrupt, then scheduler
yes, I thought maybe HAL had a master thread that was scheduling it's threads
then it wouldn't be too bad
something like "rt_task_make_periodic(task_id, period)" when the task is created
no, we didn't implement our own scheduler
all HAL threads are registered to the RTOS in the same fashion
that seemed redundant
then it would take some work in HAL for external interrupts
not scheduler, just a master thread that would wake the other threads
although I must admit the idea of working directly over ADEOS instead of using RTAI has crossed my mind
maybe they are block on a semaphore and the master thread wakes them when they should run
well, there has to be priorities, so you need a scheduler somewhere
the scheduler would handle the actual priorities and context switch
but the master thread could actually be controlling the threads by unblocking them
just a thought
I think I understand
but since the RTAI and RTLinux schedulers both had support for periodic threads built in, there didn't seem to be a reason to do it ourselves
the only reason would be to use a HW interrupt as the master time source
which does potentiall reduce jitter, since the hw can latch things on the interrupt so that latency before the sw gets around to reading it doesn't matter
but at the expense of making a multi-board system more complicated
Thats how our original Hostmot hardware worked, latching the encoders at the hardware interrupt rate...
the new encoder counter in the 5i20 reports 16 bits of count and 16 bits of timestamp when you read it, so jitter on encoder readings isn't much of an issue - you know when the most recent count actually happened
and the driver is going to compute a nice velocity output that doesn't suffer from quantization error, even if you are only getting 1 or 2 counts per period
PeterW: thats how any dedicated high performance motion control system should probably work
Right we were also synchronous with PWM - no beats
the time stamp is nice
I've already put the timestamp based velocity output into the software encoder counter, it really smooths up velocity feedback
It will be interesting to see how the timestamp works
still limited though, because the time granularity is still 15-50uS depending on the configuration
PeterW: synchronouse with PWM is how the drives I work on at my day job work
4kHz PWM, and a 4kHz thread
We do that with SoftDMC also
for 2kHz PWM, we run the thread at the peak and valley of the triangle, so its still 4KHz
I imagine you run the softDMC a bit faster ;-)
We can run 4 axis around 70 KHz in Spartan3
what are you running that needs that kind of bandwidth?
and what kind of power devices are you using that don't get clobbered by switching loss?
our 690V drive is rated 1050A at 2KHz, but only 705A at 4KHz - switching loss is nasty on 1700V IGBTs
480V stuff doesn't take quite as bad a hit, but its still significant
Voice coils are one application + little ironless core motors + everything gets better at higher PID rates
what I would consider very exotic motors
For littel stuff Mosfets are pretty amazing
for low voltages, yes.
mosfet tradeoffs start getting ugly above about 500V
right IGBTS limit you to around 20 KHz I guess
not at the power levels we run
it's help-the-poor-swede time again: discrete is seperate objects, right (whereas discreet would be acting quiet-like or generally cautious)
10KHz for small drives (under 50HP)
I always seem to mix the spelling of the two up
lerneaen_hydra: you got it right
there is hope for me yet
PeterW: we don't run the big stuff over 4KHz
even the gate drivers can't handle much over that
(gate capacitance on the big drives approaches a microfarad)
Right, Also dint you have enough motor inductance so you dont have too much ripple/hysteresis loss
Brush motors often have quite low armature inductance so high PWM rates help there (For small motors)
especially the ironless rotor ones
the only brush motors I've worked with professionally used phase control
so the ripple frequency was 360 Hz
obviously they also had lots of L
thats mainstream DC motor control though
(for integral and up horsepower, not fractional or subfractional)
BTW should I add the per-bit I/O option selection +PWM?
I'm still trying to figure out how to deal with I/O vs. special functions
it would be good to be able to select open collector, inversion, etc on a per bit basis, regardless of what the bit is being used for
for example, you embedded polarity control in the stepgen
I dunno if that is better or worse than associating the polarity control with the pin itself
If the config is limited to a sign option per pin its not too much resources
for driving a gecko, it would be nice to be able to make the pin open-collector too
and again, that is something that would apply to all outputs, whether pwm, or step/dir. or general I/O
so do we do it in the stepgen, and in the pwmgen, and in the gpio? or do it in one place?
some I/O options like SelectOption/Invert/OC could be done on a per bit basis
thats the way I was leaning
but I haven't thought through all the implications
other options are special function specific like stepdir/quadrature mode of the stepgen
btw, I'm planning on adding another mode: up/down
or pwm specific options like swapind PWM and DIR pins for Locked antiphase
yeah, pwm has lots of options
single pin with PWM on it
two pins, PWM + DIR
two pins, PWM appears on one and the other is off, swap when polariaty changes
two pins, high and low side switch drive (with deadtime between them)
and probably more
Simple I/O options are cheap deadtime costs a bit more
yeah, deadtime is always a bitch
for my own project, I'm tempted to use two optocouplers with the LEDs back to back, and a cap to control the time between when one turns off and the other turns on
Maybe a basic PWM + a fancier one with deadtime
connect the ends of the LEDs to two FPGA pins
00 or 11 = both off
01 = low on
10 = high on
since the separate high/low switch drive is usually used with more than a simple H bridge
IMHO Deadtime should be implemented in the HBridge. Having Hiside and lowside drive out of the FPGA is something of a footgun
you'd think so wouldn't you?
but I've worked with multiple different manufactures and at least eight or nine different AC drives
and every single one of them has control hardware outputs for all six IGBTs
most have logic of some form or another to prohibit shoot-thru, but deadtime is done strictly in the pwm generator
Sure but thats an integrated system, not mix+match. we are doing the same for low power = 2KW 3 phase amp we are working on but there will be no customer access to deadtime settings
if I was selling power stages, I'd certainly enforce deadtime and shoot-thru protection in the hardware
lemme think about this...
the reason I wanted separate high and low switch signals was for A) deadtime, and B) the ability to turn both switches off
Right, that allows fast or slow decay mode to be dynamically changed
well, I dunno about fast/slow, cause I don't work with brush motors or H bridges
I do three phase, when running we always have either high or low switch on
but when off, we turn them all off
Anyway, Ill work on the per bit stuff. I think simplest is a ddr source register, output source register, and invert register 3 more bits per I/O
theres some meaningless combos but will do OC/push-pull/I/O/one option on a per pin basis
I doesn't need to be an option
every pin can be an input, even if something else is using it for output
by option I meant special function output (inputs go eveywhere so they are no problem)
special function inputs are interesting too - it might be nice to be able to config the pin as a GP output, while using the special function input - so you can put a test signal on the gp output
I think what you are describing would work fine for that
Gets uglier if you have more than one special function output per pin but thats probabably not realistic for Spartan2
Sure all special inputs work all the time
and on Spartan3 there may be enough gates to reassign pins dynamically (just to give you a headache)
Got to go, need to feed bunnies...
nice seeing you here PeterW
hey PeteW - are you going to be around for ESC this year? (April 1-5, at the San Jose convention center)
Maybe, Not sure yet
ok. let me know - it would be fun to meet :)
hey petev - how about Korean Palace again? :)
Nice chatting jmkasunich Bye for now
I'll get the directions first this time ;-)
I may still have their business card if you need help ;)
[21:25:06] <lerneaen_hydra> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?IRCquotes
<-- yet another person immortalised in the irc quotes page :D