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