micges: did you verify that they work?
er, he's gone
I was going to try out Anders Wallin's inv. deadband, but I can't get comp to work.
On an old system, I get errors that it can't find "component", but that is the first word in the file, on the system I revently updated, even after doing ". emc-environemnt", it doesn't know the command "comp"
hmmm, anybody home?
I have some B series amc drives that I am thinking of getting the brushless servos you have linked to.. For playing
You mean the Keling motors? They are pretty affordable, and the Cui encoders go on pretty easily.
Well, that's what I have hooked up on my bench right now, I wanted to look at this deadband issue.
I might get a few for a circuit board mill project http://www.electronicsam.com/images/KandT/pcbmill/tableanddisp.JPG
some assembly required
A cable driven Something!
So, where is everybody?
elson, do you have emc-dev installed?
Yes, I installed emc-dev and build-essential
skunkworks: cool stuff
hmm, I don't know what the problem is then.
skunk, I recognize that controller!!
chris@rover2:~$ . ~/emc2.trunk/scripts/emc-environment
chris@rover2:~$ which comp
in other words, comp is built along everything else. check that your build was successful.
I just got a working Asymtek 402G that looks nearly just like that at an auction for $150
yes, I did the emc-environment command on both systems. the comp in question is Anders Wallin's idb.
what's your exact error message?
skunkworks, you wouldn't have happened to have gotten the fluidmove software with that would you?
Well, on the newer system I compiled the development head from git source, and EMC runs fine.
do you mean you're getting "bash: comp: command not found" or something else?
On the newer system, I get sudo: comp: command not found
on the older system, which is fairly old, comp seems to try massaging the source file, but compains it can't find any of the keywords, like "component", pin, etc.
I think comp files have sometimes changed format at major version changes
Yes, Anders' file looked a little different syntac, but I made it look more like the examples in the hal guide, and it still complains it can't find "component".
on the new system, if you're using run-in-place (which I deduce from your sourcing emc-environment) I doubt you should be using sudo
Ahhh, that could be it, steps out of the environment! Just a minute, let me try it...
sudo may sanitize the environment, removing your oddball path, for sfaety
skunkworks: what are the guides that slide on those rods? are they bearings or just something like delrin?
elson: I am working on mounting a regular encoder to the spindle. If I succeed you can borrow or have both parts of that resolver. The outside part is permanently in the motor cap, but I'll make a new cap.
Thanks, Chris, not doing sudo fixed that problem, comp now works. I may have to fix up some syntax in Anders' file to make it compile.
The older system may just need an EMC update, but I'm in a hurry to try some stuff, have to go out of town for work tomorrow.
hope the weather is good to you
As for the resolver thing, no hurry, I just sent out for 50 boards. I've made some slight changes that might allow it to deliver a little more drive to the resolver, but I think it won't be enough for those VR units. But, I'd like to try it and find out how much current they really take.
ok. hope you got the board changes right for 50! wow.
cradek: the asymtek I have says it will do about 1200 in/min - would delrin work for that?
mozmck: probably, but I'm no expert
that's why I wondered what skunkworks's was
I have a bunch of delrin and I'm always tempted to make a little gantry with a high speed spindle for engraving
seems like carefully bored holes in delrin + TGP rod would be a setup that's pretty easy to build
I see. I plan to use my machine to dispense solder paste on small runs of circuit boards.
it's made for dispensing. it has a built in controller that has a control language somewhat similar to gcode
for that, getting from one spot to the next fast is important - .002 of slop is no big deal I bet
could be. I think it's supposed to be accurate to .001
cables directly wound around the stepper shaft is an interesting setup
I've seen that with timing belts too (newer zenbots)
yeah, this machine moves really fast. I haven't taken mine apart to see exactly how it was setup since it all works.
mozmck: I know I might have the old dos version somewhere
I think I was able to get it to go into the 700+ipm when I had emc hooked into it
but at .015"/step... too coarse
seems like you'd need VERY high accel to ever get up to those speeds
Mine works as is. I got a basic gui program written to control it with the acl language it uses.
but the other software might be quite useful...
my documentation says it does .001"/step - what model machine is yours?
I would have to look..
did you see my pm?
look at it this way - the wheel is 1 inch in diameter - so 3.14/200 is around .015"
mine is a 402G
maybe it is .001 with microstepping... it may have said something like that in the manual
I tried to see how well it positioned microstepping (hoping) but half stepping was about as good as it got.. (around .007)
you can get about 3:1 reduction with one stage of pulleys - but still that doesn't really get you down to what you want
Thanks, Chris, for helping me with the sudo! So, I now have the idb component compiling on both systems, and have shown that is does exactly what Anders claimed. It definitely tightens up the response.
You can get 4:1 with XL belts, but it takes a very small motor pulley. 4:1 is no problem with MXL belts with of-the-shelf pulleys. But, the SDB or WM Berg pulleys are a bit pricey.
cradek: yes - that was why I kinda figured it wasn't really practical.
That's SDP, stock drive products. Geez, my fingers must be cold or something.
Yeah, reliable micropositioning in actual systems with friction doesn't get much better than half steps. With a servo, it gets as good as the encoder you can afford. The Cui encoders go down to 2048 cycles/rev, I think.
cradek: i am pretty sure they are some sort of ball bearing.
micges: sorry, wasn't around
EMC: 03micges 07tlo_all_axes * r3abb398cd5fe 10/src/ (4 files in 2 dirs): adapt tooledit.tcl for unified tool format
11:08:04 -!- Damon [firstname.lastname@example.org] has joined #designdata
micges: excellent, that's an important step towards making that branch mergeable
jepler: thanks to Dewey Garrett
thanks dgarr whereever you are
jepler: today I realized that fixes to glcanon was VERY important
without it emc would try to run ot of limit without a warning
there are several levels of protection against exceeding soft limits. the axis preview is only one of them, and it's not always accurate
but it's doing it's job quite well
I'm convinced that anyone who can write a program in tcl is much smarter than me
if you'd said "write a correct program in tcl", I might agree with you.
I have the same feel
yuck, something is wrong with tool touch off in (at least) lathe mode
I think the new offset is correctly written, but the dro doesn't change
cradek: sim lathe?
the dro gets updated if you do another g43 or another tool touch off (yes in this case, updated to the value that's "one old")
yes, in master, not tlo_all
annnnnd now it works
randomly? or did you fix something ;)
SWPadnos: those cases you have - do they support a normal hight pci card?
* alex_joni has a hunch it doesn't work again
no, it works fine
ah, crap.. not beeing able to reproduce it is worse
last night I was using the real lathe and it was not working right - that's why I tried it in sim today.