Jacky^ is now known as Jacky^afk
03paul_c * 10emc2-auto/wiki/ (diff_log page/E/EMC2_FileHeader.db): "Auto update wiki from a cron job. Sat Nov 26 05:30:01 GMT 2005 "
03jmkasunich * 10emc2/src/ (Makefile.inc.in hal/drivers/hal_ppmc.c hal/drivers/Makefile):
Initial checkin of HAL driver for Pico Systems cards. This version consists
mostly of the infrastructure needed to support multiple boards on multiple
parports. Most of actual hardware access code still needs to be written,
however, the digital I/O on the USC card (and probably the UPC card) works now.
Jacky^afk is now known as Jacky^
anyone up on emc2?
a little dangerous ..
well I have to run for a bit so I will ask and leave. I have been playing with emc2 for a few days. I was using the jog to test the max speed - I was only getting about 70-80 ipm before I would get a following error. I was thinking that this isn't going to work - I need more speed. I lowerd the base period and it didn't help much. Well I went into mdi mode and started moving the axises around. I can get atleast 300ipm running the m
skunkworks: i'd suggest you to post the ini file here: http://www.rafb.net/paste/
and poste the url, it may could help peoples here to help you
otherwise theyve no other chance than look at the crystal sphere :P
rayh is now known as rayh_away
im fighting with the FPGA
heh, I imagine it's not an easy task ;)
bosone was working on that too, time ago ..
do you know how to convert a binary file to that hey format used in m5i20_HM5-4E.h
who is bosone ?
well .. you need some program that does that
an italian friend
I worked with a program in the ethernut project
it's a dos utility though,
he have been here time ago ..
it takes a number of various files, and compiles them to hex form
or i change the driver to read binary files
actually a define using the content in a char array
but if it's a kernel module.. good luck
you'll certainly need it
that is the reason
ok.. gotta work on a php recursive function
back in a few hours I hope :P
alex_joni is now known as alex_joni_away
Imperator_: if you need help, I'll be around on and off
what you basicly need it to open the file in binary mode,
read one char at a time, and write an array with those values
to a .h file
which you link to your project
rayh_away is now known as rayh
Looks like jmk worked all night on ppmc.
rayh: seems like very nice work
didn't have a chance to cvs up yet.. need to finish smthg first
Hi Martin. How's it going?
slowly, but the Hardware is finished
I'd better get busy and test jmk's multiboard ppmc code
hahahaha ! http://i.gamedesire.com/upload/user_photos/g/3/1/9/3197767.jpg?1
S is now known as yabos
this the canel for emc developent ?
why you no want my changes ?
I'm the wrong person to ask
who do i ask ?
I think you should ask jmkasunich since he sent the email about your changes
he ever here ?
he will probably be here later today
i try come back tomorow.
"Wha cha do Chris?! Wha Cha do!?" heh
cradek: runnin off the people like that = =)
Jymmm: well I know his changes have caused some debate, and I'm unqualified to discuss it with him.
cradek (I'm just playing with you)
SWP_Away is now known as SWPadnos_
* Jymmm is now known as Jymmm
ok here is the ini file http://www.electronicsam.com/images/EMC.INI
that I am playing with. Here is the deal. When I lowered the max accelleration to 2 for all axises I start to get following errors for any jogging velocity above 70 ipm or so. I can go a lot faster jogging with the max accelleration set at 20. Anyway when I do mdi motion with the acceleration set to 2 I can go 300 ipm with now following errors. Is it a mouse click t
this is emc2 and steppers.
also when I get the following error some times it is very hard to turn the machine back on as the machine shutters and I get a following error again. over and over
skunkworks: looking at your INI file ..
im going to turn on emc2 pc and compare it to the mine..
my z which has an inputscale of 20000 - I can barley jog it at 20 ipm without following errors. When I command (mdi) a position it will go over 75 ipm
you should have a max vel of 75 IPM on Z
Have you timed that move for real speed?
the BASE_PERIOD won't let you go beyond 25000 steps/second, and you have 20000 steps/inch on Z
so - no more than 25000/20000 = 1.25 inches/second
takin a break from raking leaves
I got lucky - there's 6 inches of snow on our leaves ;)
jepler_ is now known as jepler
had a little snow here too...4 inches on the mountain tops...but none at the house
I was just noticing something with this:
[18:31:59] <les_w> http://www.mdsi2.com/Solutions/CNC_Controls/
about 500 microsecond servo update is the fastest they claim
hey jepler - thanks for the idea about using emc1 in SIM mode (for AXIS testing) - unfortunately, I have kernel 2.6, so I think it won't work
though it could, since there should be no kernel modules in sim mode - hmmm
Two guys from mdsi attended emc-monday a couple years ago.
OpenCNC is what NIST was using on the big lathe they were playing with during Fest
they say the servo freq scales with clock freq, but use 600 MHz pentium 3 with their turnkey system
One of em had written the hexapod kinematic stuff for us while at NIST
skunkworks - are you sure this is the correct ini file? Usually, INPUT_SCALE and OUTPUT_SCALE have to be the same for stepper systems
yeah, for me are the same
I've heard of a few explorers who run them different from each other but I never figured out the reasons why.
those are the kind of explorers who never return ;)
my other 2 axises will go 300 ipm commanded while jogging will only go above 75
Ive INPUT_SCALE = 1000 0
OUTPUT_SCALE = 1000 0.000
I'm surprised that they move at all - you should get a following error almost instantly
yes - that is how my emc1 ini is- I can try that. I just went with the defaut ini and added my scaling. Why would the jogging act differently than the commanded motion?
I will try it and get back
You might try increasing
MIN_OUTPUT = -10
MAX_OUTPUT = 10
one difference is the acceleration - a jog is generally a small move, and there's not enough time to get up to speed
also, jogging is dependent on keyboard repeat rate
For the stepper, these are used to set an upper bound in a formula.
(depending on jog mode)
rayh: where are MIN_OUTPUT and MAX_OUTPUT variables ?
[18:47:00] <Jacky^> http://www.electronicsam.com/images/EMC.INI
should be in each axis section if this is emc or bdi.
not there in emc2
thats is emc2 ini, may different from emc
sorry for the confusion.
skunkworks: is using emc2
emc2 doesn't use a servo loop to control pulse generation.
I think the 700 mhz cpu he's using could be a brake too for the feedrate he want
I think the main question here is why jogging can't get feedrates as high as MDI
Could be. I try to stay away from very large input_scale variables
swpandnos - that is the question.
mouse thing? is there a key i could test to jog? I don't know it offr the top of my head
I think the arrow keys are X and Y jog, by default
yes - thought I tried that. I get the same following error
around 70 ipm
well - I wonder if there's a bug somewhere in emc2 that causes it to try using feedback in jog mode, but not in "command" mode (either MDI or auto)
anyone know how many servo counts one should realistically have as following error ?
try changing the INPUT_SCALE to be the same as OUTPUT_SCALE for all axes, and see if it fixes the problem
depends on the machine, and your accuracy requirements
I agreed with SWPadnos_ the input/out scale looks strange
SWP: I'm just designing my machine and thinking about gearing/screw-pitch tradeoff
for x and y - so I do or don't need the output scale on emc2 - I was under the impression I didn't
I will def add it though - take a few seconde
skunkworks: you shouldn't need it, but there may be a bug that still uses it when jogging
etla: can't help you there ;) ask a real expert (like Les, Ray, or Mariss @ geckodrive)
adding the output scale didn't help - still following errors
ok - there's still a problem somewhere in the PID / feedback code - a following error should be impossible with an emc2 system using the stepper driver
is it something I am doing stupid? my ini file is set up wrong?
just to be sure - you did restart emc after changing the ini file, right?
and you're absolutely sure that this is the file that emc is using?
really ? so it just overrides max vel and max acc if the user has put in something too high ?
yes as when I make changes they are active in emc
no - there's no feedback, so there can't be a mismatch between commanded and actual position
though the stepper module still provides "faked" feedback
hmm. but the motion module can plan motion that cannot be realized by the step/dir generator cant it ?
the problem here is that jogging produces following errors at speeds that are fine using MDI commands
* rayh is a newbee to emc2 so have very little knowledge of requirements there.
join the club (I just look at the source these days) ;)
woohoo - the emc2 build just finished
gonna do a bit of testing here before I shoot off my mouth.
have you done any fiddling with the ppmc driver?
oh yes you can raise a following error with emc2
that should be due to an input_scale:output_scale mismatch though
in fact there is a difference in raising it between + and - directions.
same as the emc.
I changed my in/out scales so they are the same - still the same problem
I can issue (g1 f200 x-4) but it only travels at the rate set in the traj.
What value do you have for max vel in traj, skunkworks?
5 - 300 ipm
x - y go 300 ipm while z only goes 75
Are you seeing it move that fast?
Looks to me like the following error is raised during the decel on a minus move
The traj planner seems to work properly with mdi and auto moves but not correctly with man.
I'll play a bit more with accel
That is where I would see it the most but I do see it during accelleration also
I seem to run auto just fine also
just seems to be the jog that is causing problems
emc2 seems to have a lot smoother pulse train also.
Yep. there are a few real issues with manual jog and the emc2 step generator.
I'm getting about 0.0132 overshoot on a 1 inch move at 144 ips.
0.0255 in the negitive direction.
I also see the servo reverse at the end of the jog a few degrees
probalply what you see - overshoot (steppers
Right. If you increase the following error by a factor of ten you will see those reversals
It's interesting that mde and auto work properly.
Are you talking about the min_ferror and ferror settings? I have not touched them.
.010 and .050 respectively
Yep increase those and it widens the allowable error.
I wrote a wiki page on how it does that.
that is why I was about to give up on emc2 as I was doing all the testing in jog. I couldn't get the speeds I needed. I just out of the blue thought I would try some mdi moves to test.
[19:33:40] <rayh> http://emc.sourceforge.net/cgi-bin/emcinfo.pl?Following_Error
tongue-in-cheek --> you could hack tkemc to use mdi for jog rather than manual commands.
;) I am not that good - mostly vb. It is also worse if the accelleration is less - I get more following errors with the max accelleration set at 2 vs 20
somebody got a minute to guide me through halscope
ah got it.
Halscope can watch signals
and show them to you a lot like a recording digital scope.
so should there be a bug ticket for this?
alex_joni_away is now known as alex_joni
alex_joni - have you been reading what me rayh and swpadnos have been talking about?
hang on, just came back
ok.. read the logs
jfyi : if you find a part of emc that doesn't work as it should.. file a bug report
if the one who looks at it decides it's not a bug, he can close it
but when/if you file a bug use a sourceforge username
so we know who filed it, and we can get in touch with him for further info.. ok?
sorry I disappeared, and didn't see your message
was up till 4am coding
seen the results ;)
got up at 8am to take dog to vet, came back home and crashed, slept till 3pm
I'd say it was worth it ;)
still not done, gotta do the encoders and step gen side
I'm logging. Sorry, searching removed.
hey jmk - I've got a couple of questions about the ppmc driver
ok - do you plan to make a "bulk update" function, or keep the write_all (for example) as a bunch of individual writes?
write_all will write everything that is out there
one sec - let me get back to the code
ok - right now, for each board found, a function gets added to the wr_funct array
and all get called by write_all
write_all is the only one exported to HAL
ok - that's going to be pretty inefficient
its not safe to allow two threads to access one EPP bus
so you can't for instance sample the dio at 10KHz and the encoders at 1KHz
ok - but I think it's more efficient to read everything than it is to read several parts of the data separately
you mean to make full use of the autoincrement address feature
once you read 4 or 5 bytes, you might as well read all of them
once you need to read 4 or 5 bytes, that is ...
I was hoping to achieve some code reuse, for instance the encoder and DIO parts of the USC and UPC are the same
well - the number is actually 4 bytes - ClrTimeout does one inb, then SelWrt continues with 3 outbs
and I think even the PPMC encoder card works like the USC and UPC encoder sections
I was thinking about that - the only things that need to change are the velocity -> output calculations, and the size / address of where to write them
there may be other things as well, like control bits that have changed and the like - I haven't looked that closely yet
I have both register sets up, and the titles are identical for the read registers, and most are the same for write as well
that's why I wanted to invoke each individual function in sequence, let each one do its thing
sure - but the read_all and write_all should probably do a bulk update of all the registers for that particular board
the calculations can be controlled by a parameter or HAL pin
I already have that part done
SWPadnos: so does the STG :P
but I need to add support for v2 of the board :/
so - you keep an array of bytes, and read_all / write_all do bulk reads and writes, but the data gets split / combined by different functions
do all the boards use the entire (or most of) the 16 byte block?
if so, that makes perfect sense
if not, you might wind up doing epp cycles that you dont need
actually - it would be two 32-byte blocks (though the read buffer could probably be 16, since the upper 16 are unused)
btw, the autodetect and init is the switch at hal_ppmc.c line 374
ah - OK
jon divides the epp address space into 16 slots of 16 bytes
his older cards are one slot each
UxC is two slots
I scan the bus one slot at a time
ah - didn't know that
alex_joni_ is now known as alex_joni
read_all is invoked on a slot by slot basis
I only see the 0x51 / 0x41 byte in the register description
the older cards are on other webpages
Added the bug report - thanks everyone. Great work guys.
hmm, I could add a 32 byte array to the slot struct, and ints that say how many actually need to be read or written
then read_all could read into the array, and invoke the specific functs on the array instead of the hardware
write_all would invoke the functs on the array, then write N bytes to the HW
it's the write array that would need to be sparse
I wonder if the card responds to writes to undefined addys, or if you get an EPP timeout/
timeouts would certainly kill the efficiency
I think the registers just go nowhere - but I'd ask Jon
it shouldn't respond
as that addy might be on another card.. right?
each card occupies one (or two) 16 byte slots
hopefully it does ack reads or writes in its own slot
the addresses are sequential, in 32-byte blocks (fro the controllers)
it should ignore access to other slots
the USC only needs to read the first 16
and I bet that unless you are changing config or doing something else unusual, it only needs to write the 2nd 16
when writing, the USC uses all 16 high bytes and three low bytes (non-sequential)
what is the assy reg used for?
(the low one)
the univPWM card uses 12 of the high bytes (non-sequential), and the same 3 low bytes
that's an alias for the upper assembly registers, but I don't know where it goes when you write reg 2
if its an alias, then it isnt needed
assuming you also don't normally change the timer config or the encoder control reg...
actually - that can be used for a single axis update
you only have to write the top 17
yep - so I'd make read_all and write_all only do data, and read_config / write_config do the config (if that's even necessary after init)
no, the only hal functs will be read all and write all
the individual functs like encoder will have config params.... if they detect a change, they will write directly to the HW, otherwise they use the array
the only exported ones, at any rate - I suppose there could be a flag that tells write_all if needs to write the config
hal has no provision for calling write_config only when needed
I'd rather just embedd that into the module specific functions
keep read_all and write_all generic
you can't - they could be in different threads than the servo update thread
let them get their start and end addys from the struct
no, the module specific functs are the ones called by read_all and write_all
sure - make them totally generic (write 32 registers max, and less if start_addr and / or end_addr are specified)
no - you have to separate that into prepare_for_write_all, and then the actual write
we may not be communicating here :)
the functions that actually prepare the data to write should ge tcalled from write_all, and then write_all causes all of the data (necessary) to be physically written
yes, but that is all part of write_all
those prep functions should only populate a driver-internal array (similar to a HAL pin arrangement, only internal)
yes, the array will probably be part of the slot_data_t struct
ok - then we agree (I think)
also will add rd_start and rd_end, wr_start and wr_end fields to the struct
read_all just does a bulk read (since you need all registers, and they're contiguous)
for the USC, you only need the first 16 of 32, so start and end save 16 inbs
yeah -I was thinking of just making the read array 16 bytes, but it is better to allow for that changing some day
the USC occupies two slots of epp address space, but only one slot_data_t struct
so the struct needs to be able to handle 32 bytes
where does slot_data_t come from?
allocated during init_module, as part of the bus scan
ok - I see it
_t to you too
I almost closed that tracker the other day, with a comment something like "sorry, ain't gonna change it"
* alex_joni grins
that bus_data_t struct has 16 slot structs in it... it ain't small, but its not in shared memory, so I don't feel too bad about it
* ValarQ curses crap
yeah - I hate crap as well - let's all curse crap
ValarQ: watch your language mister
gah - how can I copy a DVD ISO easily in Linux???
sorry mr Joni
(all perfectly legal, of course)
any good way to get the number of blocks to copy?
or will it stop when it hits the end of the data track?
then move the mouse a lot ;)
it will stop at the end of the device
ok - so I can do dd if=/dev/scd0 of=~/wacky.iso bs-1M count=1000000
SWPadnos_: i would exclude the count
ok - do you suppose that will make it wait for more data to become available?
no, it will terminate when all data is copied
ok - well - I just killed the one with count, and did one with no count specified - we'll see what happens
* ValarQ is of to bed as well
good night - and thanks - that worked (I knew it had to be really simple)
I'll be back later as well - off to dinner
SWPadnos_ is now known as SWP_Away
johnny nelson won ..
I gone - laters!
got a clue for me how to address the card during loadrt
not at ox0378 eh?
I can try that. just loadrt hal_ppmc 0x0378?
sorry, I wasn't clear
it defaults to 0x0378
okay. and how would i change that to 0xb800 if needed?
you can change it with a cmd line arg, but it uses the insmod array param syntax, and I'm not sure of it myself
I can look it up tho
funny - it was yabo who introduced that indmod capability, and it is nice
but he didn't document how you actually use it
rayh@ray64:~/emcdevelop/emc2$ sudo bin/halcmd loadrt hal_ppmc
insmod: error inserting '/home/rayh/emcdevelop/emc2/rtlib/hal_ppmc.ko': -1 Operation not permitted
HAL:0: ERROR: insmod failed, returned 1
look in the kernel log
should tell you why it failed, probably "no card found" because its checking port 0x378
no boards found on bus 0, port 0378
darn still can't use the scripts menu in tkemc.
try sudo bin/halcmd loadrt hal_ppmc port_addr=0xb800
I have a bad feeling that it won't like the hex tho
probably need to set a global so it knows where to look.
I had the board on 378 for that test
port is configured to work EPP?
Let me check my bios and make certain that we have a good parport.
jon has a diagnostic prog that can test board access
both the diag and the driver work here
gotta get alex to fix that make install stuff.
drives me nuts when basic stuff doesn't work.
I believe it loaded.
bad definition in the parport.
dmesg will tell you what it found
bin/halcmd show will show you the pins, etc, it exported if it found anything
the dmesg output is rather verbose right now, will be pared back later
I see em.
I'm working on a speedup that swp suggested, then I'll be moving on to the encoder and step parts
gotta connect to a thread and I think I can play with them.
I think getting the infrastructure down was the biggest hurdle tho, hopefully the rest will progress quickly
If I've got two boards on two parports, loadrt twice.
nope, can only load it once
the command line should take up to three port addresses
If I've got two boards on two parports, loadrt twice?
the only question is the syntax
I suppose I should figure that out
okay. We can look at that later. Keep on.