two very pleasant surprises today
my probe works
all the fancy schmancy probing stuff I put in emc2 (while not having a probe) works
o7 if (X pass min to max to min) ... o7 endif
it's fascinating that this is accepted without an error
also o5 if (If step direction is down, step down. Else step up)
if I probe along Y, it says my 4" gage block is 3.9999. In X, it's 3.9996
would have been fun to see some 4.0000 but it is quite good.
yea! the computer with the 5i20 has been moved to the shop to hook up to the plasma cutter THC here we come!
I have connected to my laser flowmeter
It generates impulses on frequency based on current flow of water, how can I easly get current frequency of it in hal?
I can't find any module for any frequency count or signal average on time counting
(I suppose there isn't any such component)
isn't that what you'll get from the velocity output of encoder in 1-channel mode?
(every time I look at the screen, I see "laser flamethrower", not "laser flowmeter")
funny, I have the same problem
jepler: it works, thanks
I don't know what a laser flamethrower is, but I want one
copying a 1gb file on the raid takes 20 seconds.
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-10-15.txt
is that the total time until the drive lights go out?
hmm - good question
that sounds a bit slow actually, that's 50M/second, which relatively modern drives can couble (individually)
this is a really cheap esata card - the small pci-e card
I copies it on the raid in 20 seconds and on the os hardrive (same drive as what is making up the raid) in about 26 seconds
it's actually 100M/second aggregate, since it has to read and write
so that's what I'd expect with the single drive
(assuming that's the time until "lights out")
yah - have not looked yet. :)
like this http://www.newegg.com/Product/Product.aspx?Item=N82E16815158088
it has the Sil3726 chipset
it's hard to know if it's just a junk design from the pictures :)
came with this http://www.newegg.com/Product/Product.aspx?Item=N82E16816132016
is the OS hard drive connected to a motherboard SATA port?
take one drive of the same type (if you have another), connect it to an esata port, and do the same test you did on the OS drive
see if it takes >26 seconds
oh, the newegg discount email has a 10% (up to $10) off code on hard drives
so 2.5TB drives are $100
lights out in 20 seconds.
remember that the second time you copy the file, it's probably in cache, so it doesn't need to be read from disk again
this is very un-scientific I am sure.
so that enclosure is a power supply and two esata port replicators?
I have a 1gb file on the desktop and on the raid drive. I right click copy - then past in the same directory - or desktop depending on the test.
oh. try time cp file1 file2 && sync
or, to test write speed, time dd bs=1M count=1024 /dev/null file2 && sync
or, to test write speed, time dd bs=1M count=1024 /dev/null > file2 && sync
and to test read speed, time dd file2 /dev/null
SWPadnos: so that enclosure is a power supply and two esata port replicators? YEs
hmmm. maybe you don't redirect dd, just dd dev1 dev2
I don't think you could ever boot off of the raid... It only sees the first drive in each port at boot.
yeah, you need a true multiport card to do that
like the areca or 3ware cards, but then you also need 8 cables ...
hm, I think motion saves the probed position before it uses forward kins to generate the current position. I think this means you always get a position one servo cycle old when probing.
(wish we had sub-servocycle encoder snapshot on mesa, and the necessary supporting code in emc)
it would be great to have a secondary index/latch input on the canonical encoder
wouldn't speeding up the servo cycle have the same effect. (similar)
to get full accuracy on my machine I need to probe at 2ipm (well, 1ipm if this bug is what I think it is)
and a corresponding "latched output"
skunkworks_: yes but I can't speed it up much - too much ladder going on
put ladder in a slower thread?
can't do that either, because it wouldn't keep up with the tool changer
it spins the parts using a big 3 phase AC motor, and you have to brake it (apply some DC) at just the right time
I guess I was thinking keep the ladder in the origonal servo period but speed up the rest. (sorry - probably being dense)
oh I see what you mean now
I bet you are right - I might be able to get a 2x or even 3x improvement (but I'd like 20-30x)
all my whining aside, probing is really slick
hdparm has a mode that tests unbuffered sequential read speed
sudo hdparm -t -T /dev/sda
does that work on RAIDs?
no, it works on individual discs
that's kinda what I thought
I'm nor sure it's a good idea to use that on a drive that's part of a RAID
it's only a read test, not a read/write test
seemed to work...
cradek: the latest HostMot2 encoder counter source has a probe input (shares the index latch)
you'd think that "unbuffered sequential read test" would have clued me in to that
[14:16:16] <skunkworks_> http://pastebin.ca/1622121
sort of what I expected - write was a little slower - read a little faster.
heh - forget what I just said
* reads where faster on the raid which is what I would expect.
yeah, strangely only by 50% or less
like I say - crappy hardware. (but really cheap)
skunkworks_, turn off the RAID, and do the read test on one of the drives in the RAID
see if it's comparable to the motherboard-connected one
the quality of the case is nice though.
LaCie has a NAS with 5x 1TB drives on clearance for $549
that sounds like a good deal to me, though I think it is refurbished
did you guys see this http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-how-to-build-cheap-cloud-storage/
yeah, pretty cool stuff
our server with a real raid card
[14:37:31] <skunkworks_> http://pastebin.ca/1622155
does ppmc use a latched copy of the count or internal reset for homing?
I think it actually resets the count, but I'm not sure
if we do anything for probing, it can't work on ppmc then
not if you use the index input for probing
with hm2 it seems like you could just have another RW handshake like index-enable
if you add axis.0.motor-pos-probed then interfaces that can do better can use it; those that can't just hook it to the same thing as motor-pos-fb
maybe then more pins encoder.0.count-latched and encoder.0.position-latched
with either of them, you could run a faster thread that just reads the counters and latches the values when it sees the probe input
I don't know if there's a handshake needed, or just always latch on rising edge of probe signal
currently you can probe on either edge
i.e. probe toward or away from the work
I guess the firmware would have to know which edge to latch? not sure.
the latch still has to go to the motion controller, since that's what decides whether there's an error or not
(ie, end of move, no probe input)
well it could watch the raw probe input too - I think that's what jeff is suggesting
once you find that the raw probe input has fired (whatever edge you are seeking) you could just read the motor-pos-probed
if the firware latches on both edges would that just work? or is it asking for trouble to assume so much?
the probe signal will have to be hooked into whatever physical input(s) hostmot2 uses for encoder latch
but you could also read that yourself as gpio and send it to motion.probe-input
if you're probing in a way that just grazes the surface, it's possible to imagine getting a rising edge and then a falling edge all in 1 cycle
in that case, "both edges all the time" is no good
but then the gpio won't detect the rising edge you're waiting for, and you'll just ignore it
that was the scenario I was thinking of when I mentioned latching the probe input
however much bouncing you get, you'll either read the edge you want (in which case the LAST latched value is what you want anyway) or not the edge you want (in which case you never know the difference and don't care about the latched value)
if the counter is only latched (not reset), then it seems that latching on either edge is OK
I don't see how it could possibly work if the counter resets
yeah I'm pretty sure it can't
Bit13LatchOnProbe 1 = Latch count on probe (Version 3 counters only)
Bit12ProbePolarity 1 = active high (Version 3 counters only)
unfortunately I think hm2 doesn't do "latch on either edge"
'latchonprobe' is commented out in the current firmware source qcountersf.vhd
since it requires a polarity I guess we'd have to give motion a 'probe polarity' output as well
which will also have to be hooked through to the mesa
the advantage of a handshake like index-enable is you'd be able to get the value when you get your first reading from the bouncy probe instead of the last
I said above that you want the last one - that may be wrong
you can get your choice of first or last depending on the JustOnce setting
but if we use a handshake like that, we can't notice the probe has accidentally fired while homing (for instance) and stop (like we do now)
Yes the current probe latch is the same as the index latch for cheapness
so homing has to be separate from probing, currently theres no way
to tell a probe event from a index event but I guess that could be added
the driver knows which one you want - I don't think it matters
Sure and the hardware should only have one enabled at a time
but if you were looking to avoid a probe crash while homing
the hardware will be no help
oh I see what you mean
a sensible setup for emc might be to have all encoders share the same latch input -- and you don't give up anything because you'll use the same physical input pin to also go to emc's probe input
(for most people that'd be sensible, anyway)
Yes that how it work currently theres a single probe input pin
oh I didn't think about that - you'd need to wire all the latch inputs together
oh, wait, now I understand what pcw_home was saying about a single latch
but as long as the probe input is at least a servo period wide, you'll still be able to diagnose "probe tripped during homing", won't you?
Its not a single latch, theres one per encoder (its the index latch)
yes if we use the scheme of hooking the probe gpio to motion
if we use the RW handshake (which I think is needed to catch a very short probe signal) we wouldn't have that
I feel like hacking the VHDL to latch on either edge and adding a motor-pos-probed pin and then making minor changes to motion would give us a fairly easy solution that would still be compatible with other drivers (but maybe not the best solution)
If I had a place for the bit I could have a probe status FF but I waqs trying to keep it compatible
with the existing driver
the best solution is probably a rewrite of probing to use a RW handshake, but then you bust all the drivers, and doing it on a simple parport etc is a swirl
RW handshake like index?
yes exactly like that
emc requests a probe latch, driver tells emc when it's done
Currently its exactly like index (because its just another index input with separate mask/enable)
sounds like your firmware is ready (except we don't have the latest), all we have to do is figure out how the heck to make emc and the hal driver work
If you want both edges I could replace the mask and polarity bits with enable rising-edge and enable falling-edge
that would let me hack it into working pretty quick, I think, but I wonder instead of doing that if we should have a coherent design first
that's the problem with giving people like me the source...
cradek: that assumes you have a machine with enough hard drive space to install the xilinx software and enough RAM to run it
jepler: pcw_home is always good enough to build for us...
or does seb usually do it?
too bad he (and jmk) are not here
I'm pretty sure it's pcw
on one hand we have "hack it into working with mesa" and on the other "add probing to the canonical encoder in a smart and flexible way"
my inclination is #1 and jmk's would be #2
not only encoder, but stepgen
with software stepgen you could get one-step probe accuracy
it still revolves around latching a position on some signal's edge
what about hm2 stepgen?
ooh pretty http://antwrp.gsfc.nasa.gov/apod/ap091015.html
how in hell did someone photograph that? it lasted 2 seconds I bet.
cradek: I don't see any position latches in the hm2 regmap for stepgen..
I guess it would be pretty cheap for the stepgen since you really only need to latch the top
16 bits of the position register (integer part of a step)
if bits are scarce seems like you could give the difference from the currently reported count
I just dont want to add a feature that makes any of the existing configurations not fit
(though they could be yet more compile time options...)
we should first find a design that works with (nearly) unmodified hm2 encoder + software stepgen
that should be a sign that it's a sensible design
pcw_home: would changing the latchonprobe/probepol to latchonrising/latchonfalling break any other hm2 users?
with a "probe polarity" output from motion it seems like we could properly program the two bits to give the edge we want
"both edges" sounds like a hack around not having such an output in the motion controller today
(since theres no driver support yet)
jepler: well, I bet you are right
pcw_home: do you have non-emc2 customers using hm2 or is it pretty much just us?
We do, Even the USB version
// trigger when the probe clears, instead of the usual case of triggering when it trips
char probe_whenclears = !!(probe_type & 2);
it would be trivial to export this on a hal pin
pcw_home: what would it take to get us the updated firmwares with these existing probe functions?
I can bulld one later today if I get a chance, just tell me the base config, cardtype
and where you want the probe input pin (that doesn't sound right)
I am currently using loadrt hm2_pci config="firmware=hm2/5i20/SVST8_4.BIT num_encoders=1 num_pwmgens=0 num_stepgens=0 enable_raw,firmware=hm2/5i20/SVST8_4.BIT num_encoders=4 num_pwmgens=4 num_stepgens=0 enable_raw"
I'm not sure where the probe input pin should be. it's currently net ProbeTouch hm2_5i20.1.gpio.071.in_not => motion.probe-input
OK I'll make a probe enabled SVST8_4
and add it to I/O 71
is that the highest pin on one of the connectors?
if so, that's maybe a noncrazy place for it
yes, it is the highest gpio
I think that's a good place
thank you! I'll try it out and hack on seb's beautiful driver and jmk's beautiful motion controller...
I know what you mean. I'm glad no one looks too close at my VHDL...
[18:29:06] <cradek> http://www.linuxcnc.org/component/option,com_kunena/Itemid,20/func,view/catid,20/id,976/lang,en/#980
^ this works fine for me
he hasn't mentioned the version he's using
I ignored the thread until today (thinking it was obviously-bad gcode) since it showed up in my email with everything in [brackets] stripped out
o1 if (the number is small enough now) ... o1 endif
grrr web bbs grrr
<br /><br />o2 while (Y loop steps down)<br /><br />g0 y#29
and rss2email is vindicated because it's also wrong in the rss
I wonder what happens if people use [code] ... [/code] in their posts
<pre> they should use ASCII for god's sake </pre>
not on a web<b>BBS</b>
cradek: gocde from his first post hangs up axis indeed
hm, I only tried the second
I notice he doesn't set initial conditions before using while
it looks like he did
so I'm sure I could set variables in a way that would make the program never finish, if I bothered
the second program initializes all of the vars used in the while loop
(about the second one)
#29 = [#29 + #23] (Decrement Y)
I notice this is an increment, which makes the test o2 while [#29 GT #22] (Y loop steps down) never fail
I think he means to use #28 somehow
I prefer o1 repeat [n] g91 g1 right, g1 up, g1 left, g1 up, o1 endrepeat
these loops are just awful to get right
the text I see on the forum is "#29 = [#29 - #23] (Decrement Y)"
in the second example anyway
the second example runs fine
I haven't tried the first example
but micges says it loads forever, which I can believe, since it appears to be wrong
I'm sure there are errors in the first one (it's too long to look at :) )
however, the mystery is that the poster reports the second one also doesn't load
since he says he has problems with the second one also, I wonder what version he's running
(not that I remember any specific fixes to while loops lately)
I bet he didn't save it before reloading it into axis.
it's so easy to write gcode that goes forever. I wish there was a decent way for AXIS to know when to give up
yay - samba running. (the final problem was avg's firewall on xp)
I know TLA stands for three letter acronym, but there's no equivalent for two letters
PL for pair of letters?
"the TLA on my PL made samba fail"
I don't know if avg is an acronym.. Never thought of it.
anti virus grogram
active virus guard maybe.. someone should google it.
my high school friend insisted that the letters on his (volkswagen) gas gauge stood for Full and Rempty
(I have no idea what the R meant)
"Running on fumes"
[19:12:03] <cradek> http://content.mamotorworks.com/img300/fr4564.jpg
maybe this was it??
pretty sure his had an F though
The 1955 VW did not have a gas guage (fuel gage). Instead, when it ran out of gas and started to sputter, the driver reached below the dashboard, turned a lever there to the 'RESERVE' position and the car would run to the next gas station on 'reserve.'
[19:12:28] <SWPadnos> http://wiki.answers.com/Q/What_do_the_r_mean_on_a_vw_bug_fuel_gauge
so we should have looked on the internet
yeah, way back when in the '70s
internet was around when you were in highschool...
skunkworks_: motorcycles still have that clever scheme...
cradek: the quote I coppied from mentioned that also :)
some jaguars had dual tanks as well
with a dashboard switch to select them
like the 1976 XJ6-L, for example
my modernish VW says 0, 1/2, 1/1
I think they just like being contrary
I recently rented a Toyota, and the rental form had eighths of a tank marked off
1/8, 2/8, 3/8, 4/8, 5/8, 6/8, 7/8 :)
I had to return it 6/8 full
should have gotten points for reducing the fraction..
but it was probably the best travel deal ever
I rented the car for one day (for $45 or something)
they picked me up at my hotel to get the car, they picked up the car at the other hotel I drove to (about 30 miles away), they brought my sister to the airport a couple of days later when they finally picked up the car
saved me three $70 cab fares, and let me get around to various stores as I needed
[20:29:11] <cradek> http://timeguy.com/cradek-files/emc/0001-Fix-probe-results-being-stale-by-a-servo-cycle.patch
I came this close -><- to breaking backlash compensation and I would have never noticed
so I wonder if one of you good folks would review this for me
looks fine to me
cradek: why would you break backlash ?
because the first thing I did was move do_forward_kins above process_inputs, which is completely wrong
ah I see
it has to read some inputs (joints) and then do kins on them, and then read other inputs (probe)
... I think
EMC: 03cradek 07master * rbf4fb9c24b1b 10/src/emc/motion/control.c: Fix probe results being stale by a servo cycle
cradek: speaking of motion, when you rewrite tp, did you rewrite it from scrach based on existing code or you writed from scratch only badly working code?
to do sub-servo-cycle latching right, I'd have to get a faster opto22 input module (or eliminate it)
micges: I don't understand what you are asking
err, how much did you rewrite tp ?
micges: I wrote the simplest possible TP that would plug in to the existing interfaces and got that working, then added stuff like blending in a new way
micges: it has very little resemblence to EMC1 by now
(for better or worse)
cradek: ok tnaks
I was digging on TP due to jointsaxes3 work, and trying adding some analog synched output, and trying to figure place to added s-curve acc/deacc
and I think few places can be better done (like many nested ifs on main tp function) but don't have time to actually implement this
if you don't want to do anything smarter than current (only considering adjacent moves when calculating blends or max speeds) you can just replace tcRunCycle
if you want to be smarter than that you will probably need to rewrite everything
I thought so
alex_joni: argh, I didn't write carefully enough
care to correct me on the mailing list too?
nah, I bet it's fine ;)
but if you insist I will
it sounds like I missed the entire point of my message
SVST8_3P.BIT and SVST8_3P.PIN : http://filebin.ca/jkavy
(3 because I had to delete one stepgen to make the probe stuff fit)
SOURCE including the 5I20 bitfiles that jepler wanted rebuilt:I/O standard was not specified) : http://filebin.ca/zedfac
Also looks like you do have the ability to detect a probe event when homing (if JustOnce , LatchOnProbe and LatchOnIndex) are all set
probe events and index events will both clear their own status bits (but if they happen in the same servo period there's no way to know what the latched count represents)
on my 57 VW R meant Reservierung
ops not my 57 my 60
57 had no gauge
"gauge" by the sound of the engine...