#emc-devel | Logs for 2007-12-18

[01:18:49] <jepler> I finally got ise9 installed .. I can't verify that it works, but I can verify that the 7i43 firmware does rebuild from only the files in CVS
[01:22:49] <cradek> very slick
[01:23:02] <skunkworks> this is the pluto replacement?
[01:24:33] <skunkworks> looks like it is
[01:25:05] <jepler> well .. right now it's only for dumb I/O .. but you get 24 of each with the contributed HAL driver
[01:25:32] <jepler> I think that with the new firmware peterw has promised, it will get encoder+pwm, like the existing mesa driver
[01:26:55] <jepler> I hope that seb will contribute a driver for that too
[01:51:15] <cradek> he said he intends to
[02:00:30] <SWPadnos> it may make sense to do something like the USC driver does - make an array to transfer to/from the deivce, then use whatever bus features let you do that most efficiently
[02:00:38] <SWPadnos> like burst transfers on PCI
[02:01:00] <SWPadnos> the register set (for each FPGA function) will likely be the same
[02:10:59] <jepler> if you think you know the relative costs of an address cycle vs a data cycle of each size ..
[02:15:03] <SWPadnos> well, the way the USC driver does it is to have each function (read/write) "register" itself, and the communications code just keeps a list of the regions needed
[02:15:35] <SWPadnos> I'm not sure how it decides, but I think if there's a gap of <3 bytes, it just ignores it and continues the burst
[02:16:29] <SWPadnos> if the embedded PCs I have are any indication, individual PCI acceses cab be slow as hell - just about as bad as a parport cycle (but 32 bits)
[02:16:36] <SWPadnos> s/cab/can/
[02:36:55] <jepler> in pluto I just always update all registers, I don't track whether they've changed since last time
[02:37:17] <jepler> I figure in a normal system, the PWM values will change nearly all the time
[02:37:26] <SWPadnos> no, the USC doesn't do that either
[02:38:02] <jepler> also all the addresses to update are contiguous
[02:38:17] <SWPadnos> but the encoder read function needs addresses 0-11 say, and the digital read needs 14 and 15, so they tell the I/O code that, and it populates a memory array
[02:38:22] <SWPadnos> right, that's helpful
[02:38:40] <SWPadnos> but if someone doesn't use one function, you don't necessarily need to touch all the registers
[02:38:55] <SWPadnos> (like they use only I/O, no PWMgens)
[02:39:01] <SWPadnos> or the other way around
[02:39:09] <jepler> I also lumped everything into one function. Having it in two functions is bad for epp, since you can't know if another thread has interrupted and changed the address register
[02:39:14] <SWPadnos> heh
[02:39:38] <SWPadnos> it's more important for the USC, since there could be 256 registers to read/write
[02:39:51] <SWPadnos> or some subset, spread around the address space
[02:40:25] <jepler> clearly more complicated than what I had
[02:40:38] <SWPadnos> yep
[02:41:25] <SWPadnos> but the mesa code kind of cries out for a split between the bus and the functions, since the functions in the FPGA have identical register sets regardless of the card/interface used
[03:38:39] <tomp1> can i monitor a python variable during run time with some python ide?
[03:39:14] <cradek> tomp1: I have not used any of those
[03:39:29] <tomp1> any hints on how to monitor a variable?
[03:39:40] <tomp1> (or lotsa 'print' )
[03:39:43] <cradek> I only know how to use print
[03:39:48] <tomp1> k, thx
[03:39:54] <cradek> but it feels pretty primitive
[03:40:05] <tomp1> :)
[04:16:15] <jmkasunich> dang - why is it that I always need 7 inverters?
[04:18:18] <jmkasunich> hah, redesigned the charge pump - better mosfet drive AND two fewer inverters
[04:18:22] <jmkasunich> damn I'm good
[04:18:56] <cradek> charge pump on stepper machine?
[04:19:15] <jmkasunich> yeah
[04:19:20] <jmkasunich> maybe overkill, maybe not
[04:19:44] <jmkasunich> if the servo thread dies and the base thread doesn't, it will keep sending step pulses forever
[04:20:17] <cradek> that seems like an unlikely failure
[04:20:56] <SWPadnos> especially because the charge pump funciton would be in the base thread with the step generator
[04:21:00] <jmkasunich> the only thing that would cause it is a bug, like a null pointer or somethhing
[04:21:03] <cradek> I figured out how to hook up my vfd thanks to a passing comment in the other channel
[04:21:10] <jmkasunich> SWPadnos: the charge pump will be wherever I put it
[04:21:17] <SWPadnos> heh
[04:21:27] <cradek> fwd/rev can just come from the existing contactors
[04:21:40] <jmkasunich> huh?
[04:21:43] <SWPadnos> extra contacts
[04:21:47] <cradek> fault from the vfd will break the limit switch chain
[04:22:23] <cradek> it switches the 3ph. I'll just take all that out and use the crazy big relay to switch the vfd logic level
[04:22:27] <jmkasunich> you aren't gonna switch power with the contactors are you?
[04:22:31] <cradek> no
[04:22:42] <jmkasunich> I think you'll regret doing that
[04:22:53] <cradek> won't work for long?
[04:22:54] <jmkasunich> power contacts aren't designed to switch low voltage
[04:22:59] <cradek> yeah I know
[04:23:04] <jmkasunich> especially if the power contacts have been previously used for power
[04:23:11] <cradek> hmm
[04:23:28] <jmkasunich> why not just produce a signed analog reference for the vfg
[04:23:30] <jmkasunich> vfd
[04:23:31] <cradek> I guess I only need a 24v relay
[04:23:45] <cradek> how?
[04:23:50] <cradek> err two relays
[04:23:59] <jmkasunich> well, how are you gonna produce 0-10V?
[04:24:06] <cradek> I'm not
[04:24:07] <jmkasunich> mesa? parport pwm?
[04:24:10] <cradek> knob on the vfd
[04:24:16] <cradek> oh this is not emc yet
[04:24:18] <jmkasunich> no S words?
[04:24:23] <jmkasunich> oh
[04:24:27] <jmkasunich> * jmkasunich stops caring ;-)
[04:24:30] <cradek> this is just a hack to get spindle speed control
[04:24:46] <cradek> :-P
[04:25:06] <jmkasunich> if its just a temp hack, go ahead and use the contactors to switch the control signals
[04:26:12] <jmkasunich> worst case you take the contactors apart and clean/file/polish the contacts if they are pitted or corroded
[04:26:50] <jmkasunich> (actually, check for aux contacts on the contactors, they would be more suited for control signals, unless the bport control is already using them)
[04:27:26] <cradek> ok
[04:28:52] <jmkasunich> time to walk the dog (and probably go to sleep after that)
[04:28:55] <jmkasunich> goodnight
[04:28:57] <cradek> night
[04:30:12] <SWPadnos> see you
[04:30:16] <SWPadnos> (even though it's before midnight :) )
[07:41:19] <SWPadnos___> SWPadnos___ is now known as SWPadnos
[09:02:53] <christel> [Global Notice] Hi all! One of our sponsors is doing some maintenance, it may or may not affect connectivity on freenode. Have a nice day!
[14:02:58] <CIA-20> EMC: 03jepler 07TRUNK * 10emc2/docs/src/gcode/main.lyx: layout List doesn't seem to get shown right in l2h
[14:11:32] <CIA-20> EMC: 03jepler 07v2_2_branch * 10emc2/docs/src/gcode/main.lyx: merge from trunk: remove use of layout List
[14:13:20] <jepler> there must be something he's overlooking
[14:18:53] <jepler> hmph -- only about an hour on battery and it's down to 60%.
[14:21:27] <jepler> (on my new eee, that is)
[16:55:47] <alex_joni> jepler: I'm puzzled too
[16:56:30] <SWPadnos> the gantrykins questions?
[16:56:47] <skunkworks> digital i/o?
[16:56:57] <SWPadnos> right - another good one
[16:58:19] <alex_joni> SWPadnos: M66
[16:58:24] <SWPadnos> ok
[16:59:03] <SWPadnos> the RT code that loks at the inputs runs in the servo thread, right?
[16:59:38] <SWPadnos> err - looks
[17:00:49] <cradek> yes it would be in the motion controller
[17:01:37] <SWPadnos> not that it matters - a glitch that lasts <1ms probably shouldn't be counted as valid input anyway
[17:02:12] <SWPadnos> I think he said that it works (sort of) using a pyvcp panel, but not when connected to a parport pin - timing is the main difference there
[17:02:16] <SWPadnos> that I can think of anyway
[17:02:42] <alex_joni> SWPadnos: what puzzles me is that he sees the bits toggle in hal show
[17:02:46] <alex_joni> which is waaaay slow
[17:02:51] <SWPadnos> hmmm
[17:03:02] <cradek> I hate to guess because I haven't even tried it
[17:03:16] <SWPadnos> I like to guess, even though I haven't tried it ;)
[17:05:12] <alex_joni> well.. I have to guess even if I wrote it
[17:07:06] <alex_joni> SWPadnos: it's not really RT stuff.. so very small things get "lost"
[17:07:14] <alex_joni> RT only copies the inputs to status
[17:07:35] <SWPadnos> hmmm. is the input check in userspace?
[17:07:40] <alex_joni> yes
[17:07:44] <SWPadnos> oh - interesting
[17:08:07] <alex_joni> bbl
[17:08:13] <SWPadnos> see you
[17:16:13] <fenn> you could have some bit "triggered" that gets set in RT, and checked/reset in userspace
[17:31:15] <alex_joni> fenn: yeah, maybe .. but there's no real advantage in doing that
[17:31:28] <alex_joni> the code that waits for the input to happen is user-space
[17:31:52] <alex_joni> the interpreter is halted while the input needs to happen, so after you get the trigger you won't resume immediately
[17:32:09] <alex_joni> it will first start interpreting, queueing, etc, and at some point it will start execution
[17:34:37] <fenn> but you won't miss a small blip
[17:35:00] <alex_joni> fenn: if you have small blips you can use debounce
[17:35:15] <SWPadnos> or a latch in HAL
[17:35:20] <fenn> hmm.. yeah i guess its the same thing really
[17:35:21] <alex_joni> others might say small blips are noise
[17:36:25] <alex_joni> actually the whoel triggering could have been in hal.. not sure that was a wise decision
[17:36:48] <fenn> you cant easily set hal parameters from g-code though?
[17:37:15] <fenn> for example if you want to trigger at 1 at some part of the program, then trigger at 2 later on
[17:39:44] <alex_joni> well.. you sorta "can" using custom M-codes
[17:39:50] <alex_joni> or M64 outputs