Back
[00:01:55] <petev> BTW, while we are on this subject
[00:01:53] <petev> there is a major nasty in the IniFile code
[00:01:53] <petev> it passed back a pointer to the middle of a static buffer
[00:01:53] <petev> no buffer is passed in via the API
[00:01:53] <petev> the code is not re-entrant
[00:01:53] <petev> what is the position on stuff like this?
[00:01:54] <SWPLinux> it would be non-reentrant per process, since each process that uses the ini has its own static var
[00:02:05] <SWPLinux> but multiple processes would have no trouble as is
[00:02:05] <petev> true
[00:02:23] <petev> but it's very ugly
[00:02:29] <petev> it means you can only get one var at a time
[00:02:36] <SWPLinux> yes
[00:02:46] <petev> kinda defeats the purpose of the try/catch in some ways
[00:03:50] <jepler> so change the C++ API to use std::string, moving the return-of-static-buffer to the C compatability layer only
[00:05:24] <petev> jepler, the C++ interface is used everywhere except for halcmd
[00:05:37] <petev> so all of the calling code will need editing
[00:05:51] <petev> I'm fine with that if everyone else is
[00:05:53] <jepler> oh sorry -- I was thinking in python
[00:06:00] <jepler> I forgot there's a cascade of changed variable and return types
[00:06:50] <jmkasunich> ignore it for now
[00:07:05] <alex_joni> night all
[00:07:07] <jmkasunich> aren't you thinking of changing this:
[00:07:12] <SWPLinux> see you Alex
[00:07:20] <jmkasunich> + if (NULL != (inistring = axisInifile->Find("FERROR", axisString))) {
[00:07:22] <jmkasunich> if (1 == sscanf(inistring, "%lf", &maxFerror)) {
[00:07:22] <jmkasunich> // found, and valid
[00:07:21] <jepler> write a manpage or other documentation so that one can at least say 'yes, that limitation is documented'
[00:07:22] <alex_joni> SWPLinux: it's 6 poles btw..
[00:07:30] <SWPLinux> ok :)
[00:07:38] <jmkasunich> to something that moves the scanf into the lib?
[00:07:49] <jmkasunich> if so, lots of those passed back strings won't be strings anymore
[00:07:56] <jmkasunich> and you'll be touching all the calls again
[00:08:00] <petev> yes, for double and int stuff it should clean up
[00:08:07] <jmkasunich> (again because you changed the names already)
[00:08:11] <petev> for string stuff it will be a problem
[00:08:26] <jmkasunich> I bet thats 10-20% of the total tho
[00:08:37] <petev> not sure
[00:08:54] <petev> but the calling code needs to be carefull when getting a string
[00:09:25] <petev> I wanted to check in some basic fix of the leaks before making the major changes
[00:09:57] <jmkasunich> you are using a doze editor aren't you?
[00:10:12] <petev> I use VI
[00:10:21] <jmkasunich> -/********************************************************************
[00:10:21] <jmkasunich> -* Description: inifile.cc
[00:10:21] <jmkasunich> -* C++ INI file reader
[00:10:21] <jmkasunich> -*
[00:10:21] <jmkasunich> +/*****************************************************************************
[00:10:23] <jmkasunich> + * Description: inifile.cc
[00:10:23] <jmkasunich> + * C++ INI file reader
[00:10:26] <jmkasunich> + *
[00:10:29] <jmkasunich> why is that in the diff?
[00:10:38] <petev> don't know
[00:10:42] <SWPLinux> spaces before the asterisks
[00:10:47] <jmkasunich> oh
[00:10:47] <alex_joni> more ** ?
[00:10:56] <petev> yes, that file is very changed
[00:11:01] <jmkasunich> geez
[00:11:03] <petev> the header for it too
[00:11:03] <jmkasunich> that we don't need
[00:11:42] <alex_joni> * alex_joni hates to see things like:
[00:11:42] <alex_joni> - Inifile *inifile;
[00:11:42] <alex_joni> + IniFile inifile;
[00:12:02] <petev> alex, that was so I could find all uses of the class and fix all the leaks
[00:12:10] <alex_joni> * alex_joni shrugs
[00:12:10] <petev> not to mention more readable
[00:12:20] <alex_joni> petev: it was inifile first
[00:12:30] <petev> no, Inifile
[00:12:36] <alex_joni> then some *insert_whatever* decided to change all those to Inifile
[00:12:39] <jmkasunich> mixed case vs all lower readability is a religious argument, not a statement of fact
[00:12:51] <alex_joni> petev: trust me.. it was inifile first
[00:13:07] <alex_joni> then someone decided to change them all to Inifile
[00:13:11] <petev> when I started on the file it was Inifile, can't say what it was before
[00:13:15] <alex_joni> now you're changing to IniFile
[00:13:22] <alex_joni> that is absurd imo
[00:13:25] <SWPadnos> INIFILE
[00:13:40] <alex_joni> SWPLinux: guess after enough versions we'll get there
[00:13:52] <SWPLinux> at least it's not InIfIlE
[00:14:05] <petev> alex, at least 5 files had leaks
[00:14:08] <alex_joni> petev: I'm sorry, but "find all uses" is really no reason in my eyes
[00:14:18] <alex_joni> petev: I agree about that, and I'm glad you fixed them
[00:14:18] <jmkasunich> why not use grep to find them?
[00:14:33] <alex_joni> but grep can find anything..
[00:14:33] <petev> because that finds the class name
[00:14:38] <petev> not the var names
[00:14:46] <alex_joni> just use grep -i -r ..
[00:14:48] <petev> yeah, and take 10 x longer
[00:14:59] <petev> then you have name like i
[00:15:15] <petev> how many places does that show in grep for nothing?
[00:15:17] <jmkasunich> so instead you make the diff 10x longer, and confuse others who want to look at it later
[00:15:33] <petev> I really didn't see the big deal
[00:15:39] <SWPLinux> ok. Pete - don't do that, use grep instead in the future. can we talk about the code now?
[00:15:40] <petev> a longer diff or fixed code
[00:15:52] <petev> SWPadnos, how will grep help
[00:16:00] <alex_joni> petev: this diff doesn't count as fixed code
[00:16:05] <alex_joni> at least not to me
[00:16:16] <alex_joni> (if there is something fixed in there, I probably missed it)
[00:16:21] <petev> the leaks are gone, the unused code is gone, what's not fixed?
[00:16:28] <SWPLinux> dunno. maybe I should say don't to cosmetic fixes at the same time as code changes
[00:16:32] <petev> exception support is added
[00:16:33] <alex_joni> petev: I'm sorry.. all I saw was case changes
[00:16:42] <petev> and foundation for future cleanup started
[00:16:49] <petev> not true
[00:16:53] <SWPLinux> but anyway, this is all senseless pounding on a drum that has been sounded before, and repeated here today
[00:16:55] <petev> all globals and news gond
[00:17:01] <petev> deletes removed
[00:17:06] <jmkasunich> there are 7 changed files, and at least one of them you said yourself the only change was nameing
[00:17:10] <petev> IniFile with expection support
[00:17:29] <alex_joni> petev: I do believe you that you might have fixed things
[00:17:33] <petev> jmk, I changes 20 something files
[00:17:40] <petev> about 6-7 had bugs
[00:17:42] <alex_joni> but the cvs emails usually get truncated after a certain size
[00:17:46] <jmkasunich> sorry, 7 commit messages
[00:17:57] <SWPLinux> hmmm - I have 8
[00:17:58] <jmkasunich> more than one file per message..
[00:18:08] <petev> I commited all at once
[00:18:30] <alex_joni> petev: if you have a large diff and most of it (beginning) are case changes, then the rest will be lost..
[00:18:33] <jmkasunich> but that makes my point even more - real changes to 7 files, but 20 have diffs
[00:18:48] <alex_joni> at least to people reading commit emails (like me) in order to keep in sync
[00:19:19] <SWPLinux> it's changes in 8 dirs, to however many files in each dir are affected
[00:19:24] <petev> so what's better, it would have taken forever to track down the usage of each var any other way
[00:19:48] <alex_joni> petev: for what I care you should have renamed them twice
[00:19:55] <alex_joni> if that's your method of opperandi
[00:19:59] <jmkasunich> petev: for finding all uses of a struct member, I comment it out in the declaration and do a make, see were the compiler barfs
[00:20:05] <jmkasunich> isn't that what you were doing?
[00:20:10] <alex_joni> that way you're sure you don't miss anything
[00:20:35] <petev> you would have to find all decl and comment them all
[00:20:55] <petev> I didn't think diffs were such a big deal
[00:21:13] <petev> much of the code is simply not readable largely due to formating
[00:21:19] <jmkasunich> dunno about other distributed projects, but for us they matter
[00:21:23] <petev> why wouldn't we want to fix it?
[00:21:55] <SWPLinux> whether or not it's ok to fix is separate from whether readability changes should be mixed with functional changes
[00:21:56] <alex_joni> petev: let me point one thing out to you..
[00:21:57] <jmkasunich> IF there is a formatting fix, (big if), that commit should be a formatting fix only
[00:22:11] <alex_joni> remember that you added CL to emc2 a while ago?
[00:22:16] <petev> yes
[00:22:22] <jmkasunich> but I guarantee you cradek and jepler would both object to a formatting fix
[00:22:26] <alex_joni> after a while some users needed a newer version
[00:22:35] <petev> ok
[00:22:42] <alex_joni> the problem is that no-one was able to isolate your changes to the code
[00:22:51] <alex_joni> because you touched too much of it
[00:22:56] <jmkasunich> because you made a ton of formatting changes
[00:23:01] <jmkasunich> perfect example
[00:23:00] <alex_joni> right
[00:23:00] <petev> alex, I didn't touch it for nothing
[00:23:08] <petev> I only fixed bugs
[00:23:10] <alex_joni> petev: I don't say you didn't
[00:23:14] <petev> the CL code is a mess
[00:23:19] <alex_joni> BUT.. it made all your changes useless
[00:23:20] <petev> and I din't just format it
[00:23:34] <petev> so how can you fix bugs if you can't change the code?
[00:23:36] <SWPLinux> not useless, lost in the chaff
[00:23:38] <alex_joni> CL was close to just as bad
[00:23:50] <jmkasunich> petev: when jepler tried to apply your fixes (the critical ones) to a later (just as messy) version of CL, he couldn't tell what was formatting and what was real
[00:23:51] <alex_joni> I don't argue about CL.. I know it sux
[00:23:58] <jmkasunich> because he was buried in a huge diff
[00:24:11] <alex_joni> basicly jepler had to do all your work again
[00:24:27] <petev> well the RT stuff was from scratch and the other stuff was bug fixes
[00:24:38] <jmkasunich> if you had made only functional changes, he could have extracted them and merged them with the newer version of CL
[00:25:11] <alex_joni> petev: might have been end-of-line changes too..
[00:25:26] <petev> jmk, as I recall we decided we didn't care about going back to the original CL because it was filled with bugs and we were making it run in HAL
[00:25:36] <petev> Paul C was arguing for alternate implementation
[00:25:39] <jmkasunich> we know that CL sucks, and it also sux that our version is a fork of theirs - because when they work on theirs, we can't pull in their changes
[00:25:45] <petev> now you take the other side
[00:26:05] <petev> well this was well discussed before CL was made to run in HAL
[00:26:09] <alex_joni> petev: that code is so crappy I wouldn't want to add new features
[00:26:18] <jmkasunich> well, I was wrong I guess
[00:26:23] <alex_joni> anyways, time for bed
[00:26:28] <alex_joni> gn all
[00:26:31] <petev> so why would you want to take the crappy code and debug it again
[00:26:35] <jmkasunich> fact is, the CL developer (who had been away for a while) came back and started making improvements
[00:26:38] <alex_joni> petev: I don't ..
[00:26:45] <jmkasunich> and our users wanted the improvements
[00:26:51] <alex_joni> if it doesn't work for them.. tehy can whine at the CL devel
[00:27:11] <petev> then you should get the CL dev to make a HAL version and maintain it
[00:27:27] <jmkasunich> and why is he gonna do that?
[00:27:34] <petev> exactly
[00:28:00] <petev> so we either write our own from scracth or take ownership of the HAL version
[00:28:13] <jmkasunich> so, we take his code, make the bare minimum of changes to make it work in our world, hold our noses about the mess, and use it
[00:28:31] <alex_joni> and report back bugfixes (as any OSS developer would)
[00:28:32] <jmkasunich> then when he fixes some of the mess, we take his better code, merge our limited changes, and use that
[00:28:40] <jmkasunich> if we want to fix his code
[00:28:42] <petev> well you try that next time, because that's basically what I did
[00:28:45] <jmkasunich> right, what alex said
[00:29:04] <alex_joni> petev: jepler did that with cl x.y.100 r whatever version that is
[00:29:08] <petev> that project was dead when I ported it
[00:29:16] <petev> I got no responses
[00:29:25] <jmkasunich> it came back
[00:29:31] <alex_joni> petev: again, we don't blaim you for doing all the hard work
[00:29:37] <alex_joni> it was really appreciated at the time
[00:29:43] <jmkasunich> you didn't know it was gonna come back, and we're not second guessing that decision
[00:29:45] <SWPLinux> this is a pointless discussion
[00:30:02] <jmkasunich> we ARE pointing out the consequences of really big diffs that don't show what really changed
[00:30:11] <SWPLinux> the point that readability/formatting and functional changes should be separated has been made quite clearly
[00:30:16] <alex_joni> SWPLinux: I was trying to make a point that case-changes or things similar like formating aren't usefull/helpfull in any case
[00:30:36] <alex_joni> SWPLinux: hopefully petev got that..
[00:30:40] <petev> alex_joni, so code readbility has no value?
[00:30:43] <SWPLinux> I understand that point, and I think Pete does as well. there's no sense in beating it to death, it only gets annoying
[00:30:46] <alex_joni> SWPLinux: guess not
[00:31:08] <petev> I don't see the big deal about fixing formating when the file is 80% changed
[00:31:18] <petev> the other files are a couple of lines and that's it
[00:31:49] <alex_joni> the problem will be in a couple of months/years
[00:32:02] <alex_joni> when someone looks at the diff for ioControl.cc for example
[00:32:20] <alex_joni> and they see case changes
[00:32:35] <alex_joni> but the commit message says something completely unrelated to namechanges
[00:33:21] <alex_joni> * alex_joni shuts up and goes to bed
[00:36:01] <SWPLinux> petev: could you agree to keep formatting/readability changes to a minimum in future commits?
[00:37:14] <petev> I can't really see the point of trying to clean up the code and then not cleaning it up, the only file with formating changes was 80% changed due to code issues
[00:37:41] <petev> the other files were as minimal as possible, other than the name change that I didn't think was a big deal
[00:37:51] <SWPLinux> I don't see that in the diffs - it looks like a lot of the changes are from inifile.open to inifile.Open and the like
[00:38:11] <jmkasunich> SWPLinux: thats the name change he was talking about
[00:38:21] <petev> I completely re-did th IniFile class and made names consistent
[00:38:22] <jmkasunich> a trick to reduce the labor in finding every use of the methods
[00:38:32] <petev> that effected some of the other files
[00:38:37] <petev> but only a couple of lines
[00:39:16] <jmkasunich> this is a real change:
[00:39:19] <jmkasunich> - if (inifile->valid() == false) {
[00:39:19] <jmkasunich> + if (!inifile.Open(filename)) {
[00:39:29] <jmkasunich> this is not:
[00:39:28] <jmkasunich> - Inifile *inifile;
[00:39:30] <jmkasunich> + IniFile inifile;
[00:39:45] <petev> agreed, but what's the big deal?
[00:40:11] <jmkasunich> we USE the diffs
[00:40:12] <petev> it would have been much more work and I may have missed something not changing the class name
[00:40:24] <jmkasunich> so extra long ones that don't represent real changes are a problem
[00:40:52] <jmkasunich> -* Description: inifile.cc
[00:40:52] <jmkasunich> + * Description: inifile.cc
[00:41:04] <petev> that whole file is 80% different
[00:41:10] <jmkasunich> is the extra space something your editor did? or just your preferred way to make boxes?
[00:41:10] <petev> and it's header
[00:41:32] <petev> I probably cleaned it up out of habit since that was a major edit
[00:41:36] <jmkasunich> still, why add a space in front of the comments?
[00:41:47] <petev> it does do auto formating, but probaly not there
[00:44:33] <jmkasunich> petev: I apologise - this is no way to treat someone who is willing to work on a project
[00:44:47] <petev> accepted
[00:46:25] <jmkasunich> I hope you can understand our concerns about diffs
[00:46:35] <jmkasunich> I gotta go to the grocery store, back later
[00:46:58] <petev> I understand, but when a file is 80% different, I didn't think formating would be an inssue
[00:49:08] <SWPLinux> I think inifile is totally changed, but the callers don't seem to be (though I haven't looked through it much)
[00:49:25] <petev> about 30% of the callers are
[01:56:40] <mshaver> just read back: I think the _real_ problem is that diff is too crude to separate the significant from the non-significant changes...
[01:57:03] <SWPLinux> patches gratefully accepted ;)
[01:57:14] <SWPLinux> err -graciously
[01:57:23] <SWPLinux> grotesquely?
[01:57:52] <mshaver> but, unfortunatley, not gratuitiously
[01:58:01] <SWPLinux> galdarnit!
[01:58:19] <SWPLinux> patches painfully pushed
[01:58:34] <SWPLinux> anyway - yes, you're probably right about that
[01:58:57] <mshaver> alright, back to my source code graphing research...
[01:59:09] <SWPLinux> graphs graciously grokked
[02:00:06] <mshaver> hopefully!
[02:00:12] <SWPLinux> hmmm - true
[02:00:14] <SWPLinux> :)
[02:09:23] <SWPLinux> yay! it's over 0 degrees here!
[02:09:28] <SWPLinux> up to 1
[02:10:08] <jmkasunich> wow
[02:10:29] <mshaver> From: man diff >>> -d --minimal - Try hard to find a smaller set of changes & -b --ignore-space-change - Ignore changes in the amount of white space.
[02:10:51] <SWPLinux> doesn't help with capitalization though
[02:10:58] <mshaver> true
[02:11:05] <SWPLinux> k
[02:11:08] <SWPLinux> oops]
[02:11:11] <SWPLinux> oops
[02:11:27] <mshaver> but caps are compilationally (a new word!) signficant
[02:11:44] <SWPLinux> yep
[02:11:59] <SWPLinux> that was a lot of the - ahem- discussion
[02:12:09] <SWPLinux> should "readability" fixes be done
[02:12:30] <SWPLinux> (at all, or as part of other functional changes)
[02:13:31] <petev> --ignore-case
[02:14:00] <jepler> I can --ignore-case; can you?
[02:14:02] <SWPLinux> yeah, though that would ignore significant changes, like fixing a typo :)
[02:14:29] <SWPLinux> troll!
[02:14:33] <jepler> * jepler gets out his dapper vmware guest and tries to get the emc2-sim package to build and install
[02:15:40] <jmkasunich> speaking of sim
[02:15:55] <jepler> jmkasunich: yes?
[02:15:58] <jmkasunich> I tried to rip on my dapper vm today (sim)
[02:16:07] <jmkasunich> and got a strange error from the runscript
[02:16:14] <jepler> it probably needs to be changed to /bin/bash
[02:16:15] <jmkasunich> I didn't have a chance to investigate
[02:16:38] <jmkasunich> it looked like it was trying to either loadusr or loadrt a program with no name
[02:16:38] <jepler> I only compiled the package, I didn't test it at all :-P
[02:16:47] <jmkasunich> this isn't a package
[02:16:51] <jmkasunich> rip
[02:16:53] <jmkasunich> --enable simulator
[02:17:08] <jepler> rm bin/inivar and rebuild it
[02:17:23] <jepler> there was a flag missing in the Makefile which makes inivar die with an error that the runscript helpfully hides
[02:17:27] <jepler> (can't find shared library)
[02:17:36] <jmkasunich> ok
[02:17:38] <jepler> that is, cvs up, rm bin/inivar, rebuild
[02:17:56] <jepler> sorry, I should have listened to what you were saying
[02:18:09] <jepler> so you are regularly running TRUNK sim on dapper? that's good to know
[02:18:49] <SWPLinux> I do that as well, on amd64-SMP
[02:19:02] <jmkasunich> not regularly
[02:19:08] <jmkasunich> the sim vm is on my work laptop
[02:19:10] <SWPLinux> well, me either
[02:19:27] <jmkasunich> I wanted to look up a hal pin name to answer yet another jack ensor question
[02:19:44] <jepler> oof -- I meant to say "edgy" way back up there at the top of this conversation
[02:19:58] <SWPLinux> heh - nevermind :)
[02:20:12] <jmkasunich> oops
[02:23:28] <jepler> aha -- now I understand one of the configure problems that paul_c refused to give a useful error report on
[02:23:47] <jepler> my code to test the version of xgettext assumed the version had three parts (e.g., 0.14.5) but this one has only two (0.15)
[02:24:37] <jmkasunich> its just so satisfying to click the "full screen" button on vmware and see WinXP replaced by Ubuntu ;-)
[02:24:58] <jepler> I bet
[02:25:10] <SWPLinux> I wonder if that would work on the high res screen
[02:25:30] <SWPLinux> in fact, I don't even get widescreen resolutions on this computer (the dual LCD one)
[02:26:02] <jmkasunich> when I go fullscreen, I have ubuntu at 1920x1200
[02:26:36] <jepler> is it still possible to get 1920x1200 15" laptops?
[02:26:37] <SWPLinux> yeah - I don't think I have non-4:3 aspect modes available in VMWare. I may in 6.0 beta though
[02:26:39] <jmkasunich> need a magnifying class to read the text, but I got lots of pixels
[02:26:52] <jepler> that's what mine is and I will hate to give it up when the laptop finally dies
[02:26:54] <SWPLinux> not 15" (I think), but 17" are available
[02:27:13] <jmkasunich> mine is 15
[02:27:15] <jmkasunich> Dell 820
[02:27:16] <SWPLinux> or the fine 19/20 inch 1680x1050 ones (ewwww)
[02:27:33] <SWPLinux> really - a new 15" 1920x1200 - interesting
[02:27:45] <jmkasunich> yep
[02:27:50] <jmkasunich> what are they now?
[02:27:56] <SWPLinux> oh - I was thinking of the 2048x1536 ones - those are no longer available (and never were in the US)
[02:28:30] <SWPLinux> high res in general isn't too popular - the "icons and text are too small" ...
[02:28:38] <SWPLinux> morons
[02:28:48] <jepler> a lot of websites suck pretty bad
[02:29:00] <jepler> 2" strip of text in the middle of the screen
[02:28:59] <SWPLinux> you should see them at 3840x2400
[02:29:17] <jmkasunich> jepler: rm bin/inivar, update, build and it works
[02:29:19] <SWPLinux> it's almost laughable when you have the corect dot pitch for X
[02:29:21] <jmkasunich> thanks
[02:29:41] <jepler> jmkasunich: sorry I porked it up in the first place
[02:43:40] <jmkasunich> drat
[02:44:03] <jmkasunich> my vhdl makefile doesn't deal with "include" files in other directories
[02:45:41] <jmkasunich> duh
[02:45:58] <jmkasunich> it does too... as long as the dumb user puts the right path in the include directive
[02:46:43] <jepler> is "---" a comment in vhdl?
[02:46:49] <jmkasunich> -- is
[02:46:59] <jepler> just looking at that Makefile
[02:47:05] <jmkasunich> --- is a comment to vhdl, and a clue to the makefile
[02:47:21] <jmkasunich> there is no real include directive, so I fake it
[02:47:42] <jepler> yep, I see
[02:49:13] <jmkasunich> http://www.pastebin.ca/384486
[02:49:18] <jmkasunich> that might help
[02:49:23] <jmkasunich> notes about the design flow
[02:49:31] <jmkasunich> (dunno if I already posted that or not)
[02:49:45] <jepler> If you did, I missed it
[02:49:51] <jepler> worth putting in a README file in that dir?
[02:50:00] <jmkasunich> definitely in the plan
[02:50:31] <petev> jmk, do you know about packages in vhdl?
[02:50:57] <jmkasunich> you mean dips and 208 pin quad flat packs? ;-)
[02:51:10] <SWPLinux> those would be packages full of VHDL
[02:51:22] <petev> no, take a look at tha package and use statements
[02:51:33] <jmkasunich> libraries by another name?
[02:51:50] <SWPLinux> yes, though there are also libraries in VHDL
[02:51:58] <SWPLinux> http://eng.auburn.edu/department/ee/mgc/vhdl.html
[02:53:09] <jmkasunich> I don't see any entities in their sample package
[02:53:18] <jmkasunich> just constants, types and functions
[02:53:21] <petev> you should also look at multiple architectures and the configuration statement for multiple builds
[02:53:32] <jmkasunich> no I should not ;-)
[02:53:41] <SWPLinux> well, I'm good at finding crappy language explanation pages
[02:53:49] <jmkasunich> I have one target, with another possible single target in the future
[02:54:04] <petev> those are VHDL keywords
[02:54:20] <jmkasunich> what are?
[02:54:25] <jmkasunich> multiple architectures?
[02:54:27] <petev> they let you use the same top level with different implementations
[02:54:35] <petev> yes, architecture
[02:54:41] <jmkasunich> heh, thats the exact opposite of my goal
[02:54:54] <jmkasunich> I want different top levels (some with more encoders and less stepgens, etc)
[02:55:07] <SWPLinux> you may want both
[02:55:09] <jmkasunich> based on a set of underlying stuff
[02:55:27] <SWPLinux> same config in 5i20 and 5i22 would end up with possibly different implementations
[02:55:27] <jmkasunich> SWPLinux: why?
[02:55:41] <SWPLinux> but you want the same thing presented to the driver
[02:55:44] <jmkasunich> you mean a stepgen block would be differnt?
[02:55:49] <petev> a read throught the ieee library is very educational
[02:55:59] <petev> there is some cool stuff in there
[02:56:04] <SWPLinux> more like the aieeee library ;)
[02:57:12] <jmkasunich> you mean a stepgen block would be different?
[02:58:33] <SWPLinux> it may be, but ideally not
[02:58:56] <SWPLinux> it depends on optimization, I bet
[02:58:55] <jmkasunich> it would have to be the same from a register point of view, to not break the driver
[02:59:35] <SWPLinux> sure, but there may be extended capabilities (exposed to the driver), such as higher base clocks for PWM or the like
[03:00:06] <jmkasunich> the top level vhdl for each config will be unique
[03:00:11] <SWPLinux> so the driver would still handle it, but the underlying "parts" are a little different depending on the chip
[03:00:31] <jmkasunich> so if I want stepgena for the 5i20 and stepgenb for the 5i22, I'd just invoke the right one in the top level file
[03:00:35] <SWPLinux> true, but not necessarily for each card that config may go on
[03:00:50] <jmkasunich> huh?
[03:01:04] <SWPLinux> ie, you could have exactly one top level "8 stepgen + 16 input + i6 output" config (or whatever)
[03:01:14] <jmkasunich> for both boards?
[03:01:19] <SWPLinux> another top level config for PWM instead of stepgen
[03:01:21] <SWPLinux> yes
[03:01:32] <jmkasunich> that makes no sense, since one board has space for so much more than the other board
[03:01:55] <jmkasunich> the 5i22 would have 24 stepgan and 24 encoders and 16 pwm or whatever
[03:02:01] <SWPLinux> but using different architectures/implementations, you can have those toplevels use the correct lower level funcs for each board
[03:02:06] <SWPLinux> (if I understand correctly)
[03:02:18] <SWPLinux> that would be a different config
[03:02:35] <jmkasunich> I really don't understand what you are getting at
[03:02:42] <petev> yes, that's true
[03:02:48] <jmkasunich> there needs to be two differnt toplevel vhdls for the two boards
[03:02:50] <SWPLinux> so someone who has config foo on a 5i20 could replace their pile of char (after a lightning strike, say) with a 5i22, and have exactly the same config (on the first 3 connectors) as before
[03:02:55] <petev> say for instance some memory block is different
[03:03:00] <petev> bewteen the 2 chips
[03:03:10] <petev> and one of the modules needs to use a memory block
[03:03:21] <petev> there could be a different configs of that module
[03:03:29] <petev> so it would work on both
[03:03:44] <jmkasunich> I think you guys are making this far more complicated than it needs to be
[03:03:52] <SWPLinux> no - it gets simpler this way
[03:03:58] <jmkasunich> top1.vhd includes whatever lower vhds it needs
[03:04:03] <jmkasunich> top2.vhd does the same
[03:04:08] <petev> I was just suggesting you look at those features before writing too much
[03:04:14] <jmkasunich> if some lower vhds are the same for both, that ok
[03:04:19] <petev> packages should eliminate the need for any kind of include
[03:04:20] <jmkasunich> if they are not the same, thats ok two
[03:04:54] <SWPLinux> think of it as a single PCB that has different resistors populated depending on what particular sensor is there
[03:05:05] <SWPLinux> (like a pressure sensor or something)
[03:05:20] <SWPLinux> the output of the board (the top level interface) is a voltage proportional to pressure
[03:05:40] <SWPLinux> the bottom level (the PCB) can use several differnt parts for the sensor
[03:05:42] <jmkasunich> right - each board has a different bill of materials, that matches the sensor with the resistors
[03:05:55] <SWPLinux> the middle part (the scaling) needs to be chosen depending on the lower level
[03:06:05] <jmkasunich> and the bom calls out the bareboard, the sensor, and the resistors
[03:06:16] <jmkasunich> my toplevel vhdl with the include directives is the bom
[03:06:17] <jmkasunich> done already
[03:06:36] <petev> well that's not really the right way to do it
[03:06:49] <petev> that's what architectures and configs are for
[03:07:01] <SWPLinux> variants are a way of selecting from several sets of sub-BOMs which are the glue between the top level (what functions you want) and the bottom level (what specific ally needs to be done on each FPGA)
[03:07:21] <jmkasunich> sub boms just sound like more work
[03:07:28] <petev> architectures are different implementations of the same function
[03:07:30] <SWPLinux> they're less work overall
[03:07:36] <SWPLinux> look at it this way
[03:07:40] <petev> they are less and they insure the same interface
[03:08:02] <SWPLinux> if a ROM block is different for the two (or more) boards you want to support, then the VHDL for each board has to be written anyway
[03:08:18] <petev> the entity is the interface, the architecture is the implementation
[03:08:32] <SWPLinux> with this scheme, you can stick all variants into a single entity, with information on how to select which one gets used
[03:08:33] <petev> a configuration selects the proper architectures for the design
[03:08:48] <SWPLinux> then the top level file doesn't even need to know what chip is being used
[03:09:26] <jmkasunich> if the top level file doesn't know what chip is being used, then how does that info get into the tools?
[03:09:31] <SWPLinux> so you have one top level for each *functional* configuration, but it's the same across all boards that are supported
[03:09:47] <SWPLinux> command line option, for one
[03:09:51] <jmkasunich> eww
[03:10:06] <SWPLinux> makefile ...
[03:10:22] <SWPLinux> you run the same files through the make for each target board
[03:10:24] <jmkasunich> my goal is that one toplevel file = one bitfile = one config on one board
[03:10:29] <jmkasunich> and no other info is needed
[03:10:35] <SWPLinux> with different options - that's not ewww, that's how it's supposed to work
[03:10:55] <SWPLinux> that's not an ideal goal, IMO
[03:11:10] <jmkasunich> why not?
[03:11:26] <SWPLinux> because it requires you to duplicate work for each new board that you want to support
[03:11:40] <jmkasunich> which is likely to be 1 more board
[03:11:56] <jmkasunich> and there is no reason whatsoever to offer the exact same config on the big board as on the little board
[03:11:58] <SWPLinux> you will end up with 2 or 3 or 5 copies of each functional config, which is unnecessary
[03:12:11] <jmkasunich> because there is more gates and I/O, it would be dumb not to use them
[03:12:16] <SWPLinux> any change to the structure will require changes to several files - that's a no-no
[03:12:26] <jmkasunich> no it won't
[03:12:46] <SWPLinux> ok, so the 5i20 can only have 3 foobars, but the 5i22 can have 10 - that's another functional config that has no 5ui20 variant
[03:12:52] <jmkasunich> the same "stepgen.vhd" file will be included in all top levels (that use stepgens)
[03:13:08] <jmkasunich> unless stepgen.vhdl is found to not work on the 2nd device
[03:13:28] <jmkasunich> you'd never need the 3 foobar config on the 5i22
[03:13:32] <SWPLinux> I'm not talking about the functions, I'm talking about the top level stuff - how the ROM block is structured, changing the magic number(s), adding a new code for a different function ...
[03:14:01] <SWPLinux> ie, the interface between the driver and the functional blocks in this config
[03:14:02] <jmkasunich> the rom block is gonna be in a subfile
[03:14:06] <jmkasunich> only its content changes
[03:14:25] <jmkasunich> and with any luck at all that will be autogenerated
[03:14:38] <jmkasunich> I don't want to edit a list of 256 32bit numbers by hand
[03:15:12] <jmkasunich> lets back up and stop talking generalities
[03:15:20] <SWPLinux> ok
[03:15:25] <jmkasunich> entity: equicalent to a function declaration
[03:15:40] <jmkasunich> architecture: equivalent to a function implementation
[03:15:48] <jmkasunich> component: equivalent to a function prototype
[03:15:54] <jmkasunich> (as far as I can tell)
[03:16:05] <jmkasunich> component needs to be in the file that uses the entity
[03:16:14] <jmkasunich> entity and arch are in the file that defines it
[03:16:18] <jmkasunich> right so far?
[03:16:40] <petev> no, not exactly
[03:16:51] <petev> entity is the function interface
[03:16:54] <SWPLinux> a component is an instance, no?
[03:17:01] <jmkasunich> no
[03:17:05] <petev> component is basically the same thing but for the package
[03:17:09] <SWPLinux> ah
[03:18:07] <jmkasunich> http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/m5i20/hostmot5-4e.vhd?rev=1.3
[03:18:27] <jmkasunich> no line numbers unfortunately
[03:18:40] <jmkasunich> but about 1/4 of the way down are a bunch of component declarations
[03:18:45] <SWPLinux> http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/m5i20/hostmot5-4e.vhd?annotate=1.3
[03:18:49] <jmkasunich> basically they are function prototypes
[03:19:12] <jmkasunich> handy
[03:19:24] <SWPLinux> yes
[03:19:26] <jmkasunich> line 237: component
[03:19:35] <jmkasunich> line 371, invocation
[03:19:50] <SWPLinux> invocations
[03:19:58] <jmkasunich> nitpicker
[03:19:59] <SWPLinux> instantiations, actually
[03:20:01] <petev> that's a generate loop
[03:20:10] <petev> it instantiates muliple components
[03:20:18] <jmkasunich> nitpicker
[03:20:25] <jmkasunich> single invocation line 441
[03:20:27] <SWPLinux> necessary with language (and fun :) )
[03:20:38] <petev> just clarifying as you can use it for the number of PWM gens or whatever
[03:20:48] <jmkasunich> two differnt ways, both result in an instance of the componet
[03:20:57] <jmkasunich> and I could even mix them
[03:21:12] <jmkasunich> my point was that component in the invoking file serves as the prototype
[03:21:30] <jmkasunich> now lets look at a defining file
[03:21:40] <jmkasunich> http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/m5i20/countere.vhd?annotate=1.2.2.1
[03:21:49] <jmkasunich> 46: entity
[03:21:53] <SWPLinux> one sec - is that an error in the counter and secondary counter generate loops?
[03:21:53] <jmkasunich> 65 arch
[03:22:00] <petev> components are usually put inside a package, then the package is used
[03:22:14] <SWPLinux> they have the same name (counterx:...)
[03:22:32] <jmkasunich> SWPLinux: dunno, might be, there is supposed to be some problem with the secondary counters in this config
[03:22:38] <jmkasunich> I just grabbed it as an example
[03:23:00] <SWPLinux> ok - that's a different problem - look at how i is used in the two loops and you'll see it
[03:23:22] <jmkasunich> I think counterx might be local to the loop
[03:23:24] <jmkasunich> lets not digress
[03:23:27] <SWPLinux> ok - anyway, go on
[03:23:42] <jmkasunich> in the defining file, there is entity and arch
[03:23:50] <jmkasunich> pete said somethign about packages
[03:24:05] <SWPLinux> like a 74ls00 package, with multiple <mumble> gates in it
[03:24:13] <petev> yes, u usually put the components in a package then use it
[03:24:26] <jmkasunich> the generate loop takes care of multiple I think
[03:24:28] <petev> it's like putting them in one header and including it
[03:24:39] <petev> vs putting them in every C file
[03:24:50] <jmkasunich> more like a library
[03:25:08] <SWPLinux> ok, so package is more or less a struct of components
[03:25:08] <petev> similar, but analogous to header files
[03:25:11] <jmkasunich> the vhdl files are the C files
[03:25:18] <petev> SWPadnos, yes
[03:25:27] <petev> jmk, yes
[03:25:47] <petev> VHLD has a notion of a working dir
[03:25:52] <jmkasunich> there are no .h files (at least the way these files are done)
[03:26:04] <petev> everything u compile goes in there by default
[03:26:12] <petev> and is then available to be used by other modules
[03:26:20] <jmkasunich> it struck me as strange that the components had to be listed in the top level file, they are the same as the entities in the defining file
[03:26:26] <petev> so you don't really need to make a library unless you want to
[03:26:26] <jmkasunich> except for the first word
[03:26:48] <petev> yesh, there is some verboseness to VHDL, it's the main complaint about it
[03:27:12] <SWPLinux> think of it like having a function protptype then the implementation with the exact same parameters and return type
[03:27:26] <jmkasunich> you mean in the defining file?
[03:27:36] <petev> I think jmk is complaining about component/entity
[03:27:43] <petev> they are basically the same
[03:27:45] <jmkasunich> not complaining really
[03:28:08] <jmkasunich> just observing - in C, you'd have a single prototype in a header
[03:28:11] <SWPLinux> "restlessly observing" ;)
[03:28:23] <jmkasunich> then the definition in the defining file, and an invocation in the using file
[03:28:27] <petev> yes, that's similar to a package
[03:28:39] <petev> except you still get stuck with the one entity thing
[03:28:50] <jmkasunich> with vhdl, you have one prototype in the defining file (called entity) and another prototype in the using file called component
[03:29:00] <petev> so many using files can all use the package
[03:29:15] <petev> shouldn't have them in the using file
[03:29:18] <petev> that's bad style
[03:29:22] <petev> a package is better
[03:29:29] <jmkasunich> you mean all the components?
[03:29:32] <SWPLinux> thta's what peteW seems to do
[03:29:41] <petev> yeah, it's not real good
[03:29:52] <petev> what if two files want to use the same component?
[03:29:52] <SWPLinux> ok, that implies that it's not necessary :)
[03:30:00] <petev> then you have to duplicate it again
[03:30:10] <jmkasunich> duplicate what, the component declaration?
[03:30:14] <petev> yes
[03:30:18] <jmkasunich> thats no biggie
[03:30:24] <petev> but if you put it in a package, you don't have to
[03:30:32] <SWPLinux> it is if something changes
[03:30:32] <jmkasunich> but thats what I meant by "seems like there should be .h files"
[03:30:37] <petev> well it is if you make a typo or have to make a change to it
[03:30:40] <jmkasunich> only if the interface changes
[03:30:50] <jmkasunich> and if the interface changes, every invocation will change anyway
[03:30:50] <petev> then you have to change it all over the place
[03:31:06] <jmkasunich> if you add a pin to the interface, you gotta connect it when you invoke the comp
[03:31:06] <SWPLinux> it looks like pete is saying that you don't need them - just make packages and use them, and you get the "headers" without includes
[03:31:13] <SWPLinux> (more like import in python)
[03:31:44] <petev> for a package you just say package packageName is allTheComponents end
[03:32:01] <petev> then you only have it in one place plus the entity
[03:32:02] <jmkasunich> so instead of having components for counter, stepgen, pwmgen, I'd have packages for counter, stepgen, pwmgen
[03:32:16] <petev> no, all in one package if you want
[03:32:21] <jmkasunich> and I'd have some (hopefully shorter) stanzas in my top level to fetch those
[03:32:27] <jmkasunich> I don't want I don't think
[03:32:47] <jmkasunich> if one particular top level doesn't use stepgen, I don't want to rebuild it if only stepgen changed
[03:32:57] <petev> the components are nested in the package
[03:33:09] <petev> then the package can be used, like a header include
[03:33:26] <SWPLinux> if you stick a pwmgen+stepgen+counter in a package, can you instantiate different quantities of them (ie, 2 stepgens, 6 PWMs, and 4 counters)?
[03:33:38] <petev> sure
[03:33:38] <jmkasunich> but how does the toolchain know that a particular toplevel design only uses half of the comps in the package?
[03:33:43] <SWPLinux> ok - cool
[03:33:53] <petev> it just eliminates having to have component statements in every file that uses one
[03:33:54] <jmkasunich> SWPLinux: you'd do that with generate loops
[03:34:08] <jmkasunich> the pacakge only replaces the component declarations in the toplevel
[03:34:13] <petev> jmk, because you have to instantiate them
[03:34:16] <SWPLinux> sure - just wondering how struct-like packages actually are ;)
[03:34:26] <jmkasunich> there not struct like
[03:34:33] <jmkasunich> more header like
[03:34:38] <petev> the format is, but that's about it
[03:34:46] <SWPLinux> sure
[03:34:50] <jmkasunich> you can declare a funct in a header, and use it zero or 1 or N times
[03:35:02] <petev> for instance, line 355 does not instantiate anything
[03:35:15] <petev> line 371 does
[03:35:38] <jmkasunich> why doesn't 355 instantiate anything
[03:35:45] <jmkasunich> duh
[03:35:50] <jmkasunich> its a component thats why
[03:35:54] <petev> it's just the component statement
[03:36:03] <jmkasunich> right, I already knew that
[03:36:09] <petev> it's what would be in the header
[03:36:36] <jmkasunich> lines 237 thru 364 are the "header"
[03:36:54] <petev> yes
[03:36:58] <jmkasunich> 410 and 429 (among others) instantiate things
[03:37:06] <jmkasunich> back to my question:
[03:37:06] <petev> yes
[03:37:33] <jmkasunich> if I put all my comps in one package, then lines 237-364 are replaced by a single package invocation - nice
[03:37:42] <petev> yes
[03:37:48] <jmkasunich> but - how do I know whether the design actually uses all of those comps
[03:37:51] <petev> like this
[03:37:54] <petev> use packageName.all
[03:38:08] <petev> because you still have to instantiate them
[03:38:22] <jmkasunich> ok, I need a much smarter make system then
[03:38:24] <petev> it's like including a header, but not calling all of the functions
[03:38:30] <SWPLinux> it seems much like import in python
[03:38:44] <petev> don't really know python
[03:38:45] <SWPLinux> import allows you to use functions, but it doesn't make all the functions used
[03:38:57] <jmkasunich> maybe I should explain one thing I'm doing with my ---include
[03:39:04] <petev> if you want to really specify you can do stuff like
[03:39:07] <SWPLinux> you can also import only certain functions (has to do with namespaces)
[03:39:13] <petev> use packageName.componentName
[03:39:21] <petev> you don't have to say .all
[03:40:02] <jmkasunich> my makefile builds a list of dependencies... toplevelA uses stepgen and pwmgen, toplevelB uses pwmgen and encoder, toplevelC uses all three
[03:40:15] <petev> here's a couple of examples of lib and package
[03:40:21] <petev> library ieee;
[03:40:21] <jmkasunich> then if you change stepgen.vhdl, it only rebuilds toplevel A and toplevelC
[03:40:21] <petev> use ieee.std_logic_1164.all;
[03:40:21] <petev> use work.airLinkMiiCorePkg.all;
[03:40:47] <jmkasunich> I get the notation
[03:41:01] <jmkasunich> I just don't get how it lets me handle dependencies
[03:41:08] <jmkasunich> read back what I said about my makefile
[03:41:13] <petev> well that's something else
[03:41:26] <petev> most VHDL compilers have a feature for that the same as for C
[03:41:35] <petev> you give it a flag and it generates the deps
[03:41:41] <jmkasunich> I'm not compiling, I'm synthesizing
[03:41:56] <petev> it's two steps
[03:42:23] <petev> then usually place/route after that
[03:42:24] <jmkasunich> more than that ;-)
[03:42:47] <jmkasunich> synthesis; ngdbuild; map; place; route; bitgen
[03:42:49] <SWPLinux> no-one expects the spanish inquisition!
[03:43:01] <jmkasunich> place and rout could be combined, but I split them
[03:43:05] <SWPLinux> 6, yes 6 steps ...
[03:43:32] <petev> why are deps involved after the compile?
[03:43:43] <SWPLinux> in case the source changes
[03:44:09] <jmkasunich> you go thru the chain for each toplevel, to produce each bitfile
[03:44:13] <petev> but there would be an intermidiate file for that dep, no?
[03:44:28] <jmkasunich> no, all the files are merged in the very first step
[03:44:48] <petev> right, then after that it;s the intermediate file only
[03:44:53] <jmkasunich> *.vhd becomes foo.ngc during synthesis
[03:45:07] <jmkasunich> if any of *.vhd changes, you do everything over
[03:45:10] <petev> so the deps that come from VHDL use stuff are for the fisrt step
[03:45:39] <jmkasunich> I _could_ extract dep info from use statements
[03:45:50] <jmkasunich> assuming that entitiy names map 1:1 with filenames
[03:45:52] <petev> the compiler should have a flag for it
[03:46:07] <petev> I know model sim does
[03:46:13] <jmkasunich> this isn't a compiler
[03:46:17] <petev> I would hope the xilinx tools do too now
[03:46:25] <petev> what is the first step called?
[03:46:29] <jmkasunich> synthesis
[03:46:33] <jmkasunich> the tool is xst
[03:46:43] <jmkasunich> http://www.pastebin.ca/384486
[03:46:44] <petev> there is no compile before the synth?
[03:46:56] <jmkasunich> read line 35-75
[03:47:08] <jmkasunich> that is synthesis, as best I can figure from studying the docs for three days
[03:47:23] <jmkasunich> note the main input is a .prj file that tells it what .vhd files to read
[03:47:44] <jmkasunich> their IDE makes you choose the source files that are part of the project
[03:47:56] <jmkasunich> I create the .prj on the fly using my ---include directives
[03:48:07] <petev> seems like xilinx has merged a few of the normal steps
[03:48:13] <jmkasunich> could be
[03:48:25] <petev> so their tool doesn't have any way to generate deps?
[03:48:30] <jmkasunich> nope
[03:48:38] <jmkasunich> you tell it the deps with the .prj file
[03:49:20] <jmkasunich> I agree that if package:entity could be mapped to filename, I could create the prj file by reading use statements instead of ---include directives
[03:49:26] <SWPLinux> it should function without a .prj file
[03:49:38] <SWPLinux> I'm trying to remember exactly how though
[03:50:13] <petev> the old xilinx used to force one entity per file and matching names
[03:50:17] <petev> I hated it
[03:53:09] <jmkasunich> http://www.xilinx.com/support/sw_manuals/xilinx82/download/dev.zip or
http://www.xilinx.com/support/sw_manuals/xilinx82/download/dev.tar.gz is the manual that lists the flow, and what all the command line tools expect
[03:53:51] <petev> u could use the old xilinx limitations if you can live with them
[03:54:05] <jmkasunich> one package per vhdl file
[03:54:13] <petev> yes, and matching names
[03:54:20] <petev> actually one entity
[03:54:25] <jmkasunich> use package:all = depends on package.vhdl
[03:54:35] <petev> you wouldn't be able to use all
[03:54:36] <jmkasunich> I hope entities nest
[03:54:48] <petev> you would have to say use package.component
[03:54:57] <petev> then component.vhd is the file
[03:55:21] <petev> you can nest instantiations
[03:55:21] <jmkasunich> stepgen.vhd could contain entities dds, pulseout, and quadout for example
[03:55:32] <petev> I don't think you can nest declarations
[03:55:50] <jmkasunich> I would say use stepgen:all because if I instantiate stepgen, I need dds, pulseout, and quadout
[03:55:53] <petev> yes, real tools should handle that
[03:55:55] <jmkasunich> oops, mistake earlier
[03:56:03] <jmkasunich> stepgen.vhd could contain entities stepgen, dds, pulseout, and quadout for example
[03:56:22] <petev> I understand
[03:56:25] <jmkasunich> stepgen is the only one I'd actually instantiate directly
[03:56:37] <petev> I was just pointing out how old xilinx stuff worked
[03:56:40] <jmkasunich> ok
[03:56:51] <petev> the real tools generate the deps for you
[03:57:11] <jmkasunich> now - if I wanted to do that (to eliminate the component declarations), how do I generate packages?
[03:57:23] <jmkasunich> and what kind of files are they - separate from the .vhd I assume?
[03:57:34] <jmkasunich> or is it just a package statement inside the vhd
[03:57:37] <petev> put the package in a .vhd file
[03:57:39] <petev> yes
[03:57:44] <petev> with tht components inside
[03:57:46] <petev> the
[03:58:01] <jmkasunich> so the defining vhd would be:
[03:58:03] <jmkasunich> package {
[03:58:07] <jmkasunich> comp{
[03:58:10] <jmkasunich> stepgen
[03:58:12] <jmkasunich> }
[03:58:12] <jmkasunich> {
[03:58:14] <jmkasunich> oops
[03:58:15] <jmkasunich> }
[03:58:19] <jmkasunich> entity {
[03:58:22] <petev> almost
[03:58:23] <jmkasunich> stepgen
[03:58:25] <jmkasunich> }
[03:58:28] <jmkasunich> arch {
[03:58:32] <jmkasunich> implementation of stepgen
[03:58:35] <jmkasunich> {
[03:58:38] <jmkasunich> dammit
[03:58:39] <jmkasunich> }
[03:58:55] <petev> you start and end the package like this
[03:59:00] <jmkasunich> I'm gonnt try again without the {}
[03:59:02] <jmkasunich> package
[03:59:03] <petev> package packageName is
[03:59:05] <jmkasunich> stepgen
[03:59:07] <petev> component
[03:59:08] <jmkasunich> dds
[03:59:10] <petev> end
[03:59:17] <petev> end
[03:59:18] <jmkasunich> thats syntax
[03:59:24] <petev> yes
[03:59:28] <jmkasunich> {}, is/end, not important
[03:59:30] <petev> your idea is correct
[03:59:34] <jmkasunich> the nesting is what I was trying to get
[03:59:38] <jmkasunich> package
[03:59:41] <jmkasunich> comp1
[03:59:43] <jmkasunich> comp2
[03:59:45] <jmkasunich> comp2
[03:59:47] <jmkasunich> oops
[03:59:49] <jmkasunich> comp3
[03:59:52] <jmkasunich> entity
[03:59:55] <jmkasunich> entity1
[03:59:59] <jmkasunich> arch
[04:00:04] <jmkasunich> implemnt 1
[04:00:07] <jmkasunich> entity
[04:00:10] <jmkasunich> entity2
[04:00:13] <jmkasunich> arch
[04:00:16] <jmkasunich> implement2
[04:00:19] <jmkasunich> something like that
[04:00:31] <jmkasunich> without the oopses
[04:00:31] <petev> I don't think you can nest entity like that
[04:00:39] <petev> but what would that do anyhow?
[04:00:42] <jmkasunich> entity1 is a mistake
[04:00:57] <jmkasunich> not mistake - poor choice of words
[04:01:01] <jmkasunich> package
[04:01:03] <jmkasunich> comp
[04:01:05] <petev> you can put multiple components in a package
[04:01:06] <jmkasunich> foo
[04:01:07] <jmkasunich> bar
[04:01:17] <jmkasunich> fsck, I keep screwing this up
[04:01:23] <jmkasunich> I can think faster than I can type
[04:01:26] <jmkasunich> lemme pastebin it
[04:01:30] <petev> ok
[04:02:51] <jmkasunich> http://www.pastebin.ca/384540
[04:03:06] <jmkasunich> indentation represents the "is" and "end" stuff
[04:03:23] <jmkasunich> did I get it right?
[04:03:46] <petev> yes, you can do that
[04:03:54] <jmkasunich> the package has a name, call it foobarbaz
[04:03:59] <petev> but not in the old xilinx tools ;-)
[04:04:04] <jmkasunich> in my case, I'd make it match the name of the file
[04:04:09] <petev> sure
[04:04:26] <jmkasunich> then use foobarbaz would tell the makefile that the toplevel depends on foobarbaz.vhd
[04:04:34] <petev> yes
[04:04:41] <jmkasunich> and I would not need those comp declarations in the top level
[04:04:48] <petev> yes
[04:05:00] <jmkasunich> that sounds like a win - gonna try it
[04:05:13] <petev> and if you had some basic stuff like counters, you would just put the use packageName in each file
[04:05:18] <petev> that used them
[04:05:59] <jmkasunich> peter doesn't use predefined counters
[04:06:07] <jmkasunich> he just builds them as needed in vhdl
[04:06:14] <petev> RTL level VHDL is the most portable
[04:06:25] <petev> but sometimes the memory blocks are trouble
[04:06:26] <jmkasunich> if event= clock and clock=1 then count = count-1
[04:06:34] <petev> and you have to instantiate library cells
[04:06:37] <jmkasunich> oh, because they use device specific macros
[04:06:40] <petev> yes
[04:06:55] <petev> that's where the configs and multiple archs come in
[04:07:07] <petev> as well as for number of stepGens and the like
[04:07:29] <jmkasunich> generate loops will handle the latter
[04:07:53] <jmkasunich> peter's ram:
http://www.pastebin.ca/384544
[04:07:59] <petev> right and different configs can generate different number
[04:08:27] <petev> usually you can specify the config for your top level entity when you compile
[04:08:28] <jmkasunich> hey, you convinced me to use packages - call that a win
[04:08:35] <petev> then it's a simple makefile thing
[04:08:40] <jmkasunich> I'm not using anything else - one toplevel for one output
[04:08:44] <petev> ok
[04:09:06] <jmkasunich> the other thing I'm trying to manage is to be able to change the ram content after place and route
[04:09:24] <jmkasunich> as you can see from the pastebin, the ram content is hardcoded
[04:09:31] <jmkasunich> I don't want one vhdl per config
[04:09:42] <jmkasunich> there are tools to merge ram data with the bitstream
[04:09:46] <jmkasunich> and they work
[04:09:53] <jmkasunich> but you have to know which ram block to put the data in
[04:09:58] <petev> hmm
[04:10:17] <jmkasunich> there is supposed to be a flow that lets you spec the block by a logical name pre-place/route
[04:10:30] <jmkasunich> and it generates a file post-p/r that tells the data merger where the ram is
[04:10:35] <petev> ok, why not multiple archs and select with a config?
[04:10:38] <jmkasunich> I haven't been able to get that to work
[04:10:53] <jmkasunich> I don't see the relavance
[04:11:14] <petev> you could have multiple archs for the ram
[04:11:17] <petev> each with different data
[04:11:26] <petev> then select the right arch in a config
[04:11:26] <jmkasunich> I want to replace the constant data in that single ram.vhd file with app specific data
[04:11:41] <petev> I don't understand
[04:11:46] <jmkasunich> if I change the arch, I go all the way back to the beginning, and re do the entire path
[04:11:51] <petev> is thi header stuff to tell what's in the FPGA?
[04:11:59] <jmkasunich> data2mem lets me change the ram contant after the place and route and bitgen
[04:12:06] <jmkasunich> bitfile in, modified bitfile out
[04:12:19] <petev> what is the ram data?
[04:12:32] <jmkasunich> it tells the driver what is in the fpga
[04:12:36] <petev> right
[04:12:42] <petev> so why not use archs and configs?
[04:13:02] <jmkasunich> bacause I haven't told you the whole story ;-)
[04:13:05] <petev> do you want some type of autogen for the ram?
[04:13:18] <petev> based on FPGA config?
[04:13:21] <jmkasunich> suppose the config has 8 stepgen, 8 encoder, and 8 pwm
[04:13:49] <jmkasunich> there are general purpose I/O attached to every pin, and if I turn off stepgen3, for example, those GPIO become available
[04:14:03] <jmkasunich> so the ram will say not only what is there, but whether you want it on or not
[04:14:14] <petev> ok, I follow
[04:14:21] <petev> but do you want to autogen it?
[04:14:28] <petev> or do you do it by hand?
[04:14:33] <jmkasunich> autogen
[04:14:43] <petev> so you have some program for it?
[04:14:59] <jmkasunich> in time, I'd like to autogen the top level vhdl too - the loop counts for the generate loops, etc
[04:15:07] <jmkasunich> not yet, starting small
[04:15:18] <petev> so where is the problem?
[04:15:33] <petev> you do the data by hand of autogen and get a .vhd
[04:15:37] <petev> then you build
[04:15:43] <petev> do you want something else?
[04:15:53] <petev> ^of^or
[04:16:50] <jmkasunich> if I can build 8+8+8, but I only need 4+8+2, I don't need to make a new toplevel and go thru the entire process
[04:17:04] <jmkasunich> I can use the 8+8+8 and change the rom to turn off the stuff I don't need
[04:17:08] <jmkasunich> much much faster
[04:17:27] <petev> why isn't that a driver issue then?
[04:17:39] <jmkasunich> and in principle doable by the driver, or by the config loader
[04:17:41] <petev> can't you use mod params for that?
[04:17:59] <jmkasunich> the actual number of options can be a lot more than three ints
[04:18:06] <petev> the bit file is the same except for the ram?
[04:18:14] <jmkasunich> yes
[04:18:20] <petev> why can't you have more than 3 ints?
[04:18:37] <jmkasunich> you can have whatever you want, but 40 insmod params gets a bit much
[04:18:57] <petev> use a bit for each one and an int for each type or something like that
[04:19:10] <jmkasunich> I'm thinking of letting the config loader do some of the work
[04:19:24] <jmkasunich> load the config, then ask the user what they want, and modify the ram accordingly
[04:19:34] <petev> so you want to just change the bit file and not have to re-build?
[04:19:39] <jmkasunich> then you load the driver, andit exports the right hal stuff
[04:19:40] <jmkasunich> right
[04:19:45] <petev> this sounds ugly for the end user though
[04:19:54] <petev> he doesn't want to mess with that
[04:19:58] <jmkasunich> why?
[04:20:12] <petev> I think mod params for the driver would be easier for the user
[04:20:19] <petev> he would have to patch the bitfile
[04:20:26] <jmkasunich> well....
[04:20:48] <jmkasunich> I've been pondering this for a while... be patient while I splain, then shoot it down ;-)
[04:21:04] <jmkasunich> the bitfile format is partly closed, but the header is known
[04:21:17] <jmkasunich> add another header, big enough to contain a tag, and ram contants
[04:21:59] <jmkasunich> makefile would do this after bitgen, initial contents would indicate the maximum possible amount of "stuff" in the fpga
[04:22:04] <jmkasunich> maybe its 8+8+8
[04:22:23] <petev> even with a utility, this seems a bit fragile
[04:22:37] <petev> how do you know which ram to patch?
[04:22:54] <jmkasunich> the loader would read the bitfile, stash the ram contents block, load the fpga, use dialogs or prompts or whatever to let the user config, then write a new bitfile with the new ram contants
[04:22:59] <petev> would you have to match a util for each bit file?
[04:23:14] <jmkasunich> no, it only needs to understand the ram data
[04:23:23] <jmkasunich> it would have to change if we added a new function
[04:23:30] <petev> hmm, and the extra header stays with the file always?
[04:23:47] <petev> the loader just ignores it on a load?
[04:23:49] <jmkasunich> if we start with pwm, step, and encoder, and later add serial adc, it would have to know about serial adc (as would the driver)
[04:24:21] <jmkasunich> a bitfile fresh out of the tools would contain a flag in the header saying "uncofigured"
[04:24:23] <petev> I think any new synth/place/route may break this whole thing
[04:24:31] <petev> then you have to make a new util
[04:24:37] <petev> how do you avoid that?
[04:24:47] <petev> you don't know which ram is used?
[04:25:01] <jmkasunich> new toolchain might change the makefile, but that is unavoidable
[04:25:13] <petev> the header should always keep track of the max config
[04:25:16] <jmkasunich> the config stuff cares only about that 256x32 ram contents
[04:25:27] <jmkasunich> thats fair - put 2 256x32 blocks in the header
[04:25:28] <petev> why would the same ram cell always be used?
[04:25:42] <petev> I don't see how you could count on that
[04:25:46] <jmkasunich> doesn't have to be
[04:25:58] <petev> then how does the util know which to patch?
[04:26:02] <jmkasunich> sorry, I'm expecting you to read my mind - fingers are too slow
[04:26:08] <jmkasunich> bitfile format is not reliable
[04:26:22] <jmkasunich> there is a xilinix util to patch, but the users won't have that
[04:26:27] <jmkasunich> so I don't patch the bitfile
[04:26:37] <jmkasunich> I load it, then I just write to the ram
[04:26:48] <jmkasunich> as ram, with ordinary bus cycles
[04:26:50] <petev> oh, that's different
[04:26:51] <jmkasunich> later the driver reads it
[04:27:00] <petev> so that happens before the driver loads?
[04:27:01] <jmkasunich> yeah, I didn't pass along that part, sorry
[04:27:08] <jmkasunich> yeah, at fpga load time
[04:27:19] <petev> ok, I that seems doable
[04:27:22] <jmkasunich> the loader loads the bitstream, then loads the ram from the header
[04:27:27] <jmkasunich> (trailer maybe?)
[04:27:51] <petev> so where is the problem then?
[04:27:58] <petev> aside from the loader tool
[04:28:02] <jmkasunich> uh... no problem I guess
[04:28:17] <petev> probably need a real driver for the loader tool
[04:28:22] <petev> the IOPL stuff is crap
[04:28:35] <jmkasunich> I was thinking that the initial ram contents would have the max config, so I'd want to merge that into the bitstream with the data2mem tool
[04:28:48] <jmkasunich> but I can have two blocks in the header, max and current
[04:28:53] <jmkasunich> so I don't need data2mem at all
[04:28:55] <petev> why not just put the max config in the header
[04:29:09] <petev> the loader reads it, loads the FPGA, and inits the ram
[04:29:13] <jmkasunich> right - you gave me that idea this evening
[04:29:38] <petev> I suppose the max config could be in the initial FPGA ram too
[04:29:45] <petev> then the loader could read it first
[04:29:55] <petev> but not a big diff
[04:30:19] <jmkasunich> that was the original plan, but that means two differnet max config = two differnet vhdls with the initlal content
[04:30:28] <petev> right
[04:30:47] <jmkasunich> I'd rather have a nice simple ram.vhd that makes an empty block (probably not completely empty, put a magic number in it)
[04:30:48] <petev> but you have to gen the header anyhow, you could gen the vhdl with config and arch too
[04:30:56] <SWPadnos> the max should be in a ROM, there can be a separate kernel module that loads an FPGA bitfile and optionally sets up wanted quantities in a RAM
[04:30:57] <petev> that should work
[04:31:26] <jmkasunich> SWPLinux: the thing that lets the user pic a less than max config should be in user space
[04:31:33] <SWPadnos> if it's actual PCI accessible RAM/ROM, then the driver can read (with memory cycles) the maxes, and write the "wanteds", with no bitfile dependencies
[04:31:44] <jmkasunich> and if both max and chosen are in the header, it can be any user program
[04:32:00] <jmkasunich> read max, talk to user, write new file with same max and customized current
[04:32:11] <jmkasunich> then run loader (setuid)
[04:32:13] <jmkasunich> then load driver
[04:32:14] <SWPadnos> ok - but if I have the choice of a kernel driver (that exposes a block device, for instance), and keeping up with some closed source tool, I'd probably choose the kernel driver
[04:32:20] <jmkasunich> subsequent runs you just run the loader
[04:32:51] <jmkasunich> no closed source - the "header" is added to the front of the bitstream by us
[04:33:05] <SWPadnos> with a block device driver (to RAM and ROM), you can cat, diff, use awk to make sure you're not asking for too many "things", etc.
[04:33:06] <jmkasunich> the bitstream itself is closed and we ignore it, except to load it into the fpga
[04:33:19] <SWPadnos> the bitstream file is not guaranteed to remain in the same format
[04:33:33] <jmkasunich> one thing at a time
[04:33:42] <SWPadnos> nor is it guaranteed to be the same format (or have the same fields) between chips or vendors ...
[04:33:52] <a-l-p-h-a_> a-l-p-h-a_ is now known as a-l-p-h-a
[04:33:55] <jmkasunich> the driver part - when you are asking the user what he wants, there is no need whatsoever to interact with hardware
[04:34:20] <jmkasunich> you have a 200K file, the first 2K is a "max" and "desired" config, in OUR format, the bitstream follows
[04:34:44] <jmkasunich> the tool reads max, talks to user, writes max+desired+bitstream to a new file
[04:34:44] <SWPadnos> ok
[04:35:20] <jmkasunich> the loader reads max and discards, reads desired and saves, reads bitstream and loads the part, then writes desired into the ram using ordinary write cycles, not bitstream mojo
[04:36:04] <SWPadnos> how many different functions do you think will be available? (10, 100 ..)
[04:36:12] <SWPadnos> functions like stepgen, pwm, counter ...
[04:36:22] <jmkasunich> 10, 20 tops
[04:36:41] <jmkasunich> depends on how you break it down
[04:36:49] <SWPadnos> ok - I'd do it as module load parameters. it would possibly get as ugly as blocks, but no worse
[04:36:57] <jmkasunich> is stepgen with quadrature output a function or an option on a function
[04:36:59] <jmkasunich> I think the latter
[04:37:13] <SWPadnos> in an FPGA, it's a function
[04:37:23] <SWPadnos> you either have the wquadrature generator or you don't
[04:37:28] <SWPadnos> -w
[04:37:42] <jmkasunich> stepgen.vhdl will have three or four parts
[04:37:44] <jmkasunich> entities
[04:37:56] <jmkasunich> stepgen - overall entitiy
[04:38:13] <jmkasunich> dds - makes 1 clock long pulses at programmed freqw
[04:38:45] <jmkasunich> pulsgen makes step pulse when it sees a dds pulse, enforces stepllen, dirhold, dirsetup (by asserting a hold to dds)
[04:38:55] <jmkasunich> quadgen makes quadrature when it sees a dds pulse
[04:39:06] <jmkasunich> then you mux one or the other to the pin
[04:39:29] <jmkasunich> the whole lump is a stepgen function
[04:39:41] <SWPadnos> ok - those conveniently have the same number of output pins :)
[04:39:56] <jmkasunich> since the dds and the pulsgen parts are big, and the quadgen is little, it goes along for the ride even if unised
[04:39:58] <SWPadnos> type 2-15 don't though (if you want any of those)
[04:40:03] <SWPadnos> ok
[04:40:08] <jmkasunich> I'm aimin for 0, 1, 2
[04:40:14] <SWPadnos> heh
[04:40:17] <jmkasunich> step/dir, up/dn, and quad
[04:40:32] <SWPadnos> ok (was thnking 2 was 4-phase, but I guess that's 3)
[04:40:51] <jmkasunich> the plan is to do config on a pin-by-pin basis, so functions with variable numbers of outputs are less than pretty
[04:41:00] <SWPadnos> yes
[04:41:23] <jmkasunich> if you wanted a max of 5 outputs, you could dedicate 5 pins to that function, and any not used for a particular stepping type would be general I/O
[04:41:45] <SWPadnos> ok, so you have a number in a register (part of a RAM block) that turns on the DDS and selects one of the possible connections to the two i/o pins
[04:41:55] <SWPadnos> for each stepgen
[04:41:57] <jmkasunich> that would limit the max number of stepgens to pins/5 instead of pins/2
[04:42:06] <jmkasunich> close
[04:42:06] <SWPadnos> right
[04:42:09] <jmkasunich> the config data is per pin
[04:42:16] <SWPadnos> no problem with the >2-pin step types being gone
[04:42:29] <jmkasunich> so for a pin, you select gp in, gpout, or stepgen out
[04:42:45] <SWPadnos> is there a crossbar switch, or an N:1 mux for each pin?
[04:42:48] <jmkasunich> also per pin, you select open collector, etc
[04:42:50] <jmkasunich> N:1
[04:43:01] <jmkasunich> initially 2:1 (gp or special function)
[04:43:02] <SWPadnos> ok, with N dependent on what functions are in the config
[04:43:27] <jmkasunich> maybe later 4:1, the 5i22 might be able to have an encoder, a pwmgen, and a stepgen for every pair of pins
[04:43:59] <SWPadnos> consider that it may be easier to have the quad, up/dn/and step/dir blocks always on, and use a 4:1 mux instead (3 step types + general putpose)
[04:44:00] <jmkasunich> the 5i22 gets pretty full with 8 enc, 8 step, and 8 pwm
[04:44:24] <jmkasunich> maybe
[04:44:33] <SWPadnos> easier both in the VHDL and in configuration
[04:44:42] <jmkasunich> but I was thinking step-type would be a stepgen characteristic, not a pin characteristic
[04:45:01] <SWPadnos> and you can also assign those pins in pairs, since (for these stepgens), you either use both or neither pins
[04:45:23] <jmkasunich> yeah, but the pin assignment will be generalized
[04:45:31] <SWPadnos> I think it makes sense to connect the pins to one of the step types or to generic I/O
[04:45:48] <SWPadnos> err - generalized in what way?
[04:46:37] <jmkasunich> every pin is individually controllable for general/sp0/sp1/..../spN, and open-collector or regular or hi-Z (input)
[04:47:11] <jmkasunich> for pin 1, sp0 could be step and sp1 be up and sp2 be phaseA
[04:47:19] <SWPadnos> ok - that's just more connections for the mux in my view
[04:47:31] <jmkasunich> for pin2, sp0 would be dir, sp1 = down, sp2 = phaseB
[04:47:31] <SWPadnos> right - but stepgen 1 will always connect to pins 1 and 2
[04:47:40] <jmkasunich> right
[04:47:42] <SWPadnos> stepgen 2 to 3 and 4 (or whatever)
[04:47:54] <jmkasunich> and stuff in the RAM would tell the config tool what could be connected to pins 1 and 2
[04:48:02] <jmkasunich> stuff in the max ram
[04:48:08] <SWPadnos> sure
[04:48:19] <jmkasunich> stuff in the final ram would tell the driver what _is_ connected to 1 and 2
[04:48:33] <jmkasunich> and if both are I/O, the driver doesn't export stepgen stuff
[04:48:40] <jmkasunich> gpio
[04:48:45] <SWPadnos> right
[04:48:53] <SWPadnos> ok - 3 or 4 steps there :)
[04:49:06] <SWPadnos> 1) bitfile to actually make functions exist in the FPGA
[04:49:20] <SWPadnos> 2) ROM to tell (something) what can be done with the chip
[04:49:28] <SWPadnos> 3) RAM to tell the chip how to connect functions
[04:49:51] <SWPadnos> 4) HAL driver to look at the config (possibly setting it in (3)), and eport HAL pins for those funcs
[04:50:01] <jmkasunich> close
[04:50:12] <SWPadnos> 1a) load bitfile
[04:50:13] <jmkasunich> the rom/ram would only be accessed by the driver
[04:50:23] <jmkasunich> it wouldn't directly set anything in the fpga
[04:50:38] <jmkasunich> the driver would write to regs to set the 4:1 mux, etc
[04:51:02] <jmkasunich> (it is very hairy or impossible to get a specific RAM bit as a signal in the fpga)
[04:51:41] <jmkasunich> basiclly the driver tweaks the fpga (within the limits of the basic config)
[04:51:48] <jmkasunich> the ram replaces insmod params
[04:52:01] <jmkasunich> with a hopefully friendly user space tweaking tool
[04:52:32] <jmkasunich> dammit - talked away another evening...
[04:52:42] <jmkasunich> although the packages thing may be worth it
[04:52:44] <SWPadnos> ok - that's the thing. there would not need to be more than N params, where N is the number of types of block
[04:52:52] <jmkasunich> the less crap in the top level vhd file the happier I'll be
[04:53:02] <SWPadnos> (or N+M, where M is small, like board number)
[04:53:07] <jmkasunich> no, there are at least N, where N is the number of pins
[04:53:08] <SWPadnos> heh - true enough
[04:53:21] <SWPadnos> no - I'm looking at it from a user viewpoint, not the FPGA
[04:53:28] <jmkasunich> each pin can have one of several output sources, or be an input
[04:53:34] <SWPadnos> the driver is the translator from FPGA to user, it can do that in both directions
[04:53:36] <jmkasunich> if an output, it can be open collector, or totem pole
[04:53:40] <jmkasunich> it adds up fast
[04:54:00] <SWPadnos> sure
[04:54:33] <SWPadnos> but you have different params for those things, and you can also have sane defaults
[04:54:40] <jmkasunich> I'm gonna have to learn some python
[04:54:55] <jmkasunich> I'm thinking 72 lines (probably 3 tabs with 24 each)
[04:55:26] <jmkasunich> each line has a checkbox for open collector, a checkbox for input, and a pulldown that lists gpout, sp1, sp2, sp3, etc
[04:55:37] <jmkasunich> where sp1-3 are filled in based on what the max array says
[04:55:45] <jmkasunich> might be "stepgen.0.step"
[04:55:54] <SWPadnos> well, go for it. if I really hate what you do, I'll change it so you hate it instead ;)
[04:55:55] <jmkasunich> might be "encoder.3.phaseA"
[04:56:25] <jmkasunich> I think that would be pretty user friendly
[04:56:27] <SWPadnos> you have some interdependent things there - an output can't be hi-z, and an input can't be totem pole
[04:56:45] <jmkasunich> yes and no
[04:56:57] <SWPadnos> yep - dropdown for function, checkboxes or another drpdown for the drive type
[04:57:03] <jmkasunich> you can always check input, and the driver will export a hal -in pin
[04:57:17] <jmkasunich> even if the output is carrying steps, you can sample it in hal if you want
[04:57:43] <SWPadnos> that's two functions
[04:57:51] <jmkasunich> ?
[04:58:22] <jmkasunich> there will always be three (for the 5i20) 24 bit GPIO ports regardless of anything else
[04:58:34] <SWPadnos> you need two muxes and a buffer, unless the input flag is only for the driver (and the signals are always readable by the driver, but just not exported unless requested)
[04:58:38] <jmkasunich> and the driver will always be able to read the state of all 24 pins
[04:58:47] <SWPadnos> ok
[04:59:01] <jmkasunich> it would take more fpga logic to not read them
[04:59:26] <jmkasunich> so the checkbox just controls export of the -in and -in-not HAL pins
[04:59:39] <jmkasunich> the input checkbox that is
[04:59:40] <SWPadnos> ok - I get it now
[05:00:00] <jmkasunich> if the special functions are also inputs, then the OC checkbox is meaningless
[05:00:30] <jmkasunich> correction:
[05:00:32] <SWPadnos> that's the issue I was pointing out - the program needs to know what it means to connect a pin to a stepgen vs. a quad counter
[05:00:42] <jtr> so if you write a one to an output shorted to ground, when you read back, you see the zero?
[05:00:54] <SWPadnos> depende on the short and the output driver ... :)
[05:00:54] <jmkasunich> yes
[05:01:06] <jmkasunich> if its open collector, you see the zero and are happy
[05:01:07] <SWPadnos> and where the input is
[05:01:17] <jmkasunich> if its not, you see a fight between the driver and the short
[05:01:22] <jmkasunich> maybe you see a zero
[05:01:25] <jmkasunich> maybe you see smoke
[05:02:10] <jmkasunich> maybe the pulldown should only list special functions, plus NONE
[05:02:27] <jtr> yep. we had some metrabyte IO boards that let us do that (write then verify)
[05:02:32] <jmkasunich> if the selected item is a special function input, or NONE, the gpoutput checkbox is ungreyed
[05:02:44] <jmkasunich> if the selected item is a special output, the gpout box is grayed
[05:03:08] <jmkasunich> the idea is that if you config a special input (like an encoder), you can do a loopback test by enabling the gp output
[05:03:20] <jmkasunich> cant test at 1MHz, but....
[05:03:54] <jmkasunich> haven't completely worked out the details yet as you can tell
[05:03:57] <SWPadnos> I'd have GP Output in the dropdown, instead of a separate checkbox
[05:04:28] <jmkasunich> if all the other entries in the dropdown are special outputs, that works
[05:04:36] <jmkasunich> what if one is an input?
[05:04:40] <jmkasunich> line an encoder?
[05:04:42] <jtr> well, that would let you test before the machine is wired - afterwards, you would need to disconnect the encoder.
[05:04:44] <SWPadnos> the problem is knowing what special functions are inputs and which are outputs, so you can allow the appropriate pin driver types
[05:05:00] <jmkasunich> that would be "known" to the tool
[05:05:12] <jtr> (regarding loopback test)
[05:05:25] <jmkasunich> just like it would know that the first pin of a stepgen has the options of "step", "up" and "phaseA"
[05:05:36] <jmkasunich> while the 2nd has "dir", "down", and "phaseB"
[05:05:46] <SWPadnos> well, if you allow for a single pin to eventually have stepgen, pwm, and encoder counter on it, or GP in or GP out, then you need to have some way of telling this user utility what functions can be used with which output (/input) types
[05:05:54] <jmkasunich> right
[05:06:06] <jmkasunich> several bitfields for each pin
[05:06:20] <SWPadnos> ok - it's a synchronization problem between the VHDL and the C/Python/C++/perl/whatever program
[05:06:27] <jmkasunich> right
[05:06:33] <jmkasunich> which will always be the case
[05:06:45] <jtr> the python could get that from the max config header, right?
[05:06:47] <SWPadnos> I don't llike synchronization problems ;)
[05:06:59] <jmkasunich> when a new special function is added, the driver code needs to be written to understand it, and the config tweaker needs to be written to understnad it
[05:07:08] <SWPadnos> yep
[05:07:14] <jmkasunich> well, the driver part is unavoidable
[05:07:48] <jmkasunich> hey - since the max config doesn't have to fit _IN_ the rom, its only going to be in the file header, I don't have a size constraint
[05:08:03] <SWPadnos> the output type and even mux settings are in theory changeable on the fly, right?
[05:08:16] <SWPadnos> pin muxes that is
[05:08:20] <jmkasunich> the max part of the rom could have several bits (in/out, etc) plus a string, for every possible function of every pin
[05:08:29] <jmkasunich> changable by the driver yes
[05:08:32] <jmkasunich> but it won't do that
[05:08:39] <jmkasunich> it will set them and export matching HAL pins
[05:09:10] <jmkasunich> I could export a thousand HAL params and let the user do everything with setp
[05:09:18] <SWPadnos> I'd like to explore the possibility of using module parameters further, but I can't do it tonight
[05:09:20] <jmkasunich> but I don't want to go there I don't think
[05:09:24] <SWPadnos> no way
[05:09:27] <SWPadnos> I'm with you on that one
[05:09:44] <jmkasunich> the way I see it, there are at least 72 pieces of config info
[05:09:51] <jmkasunich> passing that as module params is unreasonable
[05:10:21] <SWPadnos> well, what are the chances that someone wants to make one stepgen use totem pole and another use open collector?
[05:10:29] <jmkasunich> each piece is several bits - say a 1:4 mux (2 bits), plus "export -in", plus open-collector,
[05:10:47] <jmkasunich> I'm not gonna constrict them
[05:11:02] <jmkasunich> maybe one is driving a gecko and one is driving a xylotex
[05:11:03] <SWPadnos> it makes no difference how much info the FPGA needs to make a config happen, it matters how much information is needed to tell (some piece of code) what the user wants
[05:11:08] <SWPadnos> ok
[05:11:32] <jmkasunich> I don't see you reducing my list above (several bits) down to 1 or two bits per pin
[05:11:51] <jmkasunich> and the more you try to shrink it, the more insane it will make the user
[05:12:10] <SWPadnos> even with that, you can still say "stepgen=0,10,20" to get 1 type 0 with output type 1, another type 0 with output type 2, and another type 0 stepgen with output type 3
[05:12:34] <jmkasunich> always starting at pin 1 I assume
[05:12:43] <SWPadnos> wherever the stepgens are mapped
[05:13:13] <SWPadnos> let's use "stepgen=1,0,11,21,0,0,31" then, so you can skip some
[05:13:25] <SWPadnos> 0=off, 1=type 1, etc.
[05:13:29] <jmkasunich> what are the two digit codes?
[05:13:39] <SWPadnos> if there are 10 functions, then you only have 10 insmod parameters
[05:13:50] <jmkasunich> each of which is a string
[05:13:55] <SWPadnos> digit 1=I/O type, digit 2=stepper type
[05:13:54] <jmkasunich> or array
[05:14:00] <SWPadnos> sure
[05:14:09] <jmkasunich> what about open collector?
[05:14:19] <jmkasunich> what about -in and -in-not?
[05:14:23] <SWPadnos> it's not all that confusing, and it eliminates a complete toolset and configuration step
[05:14:55] <SWPadnos> I'd specify inputs in nibble groups, not per bit
[05:15:13] <jmkasunich> I dunno
[05:15:28] <SWPadnos> even if you don't, there's no need for a pin-1-in if you just export a stepgen.0.step pin that the user can read
[05:15:36] <jmkasunich> what I do know is that we've talked away another perfectly good evengin
[05:15:43] <SWPadnos> you can't write it since it's controlled by hardware
[05:15:48] <jmkasunich> and I still haven't done any real work
[05:15:57] <SWPadnos> heh - but you learned something useful :)
[05:16:37] <jmkasunich> yeah, now I have to rewrite peter's vhdl to use packages, and rewrite the makefile to use the "use" statements for dependency generation
[05:16:42] <jmkasunich> wonderfull...
[05:16:51] <jtr> this was real work, even if it didn't seem like progress
[05:16:52] <jmkasunich> so I've made negative progress
[05:17:20] <SWPadnos> yeah - so many people consider specifications as a hindrance instead of part of the work
[05:17:27] <SWPadnos> arguably the most important part
[05:17:50] <jmkasunich> this is the discussion I wanted to have when you were in FLA
[05:17:55] <jtr> yep
[05:17:57] <SWPadnos> sorry
[05:18:04] <jmkasunich> and the one I wanted to have yesterday, instead of the wild tangent that we went off on
[05:18:08] <SWPadnos> had to go - the wife would have been peeved if I had remained in VT for IRC ;)
[05:18:25] <jmkasunich> I didn't expect you to stay home to talk to me
[05:18:41] <SWPadnos> heh
[05:18:42] <jmkasunich> its just that the last two days I've had some specific vhdl work that I wanted to do
[05:19:12] <jmkasunich> tomorrow evening I have other obligations, so it will be thursday at least before I do monday's VHDL work
[05:19:35] <jmkasunich> if I can even remember what I wanted to do by then
[05:20:13] <jmkasunich> now I need to try to figure out the specifics of this package stuff
[05:20:42] <jmkasunich> but first some shlock
[05:21:03] <SWPadnos> well, I'll try to figure out if there's a relatively reasonable way to do params instead of a separate config tool
[05:21:37] <jmkasunich> I can't imagine assembling insmod parameters as being easier for a user than clicking on a menu
[05:22:20] <SWPadnos> well, what happens when a new bitfile is created? (due to a bugfix, for example, not due to a function change)
[05:22:35] <SWPadnos> you now havea file with no "we want this" header, so the user has to re-select all that stuff
[05:22:55] <SWPadnos> instead of some parameters in the ini/hal files that don't change at all
[05:23:19] <jmkasunich> hmm
[05:23:28] <jmkasunich> thats valid
[05:23:33] <jtr> use the config tool to write an ini file?
[05:23:38] <SWPadnos> a graphical tool to select functions can also write a hairy awful insmod line into a hal file
[05:23:37] <petev> not a problem
[05:23:55] <petev> you can make a util like for DFU that removes/adds headers
[05:24:03] <petev> it can take the header from the old file
[05:24:21] <SWPadnos> it's still an extra step - the config should be separate from the bitfile (IMO)
[05:24:33] <petev> that would be ideal
[05:24:40] <SWPadnos> right now, there are no inis in the module dir, and no driver information in there either
[05:24:44] <petev> but there is so much config scattered everywhere already
[05:24:53] <SWPadnos> and no drivers in the users config dir
[05:25:00] <jmkasunich> at some point, you might say "don't store the config in a header on the bitfile, just store it separately"
[05:25:03] <SWPadnos> scattered among many files in one dir
[05:25:19] <petev> yes, another cofig file, argh
[05:25:21] <SWPadnos> sure, that could be done, but this is a per-config thing, not per-bitfile ...
[05:25:40] <petev> it has to match the bit file a little
[05:25:53] <jmkasunich> config with bitfile is convenient 99% of the time, but an issue if the bitfile changes and the config doesn't
[05:26:08] <SWPadnos> it has to be valid, but then again so do all the lines in the hal files (if you try to connect to stepgen.5 and there are only 4, you get an error)
[05:26:23] <SWPadnos> or if you want multiple configs that use the same hardware and different hardware configs
[05:26:39] <SWPadnos> like a lathe and a mill or something (shoptask, anyone?)
[05:27:12] <jmkasunich> bitfiles with configs in them would not be named the same as the original bitfile
[05:27:48] <jmkasunich> I'd have lathe.bit and mill.bit, both made from m5i10-8+8+8.bit (or whatever, I know + is not good for filenames)
[05:28:19] <SWPadnos> well, think on where they should go, and how they should be dealt with for multiple configs (user config dirs), updates that don't change functions, and updates that do change functions (even though the user may not want to change what they have)
[05:29:30] <jmkasunich> the only thing I intend to think about for the next couple hours (when you guys hopefully go to sleep and stop talking to me) is vhdl packages
[05:29:37] <SWPadnos> it is certainly possible to have a config / ini file that isn't part of the bitfile - if there's a userspace app to load the config (bitfile), it can also configure it with a different parameter/file specified on the command line
[05:29:39] <SWPadnos> heh
[05:29:44] <SWPadnos> night :)
[05:29:58] <SWPadnos> damn. 12:30 again
[05:30:06] <jmkasunich> tell me about it
[05:30:10] <SWPadnos> good night, for real. good luck - sorry to keep you from your appointed rounds ...
[05:31:51] <jmkasunich> is vhdl case sensitive?
[05:31:59] <jmkasunich> Port ( clk : in std_logic;
[05:32:03] <jmkasunich> port (
[05:32:03] <jmkasunich> clk : in std_logic;
[05:32:20] <jmkasunich> one is from the component definition, one is from the entity definition
[05:32:25] <jmkasunich> peter does that a lot
[05:32:35] <petev> no it's not
[05:32:48] <jmkasunich> I see
[05:32:49] <petev> I think some compilers have flags to change the default behavior of that
[05:33:00] <jmkasunich> my editor hightlights port, but not Port
[05:33:04] <petev> it's just sloppy for it to not match though
[05:33:28] <jmkasunich> yeah
[05:33:31] <jmkasunich> I'm gonna fix them
[05:33:44] <petev> watch the diffs ;-)
[05:33:48] <jmkasunich> (I'm such a hyprocrite)
[05:34:01] <jmkasunich> in my defense, they're not in cvs yet
[05:34:24] <jmkasunich> and if I add packages, peter won't want them back anyway
[05:41:37] <jmkasunich> petev: you still here?
[05:42:08] <jmkasunich> this package stuff isn't working as we thought
[05:42:24] <jmkasunich> and that online reference also doesn't match what we talked about
[05:42:28] <petev> what's happening?
[05:42:33] <petev> could be more xilinx foo
[05:42:45] <jmkasunich> I'm pastebinning something....
[05:42:51] <petev> ok
[05:44:25] <jmkasunich> http://www.pastebin.ca/384616
[05:44:42] <jmkasunich> dammit, should have pasted the error too
[05:44:55] <jmkasunich> Compiling vhdl file "/home/jmkasunich/emcdev/emc2head/src/hal/drivers/mesa_5i2x/5i20_vhdl/../5i2x_vhdl/boutreg.vhd" in Library work.
[05:44:55] <jmkasunich> ERROR:HDLParsers:3312 - "/home/jmkasunich/emcdev/emc2head/src/hal/drivers/mesa_5i2x/5i20_vhdl/../5i2x_vhdl/boutreg.vhd" Line 17. Undefined symbol 'BusWidth'.
[05:45:30] <jmkasunich> duh, Buswidth idn't defined at that point
[05:45:43] <petev> try without library work
[05:45:54] <petev> work is an automatic kind of thing
[05:46:06] <jmkasunich> ok, but thats not the error
[05:46:16] <petev> yeah, I see
[05:46:18] <jmkasunich> it barfed while processing boutreg.vhd, never even started top
[05:46:57] <jmkasunich> buswidth is defined in top
[05:47:10] <jmkasunich> in the arch section of the main entity
[05:47:11] <petev> pass it as a general param
[05:47:26] <jmkasunich> from top?
[05:47:30] <petev> yes
[05:47:37] <petev> in the instantiation
[05:47:45] <petev> add it to the general map
[05:48:09] <jmkasunich> you mean as a generic?
[05:48:12] <petev> I meant generic
[05:48:14] <petev> yes
[05:49:02] <jmkasunich> trying now
[05:49:07] <jmkasunich> bet its still gonna barf
[05:49:09] <petev> ok
[05:49:35] <petev> always good to pass args by name in instantiation instead of order too
[05:49:38] <jmkasunich> it barfed differetnly
[05:49:56] <jmkasunich> still before getting to top, so its not the passing
[05:50:20] <jmkasunich> Compiling vhdl file "/home/jmkasunich/emcdev/emc2head/src/hal/drivers/mesa_5i2x/5i20_vhdl/../5i2x_vhdl/boutreg.vhd" in Library work.
[05:50:20] <jmkasunich> Package <boutreg> compiled.
[05:50:20] <jmkasunich> WARNING:HDLParsers:3353 - "/home/jmkasunich/emcdev/emc2head/src/hal/drivers/mesa_5i2x/5i20_vhdl/../5i2x_vhdl/boutreg.vhd" Line 26. Primary unit boutreg is being redefined within the file. Prior definition (on line 12) is discarded. (LRM 11.1)
[05:50:59] <petev> maybe it doesn't like the package and component name the same
[05:51:01] <jmkasunich> does the package name need to be something other than the comp name?
[05:51:03] <jmkasunich> ;-)
[05:51:16] <petev> my VHDL is a bit rusty so I don't remember all the details
[05:51:25] <jmkasunich> testing
[05:51:52] <jmkasunich> got farther, then barfed
[05:51:54] <jmkasunich> Compiling vhdl file "/home/jmkasunich/emcdev/emc2head/src/hal/drivers/mesa_5i2x/5i20_vhdl/../5i2x_vhdl/boutreg.vhd" in Library work.
[05:51:54] <jmkasunich> Package <boutreg> compiled.
[05:51:54] <jmkasunich> ERROR:HDLParsers:3312 - "/home/jmkasunich/emcdev/emc2head/src/hal/drivers/mesa_5i2x/5i20_vhdl/../5i2x_vhdl/boutreg.vhd" Line 28. Undefined symbol 'std_logic'.
[05:52:05] <petev> thats from ieee
[05:52:13] <petev> do you have a use for it?
[05:52:17] <jmkasunich> damn line numbers are off by 2 because I put that header in the pastebin
[05:52:45] <jmkasunich> std_logic? everything uses it
[05:53:16] <petev> library ieee;
[05:53:16] <petev> use ieee.std_logic_1164.all;
[05:53:16] <petev> library ieee;
[05:53:16] <petev> use ieee.std_logic_1164.all;
[05:53:16] <petev> library ieee;
[05:53:29] <petev> use ieee.std_logic_1164.all;
[05:53:37] <petev> that was wierd
[05:53:53] <petev> u only need it once ;-)
[05:53:55] <jmkasunich> its accepting the component, and crashing on the entity/port line
[05:53:57] <jmkasunich> 30 in the pastebin
[05:54:09] <jmkasunich> thats already in there
[05:54:13] <jmkasunich> line 3 of the pastebin
[05:54:25] <petev> I can't see the line numbers
[05:54:32] <petev> theres some stuff covering them
[05:54:32] <jmkasunich> http://www.pastebin.ca/384616
[05:54:45] <jmkasunich> browser funnies?
[05:54:53] <petev> maybe
[05:54:58] <petev> I can estimate
[05:55:16] <petev> on the port line?
[05:55:25] <jmkasunich> thats where its dieing
[05:55:40] <petev> looks ok
[05:55:41] <jmkasunich> the library IEEE and use 1164 is at the top of the file already
[05:55:53] <petev> yes
[05:57:03] <petev> did u change the package name?
[05:57:11] <jmkasunich> yeah, its fooreg now
[05:57:23] <petev> I don't see anything wrong off hand
[05:57:25] <jmkasunich> wait, I think I made an editing mistake
[05:57:57] <jmkasunich> dumbass - I changed the entity name
[05:57:59] <jmkasunich> trying again
[05:58:08] <jmkasunich> and the dog is whining he need to go out
[05:58:27] <jmkasunich> same errors
[05:58:32] <jmkasunich> back soon
[05:58:36] <petev> ok
[06:02:05] <jmkasunich> still undefined std_logic on line 28
[06:02:12] <jmkasunich> which is the port line of the entity
[06:02:20] <jmkasunich> its happy with the package it seems
[06:02:34] <petev> try and comment the package for yuks
[06:02:40] <jmkasunich> yeah, was about to do that
[06:03:59] <jmkasunich> with the entire package commented out, it compiles boutreg.vhd fine
[06:04:11] <jmkasunich> dies later in top, but thats expected
[06:04:20] <petev> just the package begin/end or the component too?
[06:04:28] <jmkasunich> everything
[06:04:56] <petev> that's broken
[06:04:56] <jmkasunich> uncommented component, trying
[06:05:05] <petev> it should work the way you had it
[06:05:18] <jmkasunich> parse error, unexpected COMPONENT
[06:05:34] <petev> how do I paste bin?
[06:05:42] <petev> I have an example from an old ASIC
[06:05:49] <petev> it's exactly what you had
[06:05:55] <jmkasunich> www.pastebin.ca
[06:06:04] <petev> probably explains why peter didn't use packages
[06:06:08] <petev> the stupid tools
[06:06:50] <jmkasunich> http://eng.auburn.edu/department/ee/mgc/vhdl.html#architecture
[06:06:53] <petev> http://www.pastebin.ca/384642
[06:07:01] <jmkasunich> what exactly is the difference between package and package body?
[06:07:16] <petev> what do you mean?
[06:07:57] <jmkasunich> at that webpage, they have both package daclaration and package body
[06:08:28] <petev> I have never used package body
[06:09:00] <jmkasunich> ok
[06:09:02] <petev> maybe thats for funcs and the like
[06:09:09] <jmkasunich> noticed something in your pastebin
[06:09:16] <petev> instead of entity/arch stuff
[06:09:19] <jmkasunich> you import the IEE lib twice
[06:09:20] <petev> yes?
[06:09:25] <jmkasunich> once before the package, once after
[06:09:27] <jmkasunich> trying that now
[06:09:36] <jmkasunich> ha, boutreg compiled now
[06:09:55] <petev> yeah, it only effects what's after it
[06:09:56] <petev> I didn't catch that
[06:10:05] <jmkasunich> I was doing it at the very beginning
[06:10:15] <jmkasunich> but it must forget somehow, after doing the package part
[06:10:24] <jmkasunich> so you gotta do it again for the entity
[06:10:30] <petev> yes
[06:10:45] <petev> it may need something different than the package
[06:10:52] <jmkasunich> do you mean "it only affects the single thing thats after it"
[06:11:12] <petev> say the package only needs std_logic
[06:11:16] <jmkasunich> I thought it would be like a .h, whatever it defines is defined for the rest fo the file
[06:11:27] <petev> but maybe the architecture instantiates other stuff
[06:11:44] <petev> so you don't need to pull all the stuff for the package
[06:11:46] <jmkasunich> you can't just put it all at the top?
[06:11:50] <petev> no
[06:12:09] <jmkasunich> so what defines the scope of something that is pulled in by a "use"?
[06:12:43] <petev> have to look up the exact rules
[06:12:58] <petev> I think for each package
[06:12:59] <jmkasunich> but its obviously not "from the use line to the end of the file"
[06:13:02] <petev> and for each entity
[06:13:22] <jmkasunich> argh... thats annoying
[06:13:49] <jmkasunich> so files with 10 entities get to have 10 sets of use lines.... oh joy
[06:14:21] <petev> I just found some of my old code with package body
[06:14:33] <petev> man I didn't even remember it
[06:14:45] <petev> its for functions
[06:16:03] <petev> yes, looking at my old code you need th use statement for each package and each entity
[06:16:33] <jmkasunich> getting farther each time...
[06:17:46] <jmkasunich> seems to be working - passed the parameter into it, and shazam
[06:17:55] <petev> nice
[06:18:00] <jmkasunich> got thru synthesis, doing ngdbuild
[06:18:21] <petev> I didn't want to say it before, but VHDL is often compared to C++ and verilog to C
[06:18:25] <jmkasunich> I have a very small toplevel (1 stepgen, 1 enc, 1 pwm) so it places and routes in about 5 mins
[06:18:45] <jmkasunich> ok, I'm changing to verilog right now dammit
[06:19:05] <petev> when you get a chance read the ieee library
[06:19:22] <petev> you'll see a lot of cool stuff
[06:19:28] <jmkasunich> when I get a chance... that'll be about 2008
[06:19:37] <petev> the whole std_logic type and operators and resolution functions
[06:19:47] <jmkasunich> ok, next issue is just a nuisance - I can't name the package and the entity in it the same
[06:19:52] <petev> all built on top of bare VHDL
[06:20:09] <petev> yeah, I was afraid of that
[06:20:14] <petev> just put Pkg on the end
[06:20:17] <petev> or _pkg
[06:20:48] <jmkasunich> oh - when you are putting all your comps in one package, do you do that by putting them all in one file?
[06:21:02] <jmkasunich> or can you have "package foo is " in multiple files?
[06:21:08] <jmkasunich> and each one adds to the package?
[06:21:19] <petev> the entity/arch can actually be in other files
[06:21:27] <petev> but all the package stuff is together
[06:21:37] <petev> at least that's what I always do
[06:21:44] <jmkasunich> ok, so you have one file with
[06:21:46] <jmkasunich> package foo is
[06:21:48] <jmkasunich> bar
[06:21:51] <jmkasunich> blat
[06:21:54] <jmkasunich> bax
[06:21:56] <jmkasunich> end foo
[06:22:02] <petev> yes, that's what I do
[06:22:04] <jmkasunich> then the entities and archs are in multiple files
[06:22:20] <petev> yes, or the same if there aren't many of them
[06:22:27] <jmkasunich> ok
[06:22:38] <jmkasunich> I only want related things in one package...
[06:22:57] <petev> yes, that's good practice
[06:23:03] <jmkasunich> I need to try two comps in the package and two entites in the file, make sure it works
[06:23:24] <petev> it's supposed to
[06:23:32] <petev> if the tools aren't broken
[06:25:21] <jmkasunich> it forgets the libraries between entities, but if I add more use lines, it seems to work
[06:25:37] <petev> right, for each entity and package
[06:25:50] <jmkasunich> annoying, bit I can live with it
[06:26:08] <jmkasunich> so now I can discard my --- include directives
[06:26:15] <petev> yes
[06:26:15] <jmkasunich> and build my dependency list based on use lines
[06:26:46] <jmkasunich> gotta reject the IEEE use lines though
[06:27:05] <petev> shouldn't hurt anything
[06:27:09] <petev> they won't change
[06:27:16] <petev> but the path may be tricky
[06:27:25] <jmkasunich> they'll become dependencies and unless make knows where to find them it will get bent
[06:27:41] <petev> VPATH
[06:27:50] <jmkasunich> * jmkasunich is lazy
[06:28:09] <jmkasunich> I need to turn use <something> into <something.vhd> anyway
[06:28:20] <jmkasunich> so maybe something should be something_vhd
[06:28:23] <petev> yes, that's true
[06:28:28] <jmkasunich> and I can key on the _vhd to discard IEEE
[06:28:48] <petev> or just look for ieee ;-)
[06:29:10] <jmkasunich> the next problem is that my vhd files aren't all in the same dir
[06:29:24] <petev> why not just VPATH in the makefile?
[06:29:30] <petev> that's pretty easy
[06:29:46] <jmkasunich> what is VPATH?
[06:29:58] <petev> tells make what dirs to look in
[06:30:27] <jmkasunich> thats a make thing?
[06:30:31] <petev> yes
[06:30:33] <jmkasunich> * jmkasunich opens the make manual
[06:30:51] <jmkasunich> finding the path to the xilinx libs is less easy,
[06:30:59] <petev> true
[06:31:17] <jmkasunich> and I still have to append .vhd, so I'll filter using _vhd, and use VPATH to deal with my files being in differnt places
[06:31:35] <petev> that would work
[06:31:41] <jmkasunich> I need to append something anyway, so the names don't conflict
[06:32:09] <petev> gnu make has all those built in sub functions so it shouldn't be too bad
[06:32:54] <jmkasunich> its even easier than using make - the building of the dependency and project files is a rule, so I have grep, sed, the full arsenal at my disposal
[06:33:44] <jmkasunich> heh the filter is even easier
[06:34:09] <jmkasunich> I'm grepping for "use work.[stuff]_vhd"
[06:34:31] <jmkasunich> the work separates it from IEEE
[06:34:33] <petev> probably don't even need the _vhd
[06:34:39] <petev> as anything in work is your stuff
[06:34:44] <jmkasunich> right, still need to avoid name conflict tho
[06:35:00] <petev> name conflict how?
[06:35:10] <jmkasunich> package name and entity name
[06:35:21] <petev> oh, if in separate files?
[06:35:29] <petev> I would use _pkg for that then
[06:35:50] <jmkasunich> file boutreg.vhd defines entity boutreg, can't use boutreg alone as the package name
[06:36:04] <jmkasunich> the entity and the package collide
[06:36:10] <petev> right use bootreg_pkg if they are in separate files
[06:36:20] <jmkasunich> yeah, that works
[06:36:27] <jmkasunich> better than boutreg_vhd
[06:36:47] <petev> especailly when you put the .vhd on the end ;-)
[06:40:48] <petev> jmkasunich, do you have a good VHDL book?
[06:40:52] <jmkasunich> no
[06:40:56] <jmkasunich> just online references
[06:40:57] <petev> do u want one?
[06:41:14] <jmkasunich> haven't been able to find one in a bookstore, and didn't want to spend the bucks sight unseen
[06:41:21] <petev> I have duplicates
[06:41:28] <petev> send me your address
[06:42:11] <jmkasunich> on the way
[06:42:31] <jmkasunich> let me know what its worth + shipping
[06:42:48] <petev> no trouble, I'll send it media mail
[06:44:03] <jmkasunich> btw, are you getting list mails now?
[06:44:19] <petev> yes, the dev one seemed to be delayed a day
[06:44:23] <petev> but I got it
[06:44:24] <jmkasunich> ok
[06:54:53] <a-l-p-h-a> boo!
[06:55:11] <a-l-p-h-a> what's the word on mesa? :) I haven't asked in 3 weeks.
[06:55:21] <jmkasunich> working on it as we speak
[06:55:56] <a-l-p-h-a> * a-l-p-h-a would give jmkasunich a man hug right now. But is affraid of the backlash associated with said action.
[06:56:04] <jmkasunich> good
[06:56:08] <jmkasunich> be afraid
[06:56:11] <jmkasunich> be very afraid
[06:56:44] <a-l-p-h-a> hmm... afraid is one f. not two.
[07:40:50] <jmkasunich> petev: I'm finding all kinds of fun messiness
[07:41:03] <petev> you getting anywhere?
[07:41:12] <jmkasunich> one of peters entities has a component def like this:
[07:41:18] <jmkasunich> ibus : in std_logic_vector(BusWidth -1 downto 0);
[07:41:26] <jmkasunich> and an entity def like this:
[07:41:34] <jmkasunich> Port ( ibus : in std_logic_vector(31 downto 0);
[07:41:43] <petev> that is not cool
[07:41:44] <jmkasunich> one is a variable, one is a constant
[07:42:06] <jmkasunich> putting the comp and the entity in the same file makes it noticable
[07:42:20] <jmkasunich> yes, I'm getting somewhere
[07:42:34] <jmkasunich> makefile now handles dependencies based on use lines
[07:42:48] <jmkasunich> and I'm changing one file at a time to use package
[07:42:53] <petev> ok
[07:51:23] <jmkasunich> taking the opportunity to merge a few files
[07:51:31] <jmkasunich> the timestamp counter is dedicated to quadrature counters
[07:51:54] <petev> would it be needed for anything else?
[07:51:54] <jmkasunich> so instead of timestamp.vhd and qcounter.vhd, I put them both in qcounter.vhd
[07:51:56] <jmkasunich> no
[07:52:10] <jmkasunich> if it is, I can pull it back out - not a big deal
[07:52:22] <jmkasunich> its a good test of two entities in one package and one file though
[07:56:39] <jmkasunich> heh, another one with Buswidth in the comp, and 31 hardcoded in the entity
[07:58:01] <petev> does this new code have a 32 bit PCI interface?
[07:58:15] <jmkasunich> yes
[07:58:24] <petev> good, the 16-bit stuff was a pain
[07:58:48] <jmkasunich> there are 4 regions, two I/O, one 16bit mem, one 32 bit mem
[07:59:01] <jmkasunich> but the FPGA uses only the 32 bit mem, we've standardized on that
[07:59:10] <petev> good
[07:59:55] <petev> what about the PCI VID/PID stuff?
[08:00:05] <jmkasunich> ?
[08:00:10] <petev> is it still using PLX numbers?
[08:00:21] <jmkasunich> I dunno what VID/PID is?
[08:00:33] <petev> the vendor and product id stuff
[08:00:37] <jmkasunich> oh
[08:00:45] <jmkasunich> its using the numbers that you used
[08:00:52] <jmkasunich> the bridge chip I guess
[08:01:08] <petev> I think the bridge has an eeprom though
[08:01:16] <jmkasunich> he would have to change the board itself to fix that (not the glass,but the eeprom contents)
[08:01:27] <petev> yes
[08:01:31] <jmkasunich> and that would break people with the old eeprom, unless the driver supported both
[08:01:44] <petev> there might even be a tool for that through the bridge
[08:01:47] <petev> I forget
[08:01:55] <petev> one of the chips had that support
[08:03:29] <petev> yeah, it was using straight PLX vendor and device ids
[08:03:45] <petev> so you couldn't tell it from a plain bridge
[08:04:03] <petev> I think one of the subsys ids was from mesa
[08:04:10] <petev> but the driver wasn't checking them
[08:04:18] <petev> I had some code in there
[08:04:21] <jmkasunich> a bit of bogosity, but he's kinda stuck with it now
[08:04:30] <petev> but the old mesa cards didn't have the right values
[08:04:43] <petev> the new ones may be fixed
[08:04:53] <petev> the question is what about the old ones?
[08:04:59] <petev> they may need re-programming
[08:05:01] <jmkasunich> don't you just love legacy issues?
[08:05:07] <petev> yeah
[08:05:18] <petev> I think the PLX util was DOS based too
[08:05:23] <jmkasunich> don't you just love legacy issues?
[08:05:24] <jmkasunich> oops
[08:05:32] <jmkasunich> wrong window ;-)
[08:06:16] <petev> yeah, there is an #if 0 in the driver to enable the additional checks
[08:08:44] <petev> what did u ever do with your pico stuff?
[08:09:22] <jmkasunich> sitting on a shelf
[08:09:38] <petev> relegated to driver testing ;-)
[08:09:43] <jmkasunich> yeah
[08:10:10] <jmkasunich> I'm gonna use one of my 5i20s for my actual CNC project, and play with the other
[08:10:21] <petev> yes, it's a good card
[08:11:01] <jmkasunich> I eventually want do do my spindle motor VFD with a mix of software and 5i20
[08:11:12] <petev> really
[08:11:20] <jmkasunich> I have a large AC servo motor
[08:11:25] <petev> why not just get one from work ;-)
[08:11:40] <jmkasunich> 99% of what we deal with is for induction motors
[08:11:55] <petev> you have a servo for the spindle?
[08:12:01] <jmkasunich> servos have peramanet magnet rotors, induction control doesn't work so well
[08:12:07] <jmkasunich> big servomotor
[08:12:12] <petev> how big?
[08:12:17] <jmkasunich> not neccessarily gonna do a servo loop on it
[08:12:42] <petev> you can get the old AB1398 drives for cheap on ebay
[08:13:08] <jmkasunich> this is one of those "because I can" things
[08:13:16] <petev> I have some 2.4 HP, but that's not enough for the spindle without gearing
[08:13:29] <petev> would need about 10-15 HP
[08:13:45] <jmkasunich> http://jmkasunich.dyndns.org/cgi-bin/blosxom/shoptask/spindle-12-19-06.html
[08:13:55] <jmkasunich> its 250 in-lb peak, 2000 RPM
[08:14:07] <jmkasunich> unfortunately the continuous rating is unknown
[08:14:32] <petev> that's a low rpm servo
[08:14:44] <petev> what is that in HP ?
[08:15:03] <petev> peak seems to be about 2x on the motors I have
[08:15:14] <jmkasunich> close to 8HP
[08:15:25] <petev> that's not bad
[08:15:36] <petev> it doesn't look that big
[08:15:36] <jmkasunich> you see the pic? its not a small motor ;-)
[08:15:46] <petev> maybe the scale is misleading
[08:15:50] <jmkasunich> 7" square, 17" long
[08:15:58] <petev> it looks about like my 2.4 HP continuous motors
[08:16:12] <jmkasunich> its quite possible that the cont rating is only about that
[08:16:14] <petev> that's pretty big
[08:16:31] <jmkasunich> the original motor is 3/4HP (chinese single phase horses)
[08:16:35] <petev> I think mine are about 5-6" square and maybe 13-14 long
[08:16:43] <petev> but they are higher RPM
[08:17:01] <petev> that's maybe 1/4 real HP
[08:17:10] <jmkasunich> I think I'm gonna arrange my spindle with two speed ranges
[08:17:16] <jmkasunich> 100-500 RPM and 500-2500
[08:17:27] <petev> I don't think you need it for that machine
[08:17:33] <petev> you could just run straight
[08:17:44] <petev> is 2000 the max RPM?
[08:17:57] <jmkasunich> for the motor? thats what on the nameplate
[08:18:16] <jmkasunich> my volts/rpm calcs say I could get it to 2800 or so with a 240V supply
[08:18:20] <petev> all of my servos give a continuous RPM and then a higher peak RPM
[08:18:33] <jmkasunich> my nameplate isn't that informative
[08:18:51] <jmkasunich> this is a discard from work about 8 years ago
[08:19:03] <petev> no model number to look up?
[08:19:07] <jmkasunich> it was a test article - still has thermocouples in it
[08:19:13] <petev> oh
[08:19:16] <jmkasunich> I've googled, no luck
[08:19:40] <jmkasunich> I have another one, a little smaller, that I want to use for the mill spindle
[08:19:40] <petev> did u put ball screw on there yet?
[08:19:48] <jmkasunich> its 175 in-lb
[08:19:52] <jmkasunich> no, ballscrews will come later
[08:20:52] <petev> did u do any thrust calcs?
[08:21:05] <petev> I have a spread sheet I made for the BP
[08:21:04] <jmkasunich> no, but I'm not worried
[08:21:13] <petev> the results are interesting to play with
[08:21:19] <petev> tells you what you need for motors
[08:21:20] <jmkasunich> most people who retrofit a shoptask use 300-500 oz-in
[08:21:23] <jmkasunich> I got 900
[08:21:51] <petev> I found my cals weren't far off what the big guys are using
[08:21:55] <jmkasunich> nice fast motors too - I had one up to 3600 RPM on the bench
[08:22:06] <jmkasunich> craploads of torque at 2000 RPM or so
[08:22:06] <petev> I found some specs on Okuma and others and I was right in there
[08:22:21] <petev> of course their rapids were way faster than mine
[08:22:44] <jmkasunich> I should get close to 100 ipm with my acme screws
[08:22:56] <petev> I'm setup for about 200
[08:23:01] <jmkasunich> more if I switch from 10 TPI acme to 5TPI ball
[08:23:02] <petev> the Okuma is over 1000
[08:23:10] <jmkasunich> on a machine this size, even 100 is plenty
[08:23:17] <petev> I think my machine would tip over at that speed
[08:23:30] <jmkasunich> 100 isn't that fast
[08:23:41] <jmkasunich> you should have seen us running the mazak at 450
[08:23:44] <petev> no, at 1000
[08:23:54] <jmkasunich> oh
[08:23:56] <jmkasunich> missed a zero there
[08:23:56] <petev> I was running at 120 with the steppers
[08:24:21] <jmkasunich> well, its 3am here
[08:24:34] <jmkasunich> the old config now uses packages, and it builds
[08:24:36] <jmkasunich> bedtime
[08:24:40] <petev> gn
[08:24:46] <jmkasunich> thursday I gotta start on the revised stepgen
[08:25:04] <jmkasunich> (found a few bugs and some possible optimizations in the existing design)
[08:25:23] <jmkasunich> thats what I've been trying to start on since monday
[08:25:39] <jmkasunich> I'm glad about the package thing, thats a big improvement
[08:25:52] <petev> at least you have a good foundation now
[08:28:10] <jmkasunich> yep
[08:28:13] <jmkasunich> goodnight
[08:28:18] <petev> gn
[13:14:39] <cradek_> cradek_ is now known as cradek
[15:48:14] <cradek> it appears the stepper-xyza sample config needs some cleanup, repair, and testing
[15:50:25] <jepler> sounds like it
[15:51:46] <cradek> grr
[15:53:42] <jepler> ??
[15:54:27] <cradek> sorry, I get grumpy when there's more than one thing to do at a time (I feel like both of ed's problems are for me to fix)
[15:58:22] <rayh> I can try to do that cleanup tonight, chris.
[15:58:45] <cradek> rayh: cool, thanks, do you have a machine with 4 axes?
[15:59:01] <rayh> Yes.
[15:59:03] <cradek> rayh: I do, but it's in pieces
[15:59:07] <cradek> great
[15:59:17] <rayh> Mine is always in pieces.
[15:59:43] <cradek> I know just how that is
[16:00:17] <cradek> that MAX_ANGULAR_VELOCITY is only for the angular jog speed slider in AXIS
[16:00:34] <cradek> it's deceptive
[16:01:08] <cradek> while you can make emc2 work great with rotaries, the necessary configuration is sure non-obvious
[16:01:09] <alex_joni> hi guys
[16:01:31] <cradek> hi alex
[16:01:42] <alex_joni> * alex_joni is still busy assembling his bot back :(
[16:02:57] <alex_joni> I'm sick of energy chains
[16:03:17] <cradek> I don't even know what that is
[16:04:03] <alex_joni> the thingies that carry cables
[16:04:20] <alex_joni> hang on.. looking for a pic
[16:04:35] <SWPadnos> http://www.aboveboardelectronics.com/igus/echain/index.html
[16:04:45] <alex_joni> http://img.thomasnet.com/pad/457449/00457449_159251.gif
[16:04:52] <cradek> oh right
[16:05:01] <alex_joni> SWPadnos: slightly bigger :D
[16:05:04] <SWPadnos> heh
[16:05:16] <alex_joni> about 45cm wide
[16:05:26] <SWPadnos> oh - that is wide
[16:05:40] <alex_joni> 5m long
[16:05:47] <alex_joni> I disassembled one twice today
[16:06:10] <SWPadnos> well, you should have done it right the first time. ;)
[16:06:14] <alex_joni> SWPadnos: :P
[16:06:26] <alex_joni> the first one I just put it back to get the system working
[16:06:33] <alex_joni> now I got some other stuff to put in there
[16:06:42] <alex_joni> brb.. gotta test the new motor
[16:13:00] <SWPadnos> oh - that problem with XYZA
[16:13:13] <SWPadnos> funny - I got the fix commit message before the problem report
[16:18:19] <cradek> there might be other problems (how the various limits are set)
[16:19:44] <cradek> those TRAJ limits aren't very useful or obvious in > 3space. Sometimes I think we should not even have them with trivkins/ngc (the 3 linear, 3 rotary scheme defined in ngc)
[16:20:29] <SWPadnos> hmm. the TRAJ limits "don't apply" to rotary, right?
[16:20:40] <cradek> if you set all the [TRAJ]MAX_* to 99999, I bet you get the behavior you typically want (with the possible exception of jog slider maximums)
[16:20:52] <cradek> yes, they do
[16:20:53] <SWPadnos> ie, EMC has no knowledge of the actual tooltip velocity once you throw angular motion into the mix
[16:21:12] <cradek> yes so it may be a bug
[16:21:38] <SWPadnos> I'm still reading the problem report (and jmk's reply, which just arrived)
[16:21:41] <cradek> the "tooltip" moves in 6space with 3 axes in inches and 3 in degrees
[16:23:12] <cradek> so what should the max velocity be? uh, "big enough" I guess
[16:23:28] <SWPadnos> but the rotary dimensions can't be applied to tooltip velocity without knowledge of machine construction
[16:24:03] <cradek> for the tooltip in 3space, you are right. for the tooltip in 6space, it can be (and is) applied
[16:24:08] <SWPadnos> I thought the spec called for "rotary motions to finish at the same time as cartesian" in mixed moves
[16:24:24] <cradek> yes, and they do - this confision is about vel/acc constraints only
[16:24:36] <cradek> confision?
[16:24:39] <SWPadnos> ok - and probably some other confusion I'm bringing to the mix ;)
[16:24:51] <SWPadnos> wee - I didn't even notice that - need more coffee
[16:24:54] <SWPadnos> see
[16:59:01] <alex_joni> yay.. that works fair enough :)
[16:59:38] <rayh> There was a professor in England who was going to take on the problem of tool tip velocity for six axes.
[17:00:03] <rayh> Paul visited with him but that was just before the divorce.
[17:00:46] <SWPLinux> that's partly a kins problem
[17:01:02] <SWPLinux> pivoting head vs. rotary tables
[17:01:27] <SWPLinux> hmmm - that may be a way to approach it
[17:02:13] <rayh> Right.
[17:02:25] <alex_joni> * alex_joni goes home (hotel actually)
[17:02:30] <alex_joni> later y'all
[17:02:37] <SWPLinux> see you
[17:02:48] <rayh> An integrator would have to be able to set locations and relationships between each axis and each other.
[17:02:52] <alex_joni> SWPadnos: I have some pics of that energy chain if you care ;)
[17:03:05] <SWPLinux> heh -too much cable for my little brain :)
[17:03:06] <alex_joni> later I mean
[17:03:18] <alex_joni> rayh: defining that is not that easy..
[17:03:25] <alex_joni> I wonder how one could express that
[17:04:09] <SWPLinux> it's a pain, I;m sure
[17:04:31] <alex_joni> position & orientation of the axis center
[17:04:52] <alex_joni> (if it's a rotary)
[17:05:00] <SWPLinux> and what it sits on, since the orientation can change due to another axis
[17:05:11] <alex_joni> SWPadnos: we do that on robots
[17:05:16] <SWPLinux> a 2-axis rotary table isn't so easy to define
[17:05:18] <alex_joni> first we define all axes
[17:05:24] <jepler> that's why RPV is desirable over ABC -- ABC is more like directing joints than cartesian axes
[17:05:25] <alex_joni> then we define a chain
[17:05:37] <alex_joni> bbl
[17:05:41] <SWPLinux> enjoy
[17:06:14] <SWPLinux> when you throw offsets into the mix, it gets really interesting, I think
[17:13:12] <rayh> I'm certain that the kinematic equasions can get complex.
[17:13:41] <rayh> I would like to see us do it for a simple A axis on a mill.
[17:13:53] <rayh> and for constant surface speed on a lathe.
[17:14:03] <SWPLinux> is that a pivoting head or a rotary table? ;)
[17:14:20] <rayh> I think those are only related in my imagination.
[17:14:27] <cradek> haha
[17:14:37] <SWPLinux> I agree
[17:14:44] <SWPLinux> (with both of you :) )
[17:14:47] <rayh> A normally is defined as a rotation about the x direction vector.
[17:15:15] <SWPLinux> yep. it's a question of whether that's a part rotation or a tool rotation
[17:15:43] <rayh> Sure I can see the difference.
[17:15:47] <SWPLinux> in some senses, they're the same, but they need to be dealt with differently
[17:17:20] <cradek> hmm, I wonder if I could (easily without breaking anything) make tooltip (TRAJ) limits ignore the rotary motion
[17:17:56] <cradek> right now you have to set TRAJ to the higher of the (unitless) values
[17:17:56] <SWPLinux> that's in tpRunCycle, isn't it?
[17:18:12] <cradek> no, it may start back in task
[17:18:15] <SWPLinux> ok
[17:18:30] <cradek> one would have to look at all the levels to be sure
[17:18:44] <SWPLinux> yeah - I was afraid of that :)
[17:18:56] <cradek> often a setup will go many more deg/sec than inches/sec, so the numbers in TRAJ have to be pretty big
[17:19:36] <SWPLinux> does posemath do the vector magnitude calcs?
[17:20:02] <cradek> look at emccanon.cc
[17:20:10] <SWPLinux> looking
[17:20:32] <cradek> that figures out limits based on the axes - maybe the traj limits are only in tp, not sure
[17:21:32] <SWPLinux> hmmm - what are the acceptable ANGLE_UNITS? (degrees + radians?)
[17:21:57] <cradek> yes
[17:21:57] <SWPLinux> the TO_PROG_ANG and FROM_PROG_ANG macros are empty
[17:22:02] <cradek> the base unit (1.0) is a degree
[17:22:18] <SWPLinux> there's no G-code to change from degrees to radians, is there
[17:22:20] <cradek> no
[17:22:28] <SWPLinux> ok, that (hopefully) explains that
[17:22:32] <cradek> yes
[17:35:01] <cradek> SWPLinux: if you notice that [TRAJ]MAX_ACCEL is not being used, let me know
[17:41:41] <SWPLinux> will do
[17:41:54] <SWPLinux> I'm just geting past SET_FEED_RATE ;)
[17:48:16] <cradek> // for arcs we always user linear move, as the ABC axes can't move (currently)
[17:48:31] <cradek> beware the wildly wrong comments
[17:48:34] <SWPLinux> heh
[17:49:24] <SWPLinux> there's some silliness in getStraightVelocity and getStraightAccel, but it doesn't look dangerous
[17:50:04] <cradek> can you explain the silliness in a few words?
[17:50:54] <SWPLinux> the angular axes are checked for 0 (which I'm not sure even works for a float), but dz is just used anyway (in calculating tmax for combined moves)
[17:51:15] <SWPLinux> the min/max macros aren't used (no biggie, but could possibly make the code look better)
[17:51:45] <cradek> yeah those sure help it be clearer
[17:51:48] <SWPLinux> all the deltas are checked for <=0, after they've been set to fabs(something) and set to 0 if <tiny
[17:52:13] <SWPLinux> like I said, silly but not dangerous
[17:52:20] <cradek> ta = da? fabs(da / FROM_EXT_ANG(AXIS_MAX_VELOCITY[3])):0.0;
[17:52:25] <jepler> ta da!
[17:52:34] <cradek> is this what you mean about checking for 0?
[17:52:42] <SWPLinux> also tiny is defined separately in each function as a const double, rather than being a #define or something
[17:52:44] <SWPLinux> yes
[17:53:07] <cradek> I think 0 is one of the few things representable in FP types
[17:53:33] <SWPLinux> yeah, and it's already there with if (da<tiny) da=0.0;
[17:54:03] <SWPLinux> so that line makes no sense - if da !=0 use it, but if it's 0 use 0 instead ...
[17:54:38] <SWPLinux> but the same thing isn't done for Z, so a 2-axis machine could possibly get teh divide by 0 that they're probably trying to prevent
[17:55:03] <SWPLinux> (no MAX_VEL or MAX_ACCEL to divide by)
[17:55:48] <SWPLinux> jepler: how much memory do 100k points take in AXIS?
[17:56:49] <jepler> SWPLinux: 16 megs, I think
[17:56:56] <jepler> a point is 3 floats + 4 bytes of color
[17:57:07] <SWPLinux> oh - that's more than I would have expected
[17:57:25] <jepler> oops, slipped a decimal
[17:57:24] <jepler> 1.6 megs
[17:57:33] <SWPLinux> the 16 minute (minimum) backplot seems a bit short
[17:57:37] <SWPLinux> ah - better :)
[17:57:55] <jepler> it's more the performance than the memory usage I'm concerned about
[17:58:13] <SWPLinux> yeah. it's a tough balancing act
[17:58:27] <SWPLinux> is it possible to add an ini var to set the limit?
[17:58:36] <SWPLinux> either as memory or number of points
[17:59:00] <jepler> I'd rather find a value that doesn't step on too many toes, than force each user to find a good value
[17:59:07] <SWPLinux> that makes sense too
[17:59:12] <jepler> obviously it's not technically ifficult to add a new ini item
[17:59:16] <SWPLinux> right
[17:59:20] <jepler> man I've been typing poorly lately
[17:59:34] <SWPLinux> I wonder if it makes sense to change the limit based on how much data the preview plot takes
[18:00:10] <SWPLinux> (or some version of that that makes sense)
[18:00:16] <jepler> ooh lunchtime
[18:00:22] <cradek> yay
[18:00:22] <SWPLinux> heh
[18:40:20] <SWPLinux> there are several places where linear velocity/accel is explicitly used for combined linear/angular moves
[18:40:53] <SWPLinux> it seems to me that the two need to be calculated separately and that both are needed for any combined move
[19:02:44] <cradek> SWPLinux: yes -- the move is along the linear portion. the angular portion follows it. in emccanon.cc, the vel/acc of the linear portion are adjusted so as to exceed none of the limits
[19:03:11] <cradek> at the TP level (in 6space) there is only one acc and vel. It's calculated back in emccanon.
[19:03:47] <SWPLinux> I'm looking at emccanon - that's what my comments are derived from
[19:05:05] <cradek> ok I don't see what you mean then - for instance look around line 416
[19:05:30] <SWPLinux> look in flush_segments
[19:05:49] <SWPLinux> } else if (linear_move && angular_move) {
[19:05:52] <SWPLinux> if (vel > currentLinearFeedRate) {
[19:05:53] <SWPLinux> vel = currentLinearFeedRate;
[19:05:55] <SWPLinux> }
[19:05:56] <SWPLinux> }
[19:06:38] <SWPLinux> linear and angular vels/accs are treated separately in the ini, but not when calculating the actual acc/vel for a move (it seems)
[19:06:56] <SWPLinux> I'm not willing to bet on whether I just don't understand or whether the code is wrong, though :)
[19:08:37] <cradek> hmm maybe that is wrong
[19:09:00] <cradek> I carefully tested all this before the flush_segments stuff was put in, and that broke a lot of things, maybe we didn't catch them all yet
[19:09:35] <cradek> that may be why stepper-xyza is acting wrong now
[19:09:36] <SWPLinux> flush_segments is identical to STRAIGHT_TRAVERSE and STRAIGHT_PROBE
[19:09:47] <SWPLinux> in terms of maxvel calcs
[19:10:28] <cradek> I don't think so, flush_segments nukes the result of getStraightVelocity, STRAIGHT_TRAVERSE doesn't
[19:10:42] <SWPLinux> ok - lemme look again
[19:12:10] <cradek> STRAIGHT_PROBE does
[19:13:12] <SWPLinux> the only functional difference I see is that STRAIGHT_TRAVERSE sets linearMoveMsg.{vel,ini_vel} to the same value and flush_segments uses two possibly different values
[19:13:34] <SWPLinux> ok - it makes sense for PROBE to be different anyway - I didn't look as closely at it as I could have
[19:14:03] <jepler> queued segments can only ever be XYZ moves
[19:14:14] <cradek> oh is that what we're missing?
[19:14:15] <SWPLinux> that's true
[19:14:36] <jepler> at least -- that's how it's supposed to work
[19:14:35] <cradek> I now remember you told me that once before (last time I missed it)
[19:14:59] <SWPLinux> it sure does work that way - if a,b, or c need to change, linkable() returns false
[19:15:33] <jepler> then maybe it deserves a comment in the source
[19:16:35] <SWPLinux> maybe flush_segments should dispense with the checks for angular_move vs linear_move then
[19:17:05] <cradek> sure could
[19:17:28] <SWPLinux> that would remove the confusion almost as well as a comment :)
[19:19:30] <alex_joni> 'lo
[19:19:53] <SWPLinux> hi
[19:20:58] <cradek> hi alex
[19:21:28] <jepler> despite having written the code I'm not sure my analysis is right
[19:21:42] <cradek> SWPLinux: I forget what we started out trying to fix/find
[19:21:56] <SWPLinux> some rotary+linear problem from Ed
[19:22:17] <cradek> right
[19:22:37] <cradek> hard to say if he's just misconfigured
[19:22:43] <cradek> whether
[19:23:20] <cradek> I wish I could test it here, but I probably can't really make any sense out of it without hearing my steppers
[19:23:42] <cradek> maybe tonight (if you don't find a problem by then)
[19:24:02] <cradek> I'm going to try to nail that comp bug instead, meanwhile
[19:24:18] <alex_joni> comp?
[19:24:36] <cradek> arcs in relative mode while in cutter comp
[19:24:47] <cradek> (may not be just arcs)
[19:24:52] <SWPLinux> hmmm. you don't get the speaker output driver in sim, do you?
[19:25:02] <cradek> no
[19:25:05] <cradek> I tried that too
[19:25:06] <SWPLinux> bummer
[19:25:25] <cradek> maybe I could hack it, but it might not work well enough without realtime
[19:25:29] <cradek> ... to be useful
[19:25:34] <SWPLinux> yeah - you'd never know
[19:26:52] <rayh> We might talk with Matt about the combined rotary and linear move stuff.
[19:27:06] <rayh> He put that in there for the sherline stuff.
[19:27:18] <cradek> rayh: I pretty much replaced it all
[19:27:52] <SWPLinux> I may not have found it yet, but it looks like the two sets of constraints are handled as one set of constraints sometimes
[19:28:29] <SWPLinux> I think the spec basically treats rotary and linear moves as separate things that just happen to take the same amount of time
[19:28:42] <rayh> There was a big difference between coordinated and single axis motion.
[19:29:14] <rayh> But we have to slow a linear move if we exceed the angular max vel or max accel.
[19:29:57] <rayh> Otherwise the linear sets the speed of the rotary
[19:30:02] <SWPLinux> it seems to me that a combined move is meant to be effectively 4 independent moves that must take the same amount of time. one of those 4 is the cartesian vector, and the other 3 are the rotary axes, which are independent (of the linear move and each other)
[19:30:17] <rayh> at least that is how it was back then.
[19:30:24] <cradek> SWPLinux: that's right
[19:31:03] <SWPLinux> ok. it looks like the calcs don't keep things separate in all the right places (though I certainly be wrong about that)
[19:31:28] <cradek> SWPLinux: well the 3 rotaries feed together (feed rate is specified along the pseudocartesian 3space made with the rotaries)
[19:31:56] <SWPLinux> ok, so you have (for arguments sake) two sets of cartesian moves
[19:31:59] <cradek> yes
[19:33:30] <SWPLinux> then I guess I'd make some very robust 3-axis functions (which are probably already there), and use them on the two triplets of ordinates
[19:35:08] <SWPLinux> I don't know that it makes sense to do a sqrt(sum(squares)) on the rotaries though
[19:35:11] <cradek> can that let you pick acc and vel along the 6d vector, such that the worst constraint is just met?
[19:35:23] <SWPLinux> there is no single constraint in 6-space
[19:35:31] <SWPLinux> at least, none in the ini
[19:35:32] <cradek> (that's in ngc)
[19:35:47] <cradek> yes there is, [traj]maxvel
[19:36:08] <SWPLinux> is there a spec on how to combine angular vels and linear vels into a single vel?
[19:36:29] <cradek> yes it's spelled out in ngc
[19:36:38] <SWPLinux> ok - I'll look at that again
[19:36:39] <cradek> er do you mean vels or feeds?
[19:36:48] <cradek> how the feed is specified is spelled out
[19:37:02] <SWPLinux> right
[19:38:25] <SWPLinux> from the origin, G1 X1 Y1 Z1 A<something> B<something> C<something> F60 should take sqrt(3) seconds to complete, no?
[19:38:51] <jepler> SWPLinux: assuming the motion on A, B, and C can be completed in that time as well
[19:38:57] <SWPLinux> + some accel/decel time
[19:39:01] <cradek> yes
[19:39:07] <SWPLinux> yes, and assuming that the constraints are so big that it's possible
[19:39:21] <cradek> ngc says abc start/stop together with xyz, and their constraints are all honored
[19:39:29] <cradek> that's all it says about combined moves
[19:40:51] <cradek> (I swear this all worked right)
[19:41:07] <SWPLinux> ok, so the time it takes to do the combined move is meant to be determined in the following order:
[19:41:19] <jepler> there's probably still something wrong in the segment combining
[19:41:23] <jepler> I can't quite put my finger on it
[19:41:46] <SWPLinux> nevermind that last - you know how it's supposed to work :)
[19:41:52] <cradek> haha
[19:42:12] <cradek> SWPLinux: yes, like that
[19:42:32] <rayh> I'm waiting for the list "determined in the following order"
[19:42:48] <jepler> a derail here, but it's true that motion.feed-hold is only honored with M53 P1, right?
[19:42:57] <SWPLinux> ok - here it is (I think)
[19:43:02] <SWPLinux> 1) feed rate
[19:43:07] <alex_joni> jepler: if that's the right number, yes
[19:43:11] <SWPLinux> 2) individual axis limits
[19:43:15] <SWPLinux> 3) overall limits
[19:43:33] <SWPLinux> the question is how "overall limits" can be applied to combined moves
[19:43:57] <rayh> what are overall limits?
[19:44:05] <SWPLinux> the spec says basically that you have 4 limitations - the vector cartesian move, and each rotary axis
[19:44:06] <cradek> apply to only the cartesian part?
[19:44:18] <SWPLinux> [TRAJ]MAX_{vel,acc}
[19:44:27] <SWPLinux> are the overall limits
[19:44:35] <rayh> Ah okay.
[19:44:36] <cradek> SWPLinux: I am not sure the spec says anything about the vector limit for ngc machines - I bet that's a nontrivkins addition
[19:45:11] <SWPLinux> hmmm
[19:45:41] <rayh> I'd bet it doesn't exist at all.
[19:46:09] <cradek> wait, maybe TRAJ does apply just to the cartesian part of combined moves
[19:46:25] <SWPLinux> hmmm - [TRAJ]MAX_{ANGULAR,LINEAR}* are only used as defaults for the individual joints
[19:46:28] <SWPLinux> right?
[19:46:33] <cradek> it's the angular moves that would be the problem then
[19:46:48] <SWPLinux> it's only [TRAJ]MAXVEL that actually "does anything"
[19:46:49] <cradek> SWPLinux: it's checked in TP I think
[19:46:57] <cradek> oh, ok
[19:47:36] <SWPLinux> I'm not sure I'm right on that, but I think iniaxis loads traj values then overwrites them with individual axis values
[19:47:45] <SWPLinux> I'm not sure the TRAJ limits are used after that
[19:47:56] <cradek> I'm sure I knew how this worked a year ago
[19:48:07] <SWPLinux> heh
[19:48:07] <cradek> so don't trust me too much either
[19:48:11] <cradek> really
[19:48:39] <SWPLinux> well, "how it works" is less important than "how it's supposed to work"
[19:48:50] <SWPLinux> except when they diverge :)
[19:49:07] <rayh> I'm with cradek about a year ago.
[19:50:12] <alex_joni> heh
[19:50:14] <SWPLinux> the problem I see is that there's no way to extract 3 different vels for the angular axes from a single velocity
[19:50:15] <rayh> If I issued "g1 f10 x0.001 a720" the x move would complete when the A finished rotating as fast as it could.
[19:50:45] <SWPLinux> and a combined move gets a single velocity, as far as I can see
[19:50:49] <alex_joni> rayh: right
[19:51:30] <cradek> rayh: do you mean you tested 2.0.x a year ago with these combined moves and found that it all worked right?
[19:51:48] <rayh> I didn't.
[19:52:00] <cradek> oh ok
[19:52:36] <rayh> Last testing I did was with emc-bdi4-30 or so.
[19:53:09] <jepler> ouch -- I found the bug in segment combining
[19:53:18] <cradek> ooh!
[19:53:30] <alex_joni> why ouch?
[19:53:40] <jepler> because the result of the bug would be very bad
[19:54:11] <jepler> http://pastebin.ca/385315
[19:54:43] <SWPLinux> I didn't notice a loop in flush_segments - am I blind?
[19:54:52] <jepler> in the second part, X and A both move at the same time
[19:54:58] <rayh> I can plug stuff together here and get a system going fairly quickly if we need.
[19:55:41] <cradek> oh holy crap
[19:55:43] <jepler> it reaches A=4 X=3 at the same time
[19:55:57] <SWPLinux> hmmm
[19:57:18] <jepler> we should just revert the segment joining code
[19:57:41] <SWPLinux> but the segment joining shouldn't (famous last word) be used on combined moves ...
[19:57:57] <SWPLinux> or any thing with ABC motion
[19:58:00] <jepler> yes, but the code is wrong
[19:58:04] <cradek> jepler: nah, just fix the "last" bug in it
[19:58:10] <SWPLinux> oh - well that would be a poblem ;)
[19:58:14] <SWPLinux> problem too
[19:58:29] <jepler> it notices "oh, this next move changes ABC -- I'd better flush what came before
[19:58:32] <jepler> "
[19:58:36] <cradek> if we removed all the code that might have bugs ...
[19:58:42] <jepler> then it says "Oh, this move to X=3 is colinear with the move to X=2, so I can combine them"
[19:58:48] <jepler> then it says "better flush, I'm moving to A9"
[19:59:45] <jepler> so it's not until the same time it outputs the move to X=3 that it outputs the move to A=4, and the axes move together
[19:59:50] <SWPLinux> why is the old linear move still under consideration after a non-chainable move?
[20:03:30] <cradek> Breakpoint 1, ARC_FEED (first_end=2, second_end=2.53125, first_axis=2,
[20:03:30] <cradek> second_axis=3, rotation=1, axis_end_point=9.9999999999999995e-21, a=0,
[20:03:30] <cradek> b=0, c=0) at emc.hh:1145
[20:03:32] <cradek> think I found it...
[20:04:26] <jepler> cradek: hooray
[20:04:45] <cradek> well not quite, but smoking gun anyway (see above)
[20:05:52] <jepler> I'm not sure what you see there but I take your word for it
[20:06:05] <cradek> axis_end_point is unset
[20:06:27] <rayh> I presume that "x3 a360" does not become colinear with a next "x2"
[20:09:09] <jepler> this is what I believe the current, buggy code is doing:
[20:09:12] <jepler> http://pastebin.ca/385331
[20:11:25] <rayh> Wah that is a mess.
[20:11:31] <jepler> er, except it has to be P.001 at the first line so that combining is enabled
[20:12:07] <SWPLinux> oops
[20:12:21] <SWPLinux> see_segment should test for !empty || !linkable, not &&
[20:12:39] <SWPLinux> maybe not
[20:12:55] <SWPLinux> nevermind
[20:15:05] <SWPLinux> I think the logic in see_segment is faulty though
[20:15:22] <jepler> yes
[20:15:44] <jepler> if the movement is a change in angle not only does it need to flush stuff before, but it needs to immediately perform this movement
[20:16:04] <SWPLinux> right, and *not* place this move in the vector
[20:16:30] <jepler> http://pastebin.ca/385338
[20:16:31] <SWPLinux> (which "perform this move" would imply :) )
[20:16:57] <SWPLinux> that check is already in linkable()
[20:17:27] <SWPLinux> so if it's !linkable, then flush if !points.empty(), and in any case do this move
[20:18:00] <jepler> then you'll never link anything
[20:18:10] <SWPLinux> hmmm -could be
[20:19:26] <jepler> (or if you prefer to see it as a diff:
http://pastebin.ca/385341)
[20:19:55] <jepler> but anyway flush_segments *can* be performing a move in any of XYZABC so it should be correct for all those cases -- did you see that it wasn't?
[20:20:41] <SWPLinux> I don't think I saw that, but I'm not sure
[20:24:06] <SWPLinux> ok - it can be used, but there should never be more than one segment for anything that includes ABC motion
[20:35:24] <rayh> It seems there would be a case for coangular
[20:35:42] <SWPLinux> yeah - I was thinking that
[20:35:47] <rayh> and a combined colinear coangluar
[20:35:51] <SWPLinux> or even co-both
[20:35:57] <SWPLinux> rigth
[20:35:58] <SWPLinux> right
[20:36:11] <SWPLinux> I'm not sure what the spec says onthat subject though
[20:36:22] <rayh> gotta quit trying to think with the big dogs.
[20:41:54] <rayh> Darn I like the new classic ladder.
[20:42:09] <rayh> Gotta fix up mazak's ladder soon.
[20:44:35] <jepler> rayh: is it better? I never heard much feedback about whether the upgrad was an improvement
[20:44:48] <jepler> rayh: just one bug report that the ladder didn't function when the gui wasn't open (fixed in 2.1.1 emc)
[20:47:53] <rayh> Yes a lot better. Just the ability to use names for variables makes the system much more readable.
[20:48:10] <rayh> The ability to print from cl using pdf is awesome.
[20:48:32] <rayh> that print ability requires an additional package.
[20:49:16] <jepler> the pre-built package is supposed to include printing
[20:49:55] <rayh> It does have a print button.
[20:52:00] <rayh> I'll have to test on another system.
[20:58:06] <jepler> it looks like the 2.1.0 package on breezy didn't have printing enabled for some reason, but the 2.1.1 package does
[20:58:10] <jepler> that's the -sim package
[20:58:17] <jepler> I am unable to test the realtime or dapper packages at the moment
[20:58:39] <jepler> errr
[20:58:43] <jepler> that's the realtime package on breezy
[20:59:17] <cradek> the libgnomeprintmumbleuimumble dependency was wrong in 2.1.0
[20:59:46] <jepler> OK
[21:00:09] <jepler> looks like that and the classicladder nogui fix didn't get mentioned in the debian/changelog :(
[21:01:21] <cradek> oops
[21:02:16] <jepler> bbl
[21:08:23] <cradek> think I fixed comp
[21:08:29] <cradek> there are SO many cases
[21:21:51] <SWPLinux> cradek: sorry for the delay but yay!
[21:22:28] <cradek> I'm not sure I know how to enumerate all the cases for testing
[21:22:58] <cradek> first comp move can be an arc or line
[21:23:02] <cradek> second comp move can be an arc or line
[21:23:13] <cradek> either can have words missing (sticky from previous lines)
[21:23:23] <cradek> either can be in relative mode
[21:23:42] <SWPLinux> hmmm. I should read that problem report
[21:23:49] <cradek> the sticky values can come from before or after comp was turned on
[21:23:56] <SWPLinux> when was it sent? (or was it the same email as the blending bug)?
[21:24:08] <SWPLinux> err - not blending - the other one we were looking ar
[21:24:10] <SWPLinux> at
[21:24:16] <cradek> 80 r Mar 06 Ed ( 82) [Emc-users] Relative coordinate change?
[21:24:23] <SWPLinux> ko
[21:24:25] <SWPLinux> ok
[21:25:31] <cradek> plane can be XY or XZ (probably don't have to test both, but it wouldn't hurt)
[21:25:31] <SWPLinux> don't forget G20/G21 changes mixed in ...
[21:25:41] <cradek> ouch
[21:25:45] <SWPLinux> heh
[21:25:50] <cradek> I bet that badly screws up radius comp
[21:26:11] <SWPLinux> yeah - what units are teh tool table in?
[21:26:30] <SWPLinux> (at any given moment)
[21:26:38] <cradek> CHK((settings->cutter_comp_side != OFF),
[21:26:38] <cradek> NCE_CANNOT_CHANGE_UNITS_WITH_CUTTER_RADIUS_COMP);
[21:26:42] <cradek> yay
[21:26:44] <SWPLinux> heh
[21:27:12] <SWPLinux> tool table is in MACHINE_UNITS?
[21:27:18] <SWPLinux> (whatever those might be)
[21:27:27] <cradek> that's up in the air afaic. ngc says they are in whatever current g20/g21 units
[21:27:42] <cradek> (and I think that's crazy)
[21:27:42] <SWPLinux> oh -that's annoying
[21:27:50] <SWPLinux> yes, crazy is a better word
[21:28:03] <SWPLinux> sigh. units need a major overhaul
[21:28:29] <cradek> (ngc needs a minor overhaul)
[21:28:33] <cradek> IMO IMO
[21:28:37] <SWPLinux> well, that's probably true too
[21:29:08] <cradek> but right now, that's the way the tool table works
[21:29:15] <cradek> (probably)
[21:29:19] <SWPLinux> right
[21:34:14] <cradek> SWPLinux: are you going to be able to test it or were you just curious?
[21:34:31] <SWPLinux> I only have sim, but I can do some testing
[21:34:49] <cradek> sim is fine for testing comp
[21:34:54] <SWPLinux> I'm not very knowledgeable on the subject, so I'm probably not the best person to construct test cases though
[21:35:19] <cradek> I like to have the gcode twice in the program, once without comp on, once with - it's easy to see if the tool follows it
[21:35:34] <SWPLinux> sure
[21:36:04] <cradek> I bet ray, jon and I are the only ones in the group who know it intimately
[21:36:20] <SWPLinux> heh - that's probably true
[21:36:25] <cradek> and I bet ray's busy looking for his 4th axis about now :-)
[21:36:29] <SWPLinux> dave-e or someone like that may as well
[21:37:05] <cradek> the things to note are: the first move after turning on comp is special, the subsequent ones are all the same
[21:37:18] <cradek> you can move the "other" axis freely with comp on
[21:37:23] <SWPLinux> and the first after turning it off, I imagine
[21:37:40] <cradek> watch for sticky words and relative mode tricks
[21:38:07] <cradek> hmm wonder how an arc after turning it off would work
[21:38:22] <cradek> a relative mode arc
[21:38:27] <cradek> it may be wrong.....
[21:38:47] <cradek> IJ might be relative to the wrong start point
[21:39:14] <SWPLinux> I'm looking for documentation on the tool table format, and I can't find any
[21:39:18] <cradek> heck I'm not really sure what it should do
[21:39:32] <SWPLinux> a "tool table page" is references in the emc2 user manual, but I didn't see it
[21:39:47] <SWPLinux> referenced
[21:40:12] <cradek> I know it's there but I don't see it either
[21:40:41] <SWPLinux> ah - it's called "tool file", not "tool table"
[21:40:43] <cradek> http://www.isd.mel.nist.gov/personnel/kramer/pubs/RS274NGC_3.web/RS274NGC_32a.html#1000190
[21:40:46] <cradek> yep
[21:40:58] <cradek> beware the lathe tool table is different - more columns
[21:41:02] <SWPLinux> yep
[21:41:23] <cradek> bonus points if you can figure out what FMS stands for
[21:42:25] <SWPLinux> "Foolish Management System"
[21:42:52] <cradek> Ftool Mbarcode Snumber
[21:42:58] <SWPLinux> heh
[21:43:12] <SWPLinux> now, which is used for D- ?
[21:43:24] <cradek> the first column
[21:43:29] <cradek> I don't think the second does anything
[21:43:36] <SWPLinux> ok - that's good (ish)
[21:43:48] <cradek> by good you mean crazy?
[21:43:58] <SWPLinux> consistent, and ripe for removal ... :)
[21:44:29] <cradek> I'm very interested in ray's idea of specifying tool specs in the gcode
[21:44:38] <SWPLinux> that would be very nice
[21:44:56] <cradek> it would be extremely cool to have a graceful way to use a tool length measuring device on the mill
[21:45:10] <SWPLinux> either a file to load, or the table in the G-code, or specifying actual numbers at M6 time would be nice
[21:45:12] <SWPLinux> that too
[21:45:26] <SWPLinux> (or any combination of those 3)
[21:45:31] <cradek> yes
[21:45:34] <SWPLinux> err - 4
[21:45:42] <SWPLinux> "auto"
[21:46:14] <cradek> T06251000 M6 (load 1" long 1/16" end mill)
[21:46:20] <cradek> * cradek coughs
[21:47:02] <SWPLinux> M6 T1 L1.000 D0.0625 (load 1" long 1/16" end mill)
[21:47:26] <cradek> aside from L and D being integers...
[21:47:51] <SWPLinux> well, that's how it is now ...
[21:48:05] <cradek> wonder if D is used anywhere else - I know L is
[21:48:42] <cradek> H is length actually
[21:49:06] <SWPLinux> it's listed as "Tool radius compensation number"
[21:49:09] <SWPLinux> D that is
[21:49:26] <SWPLinux> H is listed as an index, not a length
[21:49:46] <cradek> right they're both indexes
[21:52:01] <cradek> we could have a new M code that programs a "variable" tool's parameters, like call it T1000
[21:52:53] <cradek> that isn't quite the same as specifying a table at the beginning of the program, but it would let us do measuring
[21:53:22] <SWPLinux> ok - stepping back to look at this from a higher level, there's a potential problem in combining tool information and part information in the same file (regardless of how it's done)
[21:53:36] <SWPLinux> 1) you have non-protable code (probably not an issue)
[21:53:41] <SWPLinux> portable
[21:54:16] <SWPLinux> 2) the G-code (possibly written by lackeys) may override machine configuration (presumably done by experts)
[21:54:19] <rayh> I used probe upside down, grabbed the number in tcl, subtracted from part zero and put it in the tool table
[21:54:29] <SWPLinux> auto I like
[21:55:10] <SWPLinux> what would be very cool would be the ability to select tools by tool spec (in the G-code), and have the interp "find" the right tool number for the given dimensions
[21:55:39] <SWPLinux> so you ask for a 0.25" diameter 1" tool, and if there is one in the carousel, that gets loaded
[21:55:53] <SWPLinux> dunno exactly what to do if there isn't an exact match though
[21:57:42] <skunkworks_> would work like font substituion - we can't find 'this' tool do you want to use 'this' one ;)
[21:57:55] <SWPLinux> heh - no way! ;)
[21:58:52] <SWPLinux> but I can see a tool table that has "nominal" fields and an actual field, so you can ask for a 1/4" diameter, and get the 0.123 reground tool that's supposed to be 0.125
[21:59:02] <SWPLinux> err - 0.247 vs. 0.250
[22:01:19] <cradek> I have to run - thanks SWPLinux for checking/testing all my various buggy work
[22:01:26] <cradek> I'll be back tonight
[22:01:36] <SWPLinux> err - I guess I need to test now :)
[22:05:11] <alex_joni> night all
[22:09:42] <rayh> There seems to be a memory leak or some such with demo_step_cl. It just gets slower and slower to edit.
[22:09:54] <rayh> edit cl
[22:11:45] <SWPLinux> and it gets fast again if you exit and restart?
[22:12:06] <rayh> It won't save the work I did so I've not tried to exit.
[22:12:13] <SWPLinux> ah
[22:12:18] <rayh> talk about catch22
[22:12:29] <SWPLinux> I've never been able to edit at all, so I can't really help you :)
[22:15:25] <rayh> aha save as did work.
[22:15:41] <rayh> and yes the system speeds back up.
[22:15:42] <SWPLinux> I was just going to suggest that :) (discovered it at the same time, apparently)
[22:15:45] <SWPLinux> ok
[22:16:29] <SWPLinux> how do you name things?
[22:16:32] <rayh> ULAPI: WARNING module "HAL_classicladder" failed to delete shmem 03
[22:16:35] <SWPLinux> (with readable names)
[22:17:11] <rayh> I was trying readable names.
[22:17:34] <SWPLinux> I don't see how to create any (from the GUI)
[22:17:34] <rayh> Pretty limited but better than nothing. 7-8 character names at most.
[22:17:52] <rayh> You have to start with new cause it can't edit old.
[22:18:32] <SWPLinux> I added a section, and this is from the saved-as file (though I didn't reload it - hmmm)
[22:20:02] <rayh> I found it easiest to click the Symbols button first and add all the %xx and name stuff first.
[22:20:49] <SWPLinux> ah - the names weren't editable before (you're right, it must be a "new" file)
[22:20:50] <rayh> Wow there is a lot of debug stuff that comes out to the terminal.
[22:21:00] <SWPLinux> I wonder if that's because of a file format change or something
[22:21:10] <SWPLinux> I noticed that as well
[22:21:59] <rayh> Must be a change in file format.
[22:23:30] <SWPLinux> ok -don't let the fixed number of variables thing confuse you - I was wondering what the heck was happening until I accidentally re-sorted by variable descending
[22:23:42] <SWPLinux> editing may have been working afer all
[22:23:42] <SWPLinux> after
[22:24:45] <rayh> for some reason I don't seem to be able to add the third timer to the lube rung.
[22:25:11] <SWPLinux> for some reason, I can't stand editing ladder diagrams ;)
[22:25:23] <SWPLinux> (in any editor I've tried, for what it's worth)
[22:25:36] <rayh> I see erase still does not work on vertical lines.
[22:29:12] <rayh> I know what you mean even the AB stuff is klunky.
[22:31:37] <rayh> Ah. You don't get any info in the symbol widget when you load an clp file.
[22:32:22] <SWPLinux> oh - that could be a problem :)
[22:36:01] <rayh> and you can not edit or change anything on that display.
