Back
[00:22:14] <ve7it> ve7it is now known as LawrenceG
[00:34:23] <jmkasunich> SWPadnos: around?
[00:34:32] <jtr> SWPadnos: no preference on the RoHS issue here. I'm off to drain the basement. :(
[00:34:41] <jmkasunich> is it too late to request some mate-n-locks for the H bridge board?
[00:36:47] <jmkasunich> <cradek> I'd rather he would have fixed it instead of sending an email :-)
[00:36:59] <jmkasunich> I was at work... I'm gonna look into fixing it tonight
[00:37:29] <jtr> glad you said that. I think he was talking about ordering 25. I'd go for some as well.
[00:38:20] <jtr> about the mate-n-locks. How many boards did we order that needed them?
[00:39:23] <jmkasunich> looks like 5
[00:39:29] <jmkasunich> 4 connectors per board I think
[00:42:10] <jtr> that's what I wsa thinking. well, i'm in for 4 or 5, depending on if he wants to keep spares. I'm in no rush for the boards.
[00:42:27] <jtr> no way I'll have the lathe ready for Cabin Fever.
[00:42:58] <jtr> now i'm really off to drain the swamp.
[00:43:13] <jepler> isn't 3x24 = 72 I/O points
[00:43:25] <jepler> oh you're talking about the 7i30s -- forget it
[00:44:14] <jmkasunich> back in a bit
[00:46:35] <jepler> jmkasunich: I wrote but didn't test this patch:
http://pastebin.ca/301834
[00:46:46] <jepler> in fact I didn't even compile it :-P
[01:33:12] <SWPadnos> hi folks - I'm back
[01:40:32] <jepler> hi swp
[01:40:50] <SWPadnos> hi jepler - no, I don't know of a sonata for micro-atx :)
[01:41:28] <SWPadnos> I think you'd be hard pressed to find a small case with that drive mounting method
[01:47:37] <jepler> I don't feel at all confident picking out a motherboard for linux :(
[01:47:51] <jepler> will this nic work? what about the sata?
[01:48:01] <jepler> people have problems with every motherboard, but is it just because they're clueless?
[01:48:30] <SWPadnos> I've had no issues with anything other than wireless (which I think is due to my very old 54g card) and lmsensors on the Opteron board
[01:49:03] <SWPadnos> though it's only the most recent revision of SuperMicro's hardware monitor (for Windows) that supports this motherboard anyway
[01:49:25] <jepler> I'm not looking at server-class stuff, I'm too cheap. Here's the motherboard I'm investigating most recently:
http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ProductID=2281
[01:49:56] <jepler> maybe the ethernet works with the "forcdeth" driver, maybe not
[01:51:06] <SWPadnos> the integrated GigE in the NForce 2200 and 2050 worked perfectly without any effort on my part
[01:51:11] <SWPadnos> usin ubuntu
[01:51:13] <SWPadnos> usung
[01:51:14] <SWPadnos> using
[01:52:02] <jepler> there are several drivers that refer to "marvell 88e..." in the source, but not 88e1116 specifically
[01:52:16] <SWPadnos> funny that they have notes about Linux and Win98/ME in the same place on that page
[01:52:24] <SWPadnos> hmmm
[01:52:36] <jepler> the linux kernel source, that is
[01:52:54] <SWPadnos> is that chip not in the pci.ids file?
[01:54:08] <jepler> not under that name
[01:54:40] <jepler> this person has in his signature:
[01:54:40] <jepler> AM64 3000+ / 512Mb
[01:54:40] <jepler> GeForce 6100 (onboard)
[01:54:40] <jepler> Gigabyte GA-M51GM-S2G
[01:54:41] <jepler> With Edgy it becomes a 286
[01:54:48] <jepler> ^^ which is not encouraging at all
[01:54:49] <SWPadnos> heh
[01:55:10] <SWPadnos> this isn't encouraging either: "segfaults, kernel panic using forcedeth nvidia 4"
[01:55:16] <SWPadnos> from MARC LK archives
[01:58:49] <SWPadnos> jmkasunich & jtr - I can get some of those connectors. It'll delay the other stuff by a few days, but I'd expect it to arrive by the middle to end of next week
[01:59:10] <SWPadnos> I'd want to be very sure about the connectors and pins I get though - there are a lot of similar options
[02:03:27] <jepler> cradek: we should look in the basement for those 50-pin ribbon connectors soon
[02:03:42] <jepler> cradek: you're the only one with the key or I'd go poking around myself
[02:05:19] <jepler> SWPadnos: this disclaimer about the "high performance memory design" (the paragraph in red) is a hoot:
http://www.msicomputer.com/product/p_spec.asp?model=K9N6SGM-V
[02:05:51] <SWPadnos> funny - I misread that link as "miscomputer"
[02:06:09] <jepler> hah
[02:06:40] <SWPadnos> that board has several "non-starter" features
[02:06:55] <SWPadnos> the "may not work because it's so fast" thing is one (and a funny one)
[02:07:12] <SWPadnos> then there's the "these kinds of ATI card won't work in the PCIe slot
[02:07:26] <jepler> yeah -- I quickly decided against that board
[02:11:01] <SWPadnos> http://www.linuxforums.org/forum/peripherals-hardware/68102-am2-motherboard-linux.html
[02:11:08] <jepler> seen in a motherboard manual:
http://emergent.unpy.net/files/sandbox/should-be-shot.jpg
[02:12:00] <jepler> darn: "powernow-k8: MP systems not supported by PSB BIOS structure"
[02:12:02] <SWPadnos> yeah - the whole "must have strangely shaped 24-bit background windows" thing has gone waaaaay too far
[02:12:15] <jepler> I'd like CPU frequency support -- never got it to work in my current system
[02:12:33] <SWPadnos> hmmm - I should see if it's working on the Opteron
[02:16:52] <jepler> looks like that board is the same ethernet and similar in other respects
[02:17:04] <jepler> I wonder if it's a mistake to hope to use the onboard video (not for realtime
[02:17:05] <jepler> )
[02:17:23] <SWPadnos> I was thinking that the 6100IGP could be the main sticking point
[02:17:31] <SWPadnos> but I'm not sure
[02:17:57] <jepler> I think it is supposed to work but I dunno how adversely it affects performance
[02:18:22] <SWPadnos> yeah - hard to know a priori
[02:18:38] <jepler> you'd think someone would benchmark it
[02:19:07] <jmkasunich> * jmkasunich is back
[02:19:07] <SWPadnos> not much point, I guess. most server boards don't use that chipset, and most non-server users use add-on cards I bet
[02:19:11] <SWPadnos> hi jmk
[02:22:00] <SWPadnos> there's a guy selling several Bulletin 1388 servo drives on eBay
[02:22:09] <SWPadnos> cheap, plus shipping (so far)
[02:22:25] <jepler> looks like performance is about the same whether you stick a video card in or not, if you trust these windows "application" benchmarks:
http://www.xbitlabs.com/articles/chipsets/display/gf6150-gf6100_12.html http://www.xbitlabs.com/articles/chipsets/display/gf6150-gf6100_16.html
[02:23:26] <jepler> whether that's because the "suck" doesn't get turned off with the addition of a dedicated video card, I can't say
[02:23:32] <SWPadnos> the xpress 200 is ATI's onboard graphics chip, I think
[02:23:53] <SWPadnos> so that comparison is nVidia onboards vs. ATI onboard
[02:24:18] <SWPadnos> ah - now I look at page 16 ... :)
[02:24:20] <jepler> no -- page 12 is running with the onboard video, page 16 is running with dedicated video
[02:24:24] <jepler> yes
[02:24:34] <jepler> bbiab
[02:24:41] <SWPadnos> ok
[02:28:46] <jmkasunich> hmm
[02:28:57] <jmkasunich> this fix to the parport driver brings up a question
[02:29:13] <SWPadnos> what kind of question?
[02:29:18] <jmkasunich> should the driver set _all_ the outputs to a known state when it is loaded?
[02:30:06] <SWPadnos> the port shouldn't be written to until HAL threads are started, IMO
[02:30:20] <SWPadnos> that is a programming problem though
[02:30:59] <jmkasunich> as jepler suggested, I'm reading the control port, setting the direction bit, and writing that value back out, that shouldn't affect any physical pins
[02:31:57] <SWPadnos> unfortunately, there's no way to know how to initialize the pins at driver load time
[02:32:02] <jmkasunich> right
[02:32:16] <jmkasunich> they are already gonna have some value, and if its wrong theres nothing you can do about it
[02:32:26] <SWPadnos> you could do it after the various -invert params are set (by assuming all unconnected pins should be 0)
[02:32:29] <SWPadnos> that's true
[02:32:31] <jmkasunich> so changing them at load time doesn't really help
[02:32:55] <jmkasunich> I think I'll leave well enough alone
[02:33:00] <SWPadnos> heh
[02:33:46] <SWPadnos> can the read() function just set the port to input, similar to the way the write() function does it? (ie, do the init once per port, from either read or write)
[02:34:02] <SWPadnos> but still after hal start
[02:35:09] <jmkasunich> I'd rather not - the readback, OR, and write back out approach risks changing a physical output if the readback is defective in some way
[02:35:44] <jmkasunich> and converting to input asap is IMO a good thing - the user might have a TTL chip out there fighting with the driver in the parport
[02:35:54] <SWPadnos> true
[02:39:27] <jmkasunich> I think that one counts as a bugfix, I'll backport it later
[02:39:40] <jmkasunich> I want to investigate something Jon noticed first
[02:39:52] <SWPadnos> the index thing
[02:39:54] <SWPadnos> ?
[02:40:05] <jmkasunich> if you interrupt a 'home to index' during the searching for index phase, it leaves index-enable turned on
[02:40:21] <SWPadnos> right - that one :)
[02:44:23] <jepler> jmkasunich: I agree that this change is a bugfix .. I'm not sure about the larger question
[02:44:42] <jmkasunich> I think SWPadnos convinced me to leave it as it is
[02:44:56] <jepler> for a backported bugfix, yes, I agree
[02:44:58] <SWPadnos> I did? :)
[02:45:04] <jmkasunich> the "initial values for outputs" thing that is
[02:45:22] <jepler> for 2.2 maybe we should do something about not only initial values for outputs, but a way to set known values at shutdown
[02:45:32] <SWPadnos> I'm not sure which is worse - random unchanged things or things (possibly) changed to a known state
[02:45:59] <jmkasunich> known values at shutdown interests me more than initial values
[02:45:59] <jepler> on the nist lathe, if I set the spindle to a medium speed and exit without doing a "machine off", the spindle may speed up to the maximum possible speed
[02:46:00] <SWPadnos> actually, the cfg sttring can have both init and exit values
[02:46:23] <jmkasunich> for the simple reason that there is not a damned thing we can do about the output state from PC power on until driver load
[02:46:25] <jepler> or it might stop, depending which way the PWM bit was at the time
[02:46:39] <jmkasunich> so a few more seconds until the HAL code starts running isn't likely to make a difference
[02:47:22] <jepler> jmkasunich: on the other hand, as this fellow discovered there are perfectly plausible reasons to run only the .read function, so all hardware must be set up properly no matter which subset of the functions will actually be added to threads
[02:47:42] <jepler> -> if there are multiple functions, this setup must be done in all of them, or in setup code
[02:47:55] <jmkasunich> yes, and that is the bugfix that I just added - the port direction will be done at module load time
[02:48:42] <jepler> for shutdown, I see as one possibility running a .hal file
[02:48:43] <SWPadnos> I suspect that bug was there due to excessive optimization
[02:48:58] <jepler> unlinkp parport.0.pin-02-out; setp parport.0.pin-02-out FALSE ...
[02:49:04] <jmkasunich> SWPadnos: naw, I just plain forgot
[02:49:10] <SWPadnos> heh :)
[02:49:55] <jmkasunich> jepler: so you are assuming an orderly shutdown (in order to be able to run the additional hal file)?
[02:50:00] <SWPadnos> don't forget "sets parport.0.pin-02-out-invert false"
[02:50:04] <jepler> jmkasunich: yes
[02:50:06] <jepler> SWPadnos: yes
[02:50:38] <jmkasunich> if its orderly, why don't we have some part of emc generate an estop as it shuts down
[02:50:45] <jepler> jmkasunich: it might not be enough for everyone, but the case that bites me is hitting alt+f4 to the axis window -- in which case that's fine too
[02:50:51] <SWPadnos> estop isn't the same as shutdown
[02:51:02] <SWPadnos> at least it shouldn't be forced to be
[02:51:31] <jepler> going to "machine off" would be good good for the nist lathe, and I think cradek's mill and the non-pluto servo lathe
[02:52:00] <jmkasunich> I'm thinking that there is at least one enable signal in hal that when false should put things in a safe state
[02:52:20] <jepler> it will stop the spindle, turn off the servo amps and stepper drivers, etc
[02:53:02] <jmkasunich> the way I see it, its the integrator's job to make sure that machine off (which kills the enable HAL signal(s)) makes the machine safe for shutdown
[02:53:17] <jmkasunich> and its our job to make sure that machine off is issued before the software stops running
[02:53:32] <jmkasunich> (I changed my mind, I agree that machine off makes more sense than estop)
[02:54:23] <SWPadnos> I suspect that the ideal place for that is in the driver unload code, since that's more likely to get a chance to run (regardless of how emc is stopped)
[02:54:42] <jmkasunich> but the driver unload code has no idea what is the right value
[02:54:53] <SWPadnos> well, that's the problem :)
[02:54:58] <SWPadnos> emc doesn't know either
[02:55:21] <jmkasunich> right - the machine integrator does, and he should have the hal enable signals connected where needed
[02:55:25] <SWPadnos> if emc can find out, then that information should be able to be passed into the driver
[02:55:36] <jmkasunich> for example, stepgen has an enable input, when it goes false, stepping stops
[02:55:45] <jmkasunich> pwmgen has one, when it goes false the output goes off
[02:55:56] <jmkasunich> PIDs have one, when it goes false the output goes to zero
[02:56:06] <SWPadnos> enable correctly sets up/down outputs both to 0, I assume
[02:56:10] <jmkasunich> yeah
[02:56:11] <SWPadnos> err - lack of enable ...
[02:56:22] <jmkasunich> (if not, its a pwmgen bug and should be fixed)
[02:56:29] <SWPadnos> ok
[02:57:30] <jepler> I'll look at what it would take to get something to issue a "machine off" when shutting down emc
[02:57:53] <SWPadnos> the run script could do it before unloading realtime
[02:58:17] <SWPadnos> a separate .hal file - that would be pretty good encapsulation as well
[02:58:22] <jmkasunich> I forst thought the GUI could issue it (killing the GUI starts the shutdown), but if you are running a remote or 2nd GUI, you want to be able to kill it without killing the machine I think
[02:58:41] <jepler> I was thinking that task could handle the shutdown signal that the run script sends it
[02:58:59] <jmkasunich> that makes more sense - task is the central dispatcher anyway
[02:59:06] <SWPadnos> true
[02:59:28] <jmkasunich> send the machine off command to the motion controller, and it will kill the enable HAL pins
[03:00:21] <SWPadnos> it would do a scripted set of tasks ...
[03:00:42] <SWPadnos> unless the drivers / signal generators all have a special "shutdown" hook
[03:00:55] <SWPadnos> (which seems to take it out of the integrator's hands)
[03:01:14] <jmkasunich> IMO the "scripted set of tasks" for shutdown is pretty much the same thing that should happen on machine off
[03:01:29] <jmkasunich> and the integrator should be taking responsibility for making that happen in the main hal file(s)
[03:01:43] <SWPadnos> not necessarily - large machines may have main contactors that get turned on once per day
[03:01:48] <jmkasunich> so why force him to build _another_ hal file with redundant stuff in it
[03:01:50] <SWPadnos> or that kind of thing
[03:02:23] <jmkasunich> thats why my initial thought was to force estop on shutdown
[03:02:38] <SWPadnos> startup/shutdown vs. active/inactive should be left to the integrator
[03:02:47] <SWPadnos> if it's the same thing, then their jkob is easier
[03:03:35] <jmkasunich> I guess my issue is with adding hooks and additional interconnect or config info to HAL
[03:03:57] <SWPadnos> eyah - I don't like that proposition either
[03:03:58] <jmkasunich> when you can (and probably already are) implementing startup and shutdown sequences already
[03:04:29] <jmkasunich> for example, the mazak uses a CL timer to close one contactor to charge the DC bus caps thru a resistor, then close another to bypass the resistor
[03:04:30] <SWPadnos> I think a SHUTDOWN=my_shutdown.hal solution is probably easiest to code, and most flexible
[03:04:34] <jmkasunich> that happens when you come out of estop
[03:05:52] <jmkasunich> I guess a SHUTDOWN=<filename> line in the [HAL] section of the ini file isn't too evil
[03:06:03] <jmkasunich> those (like me) who don't like it won't use it
[03:06:09] <SWPadnos> yeah, especially if it can be a script or a hal file or whatever
[03:06:12] <SWPadnos> exactly
[03:06:18] <SWPadnos> no changes unless you need the functionality
[03:09:45] <jepler> when executing "unlinkp x; setp x y" there's a time when x may have a value besides the old value and the new value
[03:10:25] <jmkasunich> yes, the unlink points the pin at its "dummy" signal
[03:10:37] <jmkasunich> IMO, doing an unlink on a running machine is NOT wise
[03:10:41] <SWPadnos> would it be detrimental to have the unlinkp function store the last connected signal value in the dummy signal?
[03:10:53] <jepler> then what will be in the shutdown.hal file?
[03:11:01] <SWPadnos> or is that supposed to always be 0-ish?
[03:11:12] <jmkasunich> SWPadnos: I kinda prefer zeroish
[03:11:13] <jepler> SWPadnos: it used to always be zero, but now it's the value of a 'setp <signal>'
[03:11:23] <jepler> I guess you unlinkp writer; sets signal newval
[03:11:22] <jmkasunich> jepler: I over-generalized
[03:11:35] <jmkasunich> I don't think you should unlink a input pin from the signal driving
[03:11:35] <jepler> then there's never an intermediate value
[03:11:38] <jmkasunich> driving it
[03:11:40] <SWPadnos> yeah - unlinking the writer is probably better
[03:11:47] <jmkasunich> instead, unlinkd the signal from the pin driving it
[03:12:02] <jmkasunich> the signal will retain its old value, until you sets it to a new value
[03:12:06] <SWPadnos> I know - how about disconnectiung the OUT pin?
[03:12:40] <jmkasunich> duh, I was typing instead of reading\
[03:12:48] <SWPadnos> heh :)
[03:12:58] <SWPadnos> now we've got 3 great minds thinking alike
[03:13:06] <SWPadnos> or at least 3 minds ...
[03:14:17] <jepler> hm this is hard to test on a "sim" machine
[03:14:44] <jmkasunich> what is? the shutdown stuff?
[03:14:48] <jepler> yes
[03:15:07] <jmkasunich> cd src
[03:15:12] <jepler> but you guys are now thinking that the emc-level "set machine to off" is *not* the way to go?
[03:15:25] <jmkasunich> I still prefer that approach
[03:15:45] <SWPadnos> I prefer the separate shutdown script/halfile approach
[03:16:00] <jmkasunich> but I can accept the existance of a "run a shutdown halfile (or script)" approach
[03:16:33] <jepler> my only worry is if a coding mistake ever makes exit make the state transition estop -> machine off or estop reset -> machine off
[03:17:02] <jmkasunich> IMO any machine with real risk can't rely on either, and needs some sort of hardware watchdog or charge pump thing or whatever to put the machine in a safe state when EMC goes away for _any_ reason
[03:17:36] <SWPadnos> in the run scriupt, there's a time after the main GUI has exited but before the other support apps have been killed, right? (ie, CL and the rest of HAL ...)
[03:17:46] <jmkasunich> including reasons that prevent the shutdown script, or machine off, or even all of HAL, from working
[03:17:59] <jmkasunich> SWPadnos: hard to say exactly how much tim
[03:18:01] <jmkasunich> time
[03:18:12] <SWPadnos> well, it's in the script, so there could be commands added there
[03:18:28] <SWPadnos> ie, execution of one or more shutdown scripts if they exist in the ini file
[03:18:31] <SWPadnos> or commands
[03:18:33] <jepler> my first stab at making emc go to machine off at exit (by changing task) looks like a failure so far
[03:18:43] <jepler> instead I just made task shut down uncleanly
[03:18:49] <SWPadnos> heh
[03:19:13] <SWPadnos> I'm not sure this has to be at the task level - it's more of an orderly "safe-ing: of the hardware
[03:19:27] <jmkasunich> exactly
[03:19:45] <jmkasunich> and for serious machines, the safeing itself needs to be done with hardware
[03:20:12] <SWPadnos> sure
[03:20:26] <jmkasunich> what happens if there is a kernel bug, or a bad memory chip, and you get a rock solid hard lockup, with even RT threads frozed
[03:20:43] <SWPadnos> that's outside the scope of "software shutdown procedures"
[03:20:51] <SWPadnos> :)
[03:20:51] <jmkasunich> while the DAC or FPGA pwmgen is commanding 75% output
[03:21:09] <jmkasunich> my point is that the integrator needs to plan for that case
[03:21:16] <SWPadnos> sure
[03:21:23] <jmkasunich> and the more common but less critical cases should use the same pathways, not invent new ones
[03:22:35] <jmkasunich> we have one path: user pushes the machine off (or estop) button, before shutting down EMC
[03:22:42] <jmkasunich> s/path/case
[03:22:51] <jmkasunich> we have the other extreme, the PC goes tits up
[03:23:12] <jmkasunich> seems like if the last case is handled, then everything else is too
[03:23:28] <SWPadnos> that depends
[03:23:53] <SWPadnos> the extreme case is one where you just want to make the machine safe, but you probably won't recover the wrokpiece
[03:23:58] <SWPadnos> it's an estop condition
[03:24:26] <SWPadnos> orderly shutdown is different (you might conceivably stop the machine for the night and want to continue machining in the morning)
[03:24:47] <jmkasunich> and exiting EMC while the spindle is spinning is an "orderly shutdown"?
[03:25:11] <SWPadnos> I didn't say that - the point is that the two are not necessarily identical conditions
[03:25:12] <jepler> when chris shuts down max, he issues a 'g28' (or something like that) so that it ends up at the machine origin again -- making it faster to start up next time
[03:25:14] <jmkasunich> if you want an orderly exit, hit machine off, then hit estop, then exit from EMC and optionally turn off the PC
[03:25:27] <jepler> it would be nice if "orderly shutdown" could include doing this automatically
[03:25:43] <SWPadnos> like I said - PC crash isn't the same as orderly shutdown ...
[03:26:07] <SWPadnos> sometimes you want to stop the machine, other times you need to Estop the machine - not the same thing
[03:26:11] <jmkasunich> ok, I've lost track of the case(s) we set out to deal with
[03:26:15] <jepler> from the user's POV, I don't want to remember more steps for an "orderly shutdown". I just want to hit alt+f4
[03:26:29] <SWPadnos> user exits from emc and wants some things to happen for them automatically
[03:26:31] <jmkasunich> I thought we were worried about the case where the user has a brain cramp and kills EMC while its running
[03:26:31] <jepler> maybe this is a toy machine vs real machine difference
[03:26:47] <jmkasunich> what is alt+F4?
[03:27:04] <jepler> the standard "close window" hotkey since win3.1 or longer
[03:27:10] <SWPadnos> they can be handled in the same way with a shutdown script (which can't deal with a PC crash)
[03:27:26] <jmkasunich> I think this is a toy vs. real issue
[03:28:09] <SWPadnos> for toys to medium sized machines, some user-defined set of functions at shutdown (like the HAL section executed at startup) is a good thing
[03:28:12] <jmkasunich> real, the EMC process(s) may keep running even overnight - you'll do machine off and maybe estop to make the machine safe, then go home
[03:28:16] <jmkasunich> you have no need or desire to kill EMC
[03:28:23] <SWPadnos> for big/real machines, there has to be hardware also
[03:28:55] <SWPadnos> (in which case the shutdown functionality may not be used since it's redundant)
[03:29:54] <jmkasunich> ok SWPadnos: in exactly what cases do you want to invoke this functionality
[03:29:59] <jmkasunich> it won't work for a crash
[03:30:00] <jmkasunich> it
[03:30:12] <jmkasunich> it's above and beyond what machine off or estop does
[03:30:54] <jmkasunich> it seems you're just adding an intermediate level for marginal benefit
[03:31:02] <SWPadnos> all it does is set hardware to a known state. if that's always equivalent to estop, then that's fine
[03:31:19] <jepler> I'm the one who brought "I'd like to do something extra" into the picture with the G28 example
[03:31:28] <jepler> I'm prepared to take that back
[03:31:42] <SWPadnos> well, I was thinking of that, but I'm not sure I'd want motion to happen automatically when exiting
[03:31:59] <SWPadnos> it could be a surprise
[03:32:28] <jmkasunich> especially if the reason you are exiting is that you had a machine crash and need to power everything down and get out the wrenches to fix it
[03:33:26] <jmkasunich> IMO on a real machine, a user hitting alt+F4 is not something that we need to strive to make work correclty, its something we need to prevent (by ignoring it if needed)
[03:33:59] <jmkasunich> for example - the Mazak has a power button on the front panel of the machine
[03:34:04] <jmkasunich> its wired to the mobo power button
[03:34:17] <jmkasunich> but there is a relay in there, and when estop is on, the power button is disconnected
[03:34:20] <jmkasunich> you _can
[03:34:38] <jmkasunich> _can't_ power down the PC when estop is on
[03:34:41] <jmkasunich> sorry, estop on is confusing
[03:34:52] <SWPadnos> I was just going to say ...
[03:34:54] <jmkasunich> what I mean is "the machine is out of the estop state and ready to run"
[03:34:59] <SWPadnos> when the machine could run
[03:35:01] <SWPadnos> ok
[03:35:19] <jmkasunich> we have a pair of contactors on the mazak that we labeled the master estop relays
[03:35:34] <jmkasunich> they are energized when everything is OK, out of estop, etc
[03:35:40] <jmkasunich> so "estop contactors on" means ready to run
[03:35:47] <jmkasunich> it bass-ackwards I know
[03:36:17] <SWPadnos> the way estop is used WRT emc is pretty strange, I'd say
[03:36:22] <jmkasunich> one of them switches the 120V AC used for the main contactor coils, hydraulic solenoid valves, etc
[03:36:36] <jmkasunich> the other switches the main 24VDC used for several other actuators and such
[03:37:53] <jmkasunich> this whole thing becomes an issue mostly for midrange machines
[03:38:05] <jmkasunich> true toys use steppers, and when you shut down, steps stop
[03:38:21] <jmkasunich> big machines have hardware estop chains and interlocks/watchdogs
[03:38:59] <jmkasunich> midrange machines might use software PWM or other servo things that can run away when the software stops executing and leaves an output set
[03:39:25] <SWPadnos> little servos driven from things like pluto and an H-bridge may get more popular though ...
[03:39:36] <SWPadnos> maybe jepler needs to make the pluto-servo config more robust :)
[03:39:55] <SWPadnos> (all outputs go to 0 if several ms pass by with no updates)
[03:40:03] <jmkasunich> a watchdog
[03:40:15] <skunkworks> some sort of charge pump would be nice
[03:40:20] <skunkworks> right
[03:40:38] <jmkasunich> if you trust the FPGA you can do the watchdog in there
[03:40:39] <jepler> yeah I thought about it but couldn't work out the details .. and then I used up the rest of my gates for something frivolous
[03:40:42] <jmkasunich> no additional hardware
[03:41:07] <SWPadnos> crap. I think mozilla will crash in a couple of minutes
[03:41:16] <jmkasunich> a charge pump is more robust, but the kind of folks who are using a pluto and a L298 aren't gonna want to mess with that
[03:41:17] <SWPadnos> when I close the Alamo car rental window :(
[03:43:42] <jmkasunich> jepler: your most recent change to halcmd (skip no pin nets, let save signal save them)...
[03:43:57] <jmkasunich> how does save signal know only to save the ones that have no pins connected?
[03:44:39] <jepler> jmkasunich: I added a flag to save_signals()
[03:44:43] <jepler> and it tests: if(only_unlinked && (sig->readers || sig->writers)) continue;
[03:44:47] <jepler> when you issue 'save sigu'
[03:45:12] <jmkasunich> oh... sigu is a new command that I didn't know about (thought it was a typo)
[03:45:22] <SWPadnos> sigunconnected?
[03:45:26] <jepler> 'net' can't save them, because you have to give a type to a signal with nothing connected
[03:45:29] <jepler> SWPadnos: yes
[03:50:13] <jepler> what's the distinction between a charge-pump and a watchdog? I thought a charge-pump was a specific kind of watchdog circuit, but I guess that must not be right
[03:50:24] <SWPadnos> that's mostly correct
[03:50:52] <SWPadnos> watchdog is anything that causes something to stop when it isn't "tickled" every so often
[03:51:00] <SWPadnos> a charge pump does that in a specific way
[04:11:13] <jmkasunich> jepler: a watchdog can be implemented in an FPGA for example, using a counter to count a clock, and resetting the counter when the software writes to a register
[04:11:37] <jmkasunich> if the counter ever reaches a value that corresponds to a few mS, then the FPGA resets its outputs to a safe state
[04:11:52] <jmkasunich> but that is only as reliable as the FPGA and the clock
[04:12:16] <jmkasunich> a charge pump is much simpler, thus more reliable
[04:12:53] <SWPadnos> technically, the charge pump output could get stuck high and hte cap could die as a short, but that's pretty unlikely :)
[04:37:20] <cradek> if a machine like the mazak heads for the limits at full speed, does estop on the limit switch really save it? seems limits are pretty close to the end of travel.
[04:37:43] <cradek> I guess if it brakes/shorts the motors maybe? coasting probably wouldn't help much?
[04:41:57] <SWPadnos> in theory there should be 3 sets of limit "switches", plus shock absorbers at the end stops
[04:42:38] <jmkasunich> if it was running full blast, it probably would ram into the physical stops pretty hard
[04:42:39] <SWPadnos> soft limits are first, followed by a "hey, this is wrong" limit switch (still used by software and/or drivers to decelerate the motor sanely), followed by hard limits that cause a panic abort (estop)
[04:43:04] <jmkasunich> yeah
[04:43:15] <jmkasunich> the mazak has five switches per axis
[04:43:20] <cradek> I know it should have several tries to stop if it's working right, but I wondered if the last chance hardwiring would actually save it
[04:43:23] <jmkasunich> one home, two limits, and two estops
[04:44:15] <jmkasunich> it will save it, for some value of save
[04:44:38] <jmkasunich> if only the difference between coasting into the hard stop at 200ipm vs. driving into it at 400ipm
[04:45:01] <SWPadnos> are there braking resistors / shorting contactors?
[04:45:08] <jmkasunich> not on the motors
[04:45:31] <SWPadnos> ah - the drives probably have some sort of braking load dump though
[04:45:34] <SWPadnos> ?
[04:45:40] <jmkasunich> the estop does drop a big resistor across the DC bus, and the freewheel diodes in the drives mean that once the bus voltage drops that resistor appears across the motors
[04:45:49] <SWPadnos> ok
[04:46:17] <jmkasunich> I don't recall the value of the big resistor, I doubt its low enough to give 1/10th second discharge
[04:46:28] <SWPadnos> indeed
[04:46:32] <jmkasunich> which is what you'd need to stop a full blast runaway
[04:46:38] <cradek> scary stuff
[04:46:52] <jmkasunich> I think we used either 4x or 6x2700uF caps, gotta discharge them first
[04:47:04] <SWPadnos> that's why the E is there in E-stop ...
[04:47:57] <jmkasunich> otoh, Z will stop pretty quickly
[04:48:03] <jmkasunich> it has a mechanical brake
[04:48:06] <cradek> I think 6 ohms makes RC=.1
[04:48:57] <cradek> and one time constant isn't anything like discharged...
[04:50:54] <jmkasunich> getting the bus down to 37% means the speed is down to 37% too though
[04:51:35] <cradek> what voltage is it?
[04:51:43] <SWPadnos> hmmm - I guess my 2x17000uF cap bank shuold be ok for a lowly bridgeport then :)
[04:51:51] <jmkasunich> 90V IIRC
[04:52:15] <cradek> ouch, that's a lot of watts
[04:52:19] <cradek> (not for long though)
[04:52:37] <jmkasunich> most wire-wound resistors can handle the peak watts
[04:52:43] <jmkasunich> especially low value resistors (fat wire)
[04:52:49] <jmkasunich> joules is the issue
[04:53:23] <jmkasunich> the other issue is what happens when a malfunction puts the resistor across the bus while power is still being applied to it
[04:53:53] <cradek> woo
[04:54:23] <jmkasunich> we had that happen with bus charging resistors
[04:54:45] <jmkasunich> similar application - intermittent duty resistors seeing continuous power
[04:54:55] <SWPadnos> toasters
[04:54:59] <cradek> did they just burn up?
[04:54:59] <jmkasunich> in this case, 6x 300W tubular wirewounds
[04:55:20] <SWPadnos> that's a good load test
[04:55:27] <jmkasunich> they burned the paint off the cabined they were in, and melted plastic parts of a contactor a few inches away
[04:55:31] <jmkasunich> cabinet
[04:55:45] <SWPadnos> it becomes a high power space heater at that point - ouch
[04:55:51] <jmkasunich> burn the hell out of the wiring harness too
[04:56:28] <jmkasunich> IIRC they were 10 ohms each and were wired in parallel
[04:56:40] <jmkasunich> probably had about 200V across them
[04:56:43] <SWPadnos> ouch
[04:56:47] <jmkasunich> 20A, 4000W
[04:56:50] <jmkasunich> each
[04:57:09] <SWPadnos> that's a lot of headroom
[04:57:22] <SWPadnos> (if they were able to melt all that stuff before sizzling open)
[04:58:31] <jmkasunich> they don't open until the resistance wire melts
[04:58:45] <jmkasunich> which is well into red heat, probably orange or yellow
[04:58:58] <SWPadnos> hmmm - true. close to white even
[04:59:18] <jmkasunich> these were the traditional brown tubulars
[04:59:33] <jmkasunich> the brown coating melted and dripped off, the white tubes held up fine
[04:59:52] <SWPadnos> well, from that I guess I shouldn't worry about the 220W 6.8 ohm I've got for my load dump
[05:00:21] <jmkasunich> we've since switched to a thick film resistor, still rated at 300W, it fails much more benignly
[05:00:54] <SWPadnos> interesting to have to design around the failure modes of the components
[05:01:03] <SWPadnos> normal in high power stuff though
[05:01:08] <jmkasunich> yep
[05:02:14] <jmkasunich> brain fart - I know I have the xilinx software installed here, but I can't remember what its called
[05:02:22] <jmkasunich> and of course there are no man pages
[05:02:32] <SWPadnos> ise foundation
[05:02:34] <jmkasunich> at least not that "apropos xilinx" or "apropos fpga" can find
[05:02:51] <SWPadnos> I don't know what the Linux executables are called
[05:03:44] <SWPadnos> synplicity (or symplicity) ?
[05:05:25] <SWPadnos> or are you looking for the schematic layout-like thing?
[05:05:46] <jmkasunich> no just the main gui thing
[05:05:54] <SWPadnos> hmmm - "
[05:06:03] <SWPadnos> "Project Navigator" in the Windows menu :)
[05:06:05] <jmkasunich> duh, I downloaded manuals
[05:06:19] <jmkasunich> * jmkasunich rt's the fm
[05:06:24] <SWPadnos> heh
[05:07:30] <SWPadnos> it's entirely possible that it's called pn
[05:08:25] <SWPadnos> hey - the seller still has those resistors in stock
[05:28:28] <jmkasunich> we're gonna have to add some more files to CVS for this FPGA stuff
[05:28:37] <jmkasunich> pinout files, and other xilinx files
[05:30:17] <SWPadnos> yep
[05:31:04] <SWPadnos> I'm not sure if each config shuld have its own hal module
[05:31:17] <jmkasunich> I hope not
[05:31:21] <SWPadnos> that may be the simplest approach for now (since each can have the config hard-coded)
[05:31:45] <SWPadnos> it'll be necessary in certain cases, but I hope it's kept to a minimum
[05:37:30] <SWPadnos> I wonder if it's stupid to use the existing FPGA loader plus some scripting shenanigans to switch between configs
[05:37:49] <jmkasunich> compared to what?
[05:38:17] <SWPadnos> implementing something that lets a driver load a config from a load-time-specified file
[05:38:35] <SWPadnos> it's the age old "files from RT modules" problem
[05:39:08] <jmkasunich> yeah
[05:40:31] <SWPadnos> the firmware loader functions may be useful, but I think they only allow for one firmware version (that may not be true), and they also only work with hotplug, I think
[05:41:11] <SWPadnos> I found an example of a driver loading its own firmware, but the example was marked "don't do this, use get_firmware instead" (or whatever the function is)
[05:41:43] <jmkasunich> the loader that is in the existing driver uses a config that was embedded in the source
[05:41:55] <jmkasunich> (as a huge initialized array in a .h file)
[05:41:56] <SWPadnos> right, and that requires a different driver for each config
[05:42:08] <jmkasunich> well, you could cheat
[05:42:17] <SWPadnos> sure, and have a very very large driver :)
[05:42:56] <jmkasunich> you could have a series of kernel modules that are nothing but the big array, with skeleton init_module and cleanup_module functions
[05:43:04] <jmkasunich> load one of them, then load the driver
[05:43:10] <SWPadnos> yeah
[05:43:32] <SWPadnos> though the register map will likely change (as will the functionality) between configs, so separate drivers may actually be a good idea
[05:43:34] <jmkasunich> still crufty, for several reasons
[05:45:23] <jmkasunich> if we have some finite and managable number of different "things" (pwmgen, stepgen, ADC, DAC, serial I/O expander, etc, etc) then we could probably use a single driver
[05:45:42] <jmkasunich> the PCI address space is not small
[05:46:14] <SWPadnos> yep. though I've had thoughts of classic ladder (parts anyway) and the softDMC processor ...
[05:46:40] <jmkasunich> you mean the ladder engine?
[05:46:57] <SWPadnos> yep
[05:47:05] <SWPadnos> the rung evaluator or a subset of it
[05:47:24] <jmkasunich> the engine would have to directly (no HAL) connect to the 5i20 I/O for that to make any sense
[05:47:32] <SWPadnos> yep
[05:47:52] <SWPadnos> but timers could be much faster and higher precision, and the loop rate could be way higher
[05:48:05] <jmkasunich> yeah
[05:48:07] <SWPadnos> I'm not sure where that's helpful, but I was thinking about it :)
[05:48:17] <jmkasunich> that version would definitely be a unique driver/config
[05:48:42] <jmkasunich> what I'm thinking about right now is maybe 5-10 types of I/O
[05:48:46] <jmkasunich> steps, pwm, etc
[05:48:53] <SWPadnos> there's always the option of a separate driver, so trying to make a "unified" approach doesn't prevent that
[05:49:41] <jmkasunich> and the ability to say "I want N of this, and M of that, and X of the other", build a config, then have the driver read N, M, and X from a register in the device and export the corresponding HAL pins
[05:50:13] <SWPadnos> right - some kind of enumeration of what's in there, from some well-defined set of options
[05:51:06] <jmkasunich> in my daydreaming the other day, I even thought of having the top level vhd file being created by a script
[05:51:24] <jmkasunich> tell the script what N, M, and X are, and it generates the vhd code
[05:51:36] <SWPadnos> well, let me know how long it takes to process the current mesa config :)
[05:51:48] <jmkasunich> ?
[05:51:59] <jmkasunich> I don't expect that the average joe will change N, M, or X
[05:52:02] <SWPadnos> you'd have to re-place+route the config
[05:52:09] <jmkasunich> cause he won't have the tools
[05:52:26] <SWPadnos> I suspect that process takes longer than a full make after make clean (by a factor of 2 or 3)
[05:52:33] <jmkasunich> yeah
[05:52:41] <SWPadnos> for one config ...
[05:52:50] <jmkasunich> I didn't mean that we'd redo that all the time
[05:53:01] <SWPadnos> like the docs, I guess
[05:53:08] <jmkasunich> not even...
[05:53:38] <SWPadnos> ie, not built by default ...
[05:53:58] <jmkasunich> when somebody generates a new config, they would commit the script input (N,M,X,etc), the new top level vhd file, the bitfile, and the .h file containing the initialized array
[05:54:17] <jmkasunich> the config would never again need to be placed and routed
[05:54:47] <jmkasunich> I'm not sure place and route is deterministic, I wouldn't want to redo it anyway, unless I was sure I could get the same bitfile
[05:54:48] <SWPadnos> true
[05:55:00] <SWPadnos> yeah - that's one of the things that makes me nervous
[05:55:27] <jmkasunich> I just thought of an advantage of the "module with nothing in it but an array" approach
[05:55:31] <jmkasunich> there can be two arrays
[05:55:39] <jmkasunich> one is big, and has the bitfile
[05:55:47] <jmkasunich> the other is small, and contains the enumeration onfo
[05:55:48] <SWPadnos> the other is the config info
[05:55:48] <jmkasunich> info
[05:55:51] <SWPadnos> yep
[05:56:02] <jmkasunich> instead of wasting fpga resources on read once registers
[05:56:31] <SWPadnos> that should be in the config f the FPGA though - you shouldn't have to reprogram it every time
[05:57:09] <jmkasunich> oh, you would put the info into registers?
[05:57:10] <SWPadnos> loading a few constants from some RAM blocks shouldn't take too much of the FPGA fabric
[05:57:15] <SWPadnos> yes
[05:57:55] <jmkasunich> I suppose that is cleaner
[05:58:12] <jmkasunich> I'm still not used to having tons of gates, I consider them a scarce resource
[05:58:11] <SWPadnos> with 16 types of I/O (and <256 of each), you can specify all of that in 4 words
[05:58:37] <SWPadnos> heh - they will be one day, but as usual, there are tradeoffs (ease of use vs. gates)
[05:58:54] <jmkasunich> since CLBs can be a 16 deep x 1 wide memory, 8 CLBs could give us those 16 eight bit values
[05:58:58] <SWPadnos> you know the functionality of the G-Rex, right?
[05:59:10] <jmkasunich> I've been out of the loop for a while
[05:59:25] <SWPadnos> 6x step/dir + 6x encoder inputs + I/O + analog + white heat processor
[05:59:34] <SWPadnos> all that fits into a 50k spartan 2
[05:59:59] <SWPadnos> white heat including a 1.5kword program space + some data space
[06:00:20] <jmkasunich> old habits die hard, but I'll try to keep that in mind
[06:00:44] <SWPadnos> one of the standard Mesa configs has a DSP with full PID + FF for 8 axes
[06:01:09] <jmkasunich> ok, config data in FPGA ROM blocks (ram with no write access)
[06:01:13] <SWPadnos> I'll be interested in seeing how much space the actual functions take (once all the bus interface stuff is there)
[06:01:23] <jmkasunich> maybe 16 values each 8 bits wide, or something along those lines
[06:01:29] <SWPadnos> right - like the ID registers are noe (in the new configs)
[06:01:55] <SWPadnos> yep, as long as the order of the functions can be fixed
[06:02:02] <jmkasunich> I wonder how big the PCI address space is?
[06:02:08] <SWPadnos> 4G
[06:02:09] <SWPadnos> :)
[06:02:19] <jmkasunich> I mean the part thats mapped to the 5i20 FPGA
[06:02:27] <SWPadnos> I'm not sure how many words the PLX chip gives you
[06:03:00] <jmkasunich> suppose an encoder counter is 4 32 bit registers (some might be narrower, but thats irrelevent)
[06:03:17] <SWPadnos> why 4 registers?
[06:03:36] <SWPadnos> (curiosity)
[06:03:45] <jmkasunich> a guess
[06:03:48] <jmkasunich> raw count
[06:03:52] <jmkasunich> control/status
[06:03:57] <jmkasunich> maybe a captured index count, maybe not
[06:04:04] <SWPadnos> ok - close enough
[06:04:18] <jmkasunich> and I'd like a timestamp (time in FPGA clocks of the last count)
[06:04:35] <jmkasunich> the timestamp lets you generate _much_ better velocity information
[06:05:07] <SWPadnos> actually, the FPGA can have a velocity register calculated at the higher clock rate
[06:05:22] <jmkasunich> anyway, the max number of encoders is 32 (that would require 64 inputs even without indexes, and we only have 72 total)
[06:05:43] <jmkasunich> digression: velocity = distance over time
[06:06:00] <jmkasunich> fpga's aren't the best place to do division IMHO
[06:06:03] <SWPadnos> true enough
[06:06:19] <jmkasunich> the timestamp is the value of a fast counter (maybe 33MHz, or whatever other fast clock there is)
[06:06:30] <SWPadnos> 100 MHz at this point
[06:06:52] <jmkasunich> on each encoder count, the count register is incremented or decremented, and the timestamp register is loaded with a snapshot of the fast counter
[06:07:17] <SWPadnos> sure - you get a high res period between edges
[06:07:48] <jmkasunich> so if the last read (every mS) says 1234 counts, last count at t=1232351nS, and the next read is 1245 counts, last count at t=12546674nS
[06:08:00] <jmkasunich> you know exactly how long those 11 counts took
[06:08:18] <SWPadnos> yep
[06:08:52] <SWPadnos> I'm not sure what the highest attainable clock rate is (for a 32-bit counter), but it's got to be at least 100 MHz :)
[06:09:03] <jmkasunich> no desire to go _that_ fast
[06:09:18] <jmkasunich> even 1uS timestamp resolution would be great
[06:09:56] <jmkasunich> neither the timestamp nor the count needs to be a full 32 bits either
[06:10:06] <jmkasunich> as long as neither one can overflow between samples
[06:10:25] <jmkasunich> I'd design for maybe 100Hz sampling, 10x slower than we normally do
[06:10:30] <SWPadnos> don't optimize gate usage yet ;)
[06:10:57] <jmkasunich> a 16 bit count can handle 6.5MHz at 100Hz
[06:11:12] <jmkasunich> well, it would be nice if the count and timestamp fit in one 32 bit read
[06:11:14] <SWPadnos> there are 12-axis versions of the Mesa config, so there has to be a fair amount of room in there
[06:11:36] <SWPadnos> or the read of the count latches the last timestamp in to the readable register
[06:11:41] <SWPadnos> the maintain sync
[06:11:42] <jmkasunich> eliminates a lot of complex (tricky) logic that would otherwise be needed to ensure the stamp and count are matched up
[06:12:02] <jmkasunich> anyway, enough digression
[06:12:08] <SWPadnos> I don't think it's that tricky
[06:12:08] <SWPadnos> ok
[06:12:09] <jmkasunich> my point was this
[06:12:18] <jmkasunich> 4 registers per encoder
[06:12:21] <jmkasunich> 32 encoders max
[06:12:34] <jmkasunich> 128 words, 512 bytes, of address space
[06:12:49] <jmkasunich> so dedicate that much address space to encoders, even if you don't have any
[06:12:57] <SWPadnos> ah
[06:13:01] <jmkasunich> the next 512byte block is pwmgens, even if you don't have any
[06:13:01] <jmkasunich> etc
[06:13:15] <SWPadnos> that may be too much, but we'll have to see
[06:13:20] <jmkasunich> 16 types of I/O, each with 512 bytes of address space dedicated, is 8K
[06:13:36] <SWPadnos> I suspect that the total address space is in the low kbyte range
[06:13:40] <SWPadnos> so it may fit
[06:13:58] <jmkasunich> ISTR it was more than that, checking
[06:14:46] <jmkasunich> bus space 5, MEM, width 32 bits, range 64K bytes, 16K longs
[06:15:05] <SWPadnos> ok - that's plenty then
[06:15:25] <jmkasunich> by always having each type of device in its own address block, the driver is simpler
[06:15:38] <jmkasunich> all it needs to know is how many there are
[06:15:50] <jmkasunich> and it gets that from the config rom
[06:17:09] <SWPadnos> where was that address range comment?
[06:17:21] <jmkasunich> http://www.mesanet.com/pdf/parallel/5i20man.pdf
[06:17:22] <jmkasunich> page 8
[06:17:35] <SWPadnos> ah - silly me, looking at the source
[06:18:27] <SWPadnos> that's probably a function of the PCI interface chip anyway, which may explain why I couldn't find it
[06:18:36] <jmkasunich> it is
[06:18:37] <SWPadnos> (or the fact that I'm not too good with VHDL)
[06:18:46] <jmkasunich> that is configurable too, but not easily
[06:18:58] <jmkasunich> there is a serial EEPROM on the board that configs the PCI chip
[06:19:06] <SWPadnos> right - you have to use JTAG to the board or something
[06:19:21] <jmkasunich> I'm not sure
[06:19:39] <jmkasunich> there are two 128 byt spaces mapped to the PXL9030 configuration registers
[06:20:06] <SWPadnos> it'll be interesting to see what happens when I plug in more than one board
[06:20:14] <jmkasunich> anyway, I certainly don't want to mess with the PCI chip
[06:20:31] <SWPadnos> no
[06:21:10] <jmkasunich> but with 16K 32-bit locations and another 32K 16-bit locations, address map space isn't going to be an issue
[06:22:49] <jmkasunich> we could have 32 kinds of "things", with 0 to 31 of each thing, and allow 16 32-bit registers for each one, plus 16 registers that are common to all instances of a thing
[06:23:50] <jmkasunich> and the only config info we need to store is 32 5-bit numbers
[06:23:51] <SWPadnos> hmmm -they mention the config disk, but I didn't get any
[06:23:55] <jmkasunich> quantityt of each thing
[06:24:06] <SWPadnos> err - distribution disk
[06:24:18] <jmkasunich> bet its all downloadable from the web
[06:24:29] <jmkasunich> if not, peter can send it to us
[06:24:31] <SWPadnos> there are 3 downloads, from what I remember
[06:24:34] <SWPadnos> yep
[06:25:54] <jmkasunich> lets get back to handling the configs
[06:26:09] <SWPadnos> at load time or compile time?
[06:26:17] <jmkasunich> we can use a user space loader (if all the enumeration info is embedded in the fpga)
[06:26:34] <jmkasunich> we can use a kernel module containing the bitfile in an array and load from the driver
[06:26:50] <jmkasunich> we can embed the bitfile in the driver (and have lots of drivers)
[06:27:00] <jmkasunich> any other variations?
[06:27:51] <SWPadnos> is the userspace loader the same as "firmware file loaded from disk by the driver" option?
[06:28:03] <jmkasunich> I think so
[06:28:07] <SWPadnos> ie, something like the get_firmware option
[06:28:09] <SWPadnos> ok
[06:28:22] <jmkasunich> A utility program SC5I20.EXE is provided to send configuration files to the 5I20.
[06:28:23] <jmkasunich> SC5I20 is usable under DOS and Windows 9X where direct I/O access to the 5I20 card
[06:28:23] <jmkasunich> is available. The Pascal and C source for this program is available on the distribution
[06:28:23] <jmkasunich> disk, and can be used as an example for writing a custom version of download software.
[06:28:23] <jmkasunich> The C source can also be compiled under Linux. SC5I20 is invoked with the FPGA
[06:28:23] <jmkasunich> configuration file and the 5I20 configuration base address on the command line:
[06:28:25] <jmkasunich> SC5I20 FPGAFILE.BIN
[06:28:39] <jmkasunich> thats simple user space
[06:28:57] <SWPadnos> yep - that program is in cvs, and it's what creates the header files if invoked without a card number to configure
[06:29:15] <jmkasunich> ok, the header stuff must be PeteV's addition
[06:29:24] <SWPadnos> could be
[06:29:55] <jmkasunich> from a usage point of view, the nicest would be if you could say "loadrt hal_5i20 config=foobar"
[06:30:02] <SWPadnos> yep
[06:30:06] <jmkasunich> but I don't see how to do that
[06:30:18] <jmkasunich> unless all the configs were embedded in the driver, which is insane
[06:30:32] <jmkasunich> memory is cheap, but not that cheap, especially in kernel space
[06:30:33] <SWPadnos> actually, it may be easier for an integrator to say "loadrt m5i20_foobar"
[06:30:51] <jmkasunich> that means a crapload of .ko modules
[06:30:56] <jmkasunich> maybe not a big deal
[06:31:10] <SWPadnos> you should be able to mark the data as initdata, so it would be freed once the driver init is done
[06:31:28] <jmkasunich> gets interesting when you want to load two boards, especially with two differnet configs
[06:32:03] <SWPadnos> well, there you get into issues with function naming and stuff
[06:32:38] <jmkasunich> yeah
[06:32:52] <jmkasunich> and the generic driver code is completely reusable anyway
[06:33:18] <jmkasunich> I hate the thought of trying to make it all work, but...
[06:33:26] <jmkasunich> modprobe could deal with this
[06:33:26] <SWPadnos> this is a good application of the load being separate from the instances
[06:33:40] <jmkasunich> make the individual "drivers" contain next to no code, just the bitfile
[06:33:43] <SWPadnos> modprobe only works for intalled modules
[06:33:45] <jmkasunich> and have them all depend on the real driver
[06:33:50] <SWPadnos> sure
[06:34:34] <jmkasunich> like I said, I hate the idea of trying to work with modprobe
[06:34:41] <jmkasunich> and I consider run-in-place very important
[06:34:48] <jmkasunich> so that won't work
[06:35:14] <jmkasunich> but perhaps the idea of loading the driver first, then the config "module" might be ok
[06:35:43] <jmkasunich> heck, you could unload the config module once the FPGA is configured
[06:35:52] <jmkasunich> that would solve the "can't load the same one twice" problem
[06:35:57] <jmkasunich> loadrt hal_5i20
[06:36:07] <jmkasunich> loadrt 5i20_foo slot=1
[06:36:17] <jmkasunich> (or whatever way we use to identify a board)
[06:36:18] <SWPadnos> I'd go the other way
[06:36:25] <SWPadnos> config the board first, then load the driver ...
[06:36:24] <jmkasunich> loadrt 5i20_bar slot=2
[06:36:39] <SWPadnos> oops - config the board(s) first ...
[06:36:39] <jmkasunich> maybe
[06:36:53] <SWPadnos> if you do it the other way, the driver doesn't know what resources will be there
[06:37:47] <jmkasunich> the driver could contain the "write config to board" functions, and the "init_module()" in 5i20_foo would invoke that function first, passing the address of the bitfile array, then it would invoke the code that reads the config from the fpga and exports hal pins
[06:38:03] <jmkasunich> the driver module's init_module() would be a stub
[06:39:08] <jmkasunich> either way could work
[06:39:25] <jmkasunich> loading the driver first means you don't have to tell it what slot(s) to read
[06:39:38] <SWPadnos> the word "driver" is a bit overloaded here ...
[06:40:16] <SWPadnos> there's a loader module that configs the board, and a HAL driver to make it do stuff
[06:40:19] <jmkasunich> driver = the module with the realtime code that accesses the FPGA (HAL functions) and the code that reads the config ROM in the fpga, and exports the HAL pins
[06:40:42] <jmkasunich> config = the module that contains the bitfile and a very small amount of executable code
[06:40:48] <SWPadnos> ah - you've got a unified loader/HAL driver there
[06:40:53] <jmkasunich> no
[06:41:07] <SWPadnos> and a separate "config module"
[06:41:15] <jmkasunich> yes
[06:41:21] <jmkasunich> sorry ;-)
[06:41:33] <jmkasunich> the loader isn't very big
[06:41:43] <jmkasunich> it could either be part of the driver, or part of the config module
[06:41:53] <SWPadnos> I guess the easiest way to do this is to use two halcmd lines if you want to guarantee a particular config for a specific card:
[06:42:06] <SWPadnos> halcmd loadusr SC5I20 myconfig
[06:42:07] <jmkasunich> I guess if you're gonna immediately unload the config module might as well put the loader in there
[06:42:20] <SWPadnos> halcmd loadrt hal_appropriatedriver
[06:42:31] <jmkasunich> yeah
[06:42:34] <SWPadnos> you might as well use the esixting ptrogrammer
[06:42:52] <jmkasunich> where hopefully appropriate_driver = the same for all but the most specialized configs
[06:43:01] <SWPadnos> if it's one halcmd line, that's good, but if it's two, there's no sense reinventing that wheel
[06:43:06] <SWPadnos> sure
[06:43:16] <jmkasunich> both the loadusr and the loadrt would need to accept some kind of slot ID or something like that
[06:43:36] <SWPadnos> the downloader app already does
[06:43:39] <jmkasunich> actually the driver can only be loaded once, so it needs to accept a list of slots
[06:43:56] <SWPadnos> right, though obviously not so for the configurator
[06:44:00] <SWPadnos> (in userspace)
[06:44:07] <jmkasunich> right
[06:44:21] <jmkasunich> run the configuator N times passing a different slot number each time
[06:44:32] <jmkasunich> then run the driver, passing all the slot numbers
[06:44:43] <SWPadnos> yep
[06:47:53] <jmkasunich> for this to work, we need to have some standardized on-chip busses and address decoding
[06:48:15] <jmkasunich> I think mesa already has something like that
[06:48:28] <jmkasunich> although it could be documented better
[06:48:33] <SWPadnos> yep. this will only work for "modules" that are attached to the same ibus/obus structures that are already there
[06:48:53] <SWPadnos> yes, there's an address bus and data decoding (though I'm not sure exactly where the latter is)
[06:49:10] <SWPadnos> also some read/write register blocks
[06:49:45] <SWPadnos> word24rb and wordpr24, I think
[06:50:36] <jmkasunich> dang - for some reason, when I resume the BDI-4.51 VM, it starts with the correct time, but when I resume the ubuntu ones, they don't
[06:50:48] <SWPadnos> bummer
[06:50:54] <jmkasunich> those word things are the digital I/O I believe
[06:51:07] <SWPadnos> there is a note on synchronizing clocks on guest OSes
[06:51:14] <SWPadnos> true - they're 24 bits
[06:51:16] <jmkasunich> yeah, I read it a while back
[06:51:37] <jmkasunich> its getting late - I resumed the VMs as the first step in going to bed
[06:51:44] <jmkasunich> but...
[06:52:03] <SWPadnos> hmmm - there's only an 8-bit data bus at this point
[06:52:07] <SWPadnos> err - address bus
[06:52:10] <jmkasunich> we've talked about enumerating the "things" that we're gonna put in the fpga
[06:52:17] <jmkasunich> I'm sure the bus can be widened
[06:52:25] <SWPadnos> true, but the logic cost :)
[06:52:31] <jmkasunich> actually it could be split
[06:52:47] <SWPadnos> no banking!!!!!
[06:52:50] <jmkasunich> decode the top few bits as "thing type" and pass a strobe to the thing
[06:52:58] <SWPadnos> ok - that can work
[06:53:02] <jmkasunich> decode the next few bits as "thing instance" inside the thing
[06:53:21] <jmkasunich> and the final few bits are the registers inside each instance
[06:54:05] <jmkasunich> anyway, where I was going next is mapping thing I/O to the 3 connectors
[06:54:45] <SWPadnos> that's a tough one I think
[06:54:57] <jmkasunich> you _could_ do that with pinout files and customise those as needed
[06:55:19] <jmkasunich> but I'd be inclined to define signals called J1-1 thru J1-24, J2-1, etc
[06:55:29] <jmkasunich> use only one pin file
[06:56:07] <SWPadnos> I think there's something similar now - IOBITSA and IOBITSB
[06:56:09] <jmkasunich> and in the top level file (the same one that says to have N instance of thing A and M instances of thing B) you say thingA.2 output 1 goes to J1.21
[06:56:51] <SWPadnos> that's not perfect, because every second pin is ground (so you don't get the pin number association)
[06:57:20] <jmkasunich> the J<n>-<m> scheme would be chosen to make sense
[06:57:41] <jmkasunich> whether that means using 1-24, or 1-49 (every other one)
[06:58:25] <SWPadnos> pin associationis a whole other topic, and you're right - it's bedtime :)
[06:58:34] <jmkasunich> goodnight
[06:58:41] <SWPadnos> good night. see you today (probably) :)
[09:26:39] <lerneaen_hydra_> lerneaen_hydra_ is now known as lerneaen_hydra
[23:28:24] <jepler> jmkasunich: any idea why the breezy systems aren't sending e-mail when they fail? they started failing back on 12-31 and I haven't heard a peep about it on irc or on the mailing lists
[23:28:41] <jmkasunich> hmm
[23:28:43] <jmkasunich> no clue
[23:30:40] <jmkasunich> damned VMs are having bitrot
[23:30:59] <jmkasunich> I know I installed vmware tools, it says they aren't there
[23:31:19] <jmkasunich> and I know that the libs needed for esmtp were working, no it cant' find em
[23:32:52] <jepler> huh
[23:32:53] <jmkasunich> s/no/now/
[23:38:58] <jmk-vm03> esmtp: error while loading shared libraries: libesmtp.so.5: cannot open shared object file: No such file or director
[23:39:25] <jmk-vm03> I'm dumb about .so stuff
[23:44:41] <jmkasunich> jepler: I'm going to have to leave soon... can you help me figure out this lib thing?
[23:45:03] <jmkasunich> isn't there something that tells you about installed shared libs?
[23:45:18] <jmkasunich> (apropos didn't help, and the VM is dog slow right now because its doing another build)
[23:46:30] <jmkasunich> never mind, I gotta go
[23:46:38] <jmkasunich> I'll be back around 10ish EST
