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
this is the pluto replacement?
looks like it is
well .. right now it's only for dumb I/O .. but you get 24 of each with the contributed HAL driver
I think that with the new firmware peterw has promised, it will get encoder+pwm, like the existing mesa driver
I hope that seb will contribute a driver for that too
he said he intends to
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
like burst transfers on PCI
the register set (for each FPGA function) will likely be the same
if you think you know the relative costs of an address cycle vs a data cycle of each size ..
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
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
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)
in pluto I just always update all registers, I don't track whether they've changed since last time
I figure in a normal system, the PWM values will change nearly all the time
no, the USC doesn't do that either
also all the addresses to update are contiguous
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
right, that's helpful
but if someone doesn't use one function, you don't necessarily need to touch all the registers
(like they use only I/O, no PWMgens)
or the other way around
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
it's more important for the USC, since there could be 256 registers to read/write
or some subset, spread around the address space
clearly more complicated than what I had
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
can i monitor a python variable during run time with some python ide?
tomp1: I have not used any of those
any hints on how to monitor a variable?
(or lotsa 'print' )
I only know how to use print
but it feels pretty primitive
dang - why is it that I always need 7 inverters?
hah, redesigned the charge pump - better mosfet drive AND two fewer inverters
damn I'm good
charge pump on stepper machine?
maybe overkill, maybe not
if the servo thread dies and the base thread doesn't, it will keep sending step pulses forever
that seems like an unlikely failure
especially because the charge pump funciton would be in the base thread with the step generator
the only thing that would cause it is a bug, like a null pointer or somethhing
I figured out how to hook up my vfd thanks to a passing comment in the other channel
SWPadnos: the charge pump will be wherever I put it
fwd/rev can just come from the existing contactors
fault from the vfd will break the limit switch chain
it switches the 3ph. I'll just take all that out and use the crazy big relay to switch the vfd logic level
you aren't gonna switch power with the contactors are you?
I think you'll regret doing that
won't work for long?
power contacts aren't designed to switch low voltage
yeah I know
especially if the power contacts have been previously used for power
why not just produce a signed analog reference for the vfg
I guess I only need a 24v relay
err two relays
well, how are you gonna produce 0-10V?
mesa? parport pwm?
knob on the vfd
oh this is not emc yet
no S words?
* jmkasunich stops caring ;-)
this is just a hack to get spindle speed control
if its just a temp hack, go ahead and use the contactors to switch the control signals
worst case you take the contactors apart and clean/file/polish the contacts if they are pitted or corroded
(actually, check for aux contacts on the contactors, they would be more suited for control signals, unless the bport control is already using them)
time to walk the dog (and probably go to sleep after that)
(even though it's before midnight :) )
SWPadnos___ is now known as SWPadnos
[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!
EMC: 03jepler 07TRUNK * 10emc2/docs/src/gcode/main.lyx: layout List doesn't seem to get shown right in l2h
EMC: 03jepler 07v2_2_branch * 10emc2/docs/src/gcode/main.lyx: merge from trunk: remove use of layout List
there must be something he's overlooking
hmph -- only about an hour on battery and it's down to 60%.
(on my new eee, that is)
jepler: I'm puzzled too
the gantrykins questions?
right - another good one
the RT code that loks at the inputs runs in the servo thread, right?
err - looks
yes it would be in the motion controller
not that it matters - a glitch that lasts <1ms probably shouldn't be counted as valid input anyway
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
that I can think of anyway
SWPadnos: what puzzles me is that he sees the bits toggle in hal show
which is waaaay slow
I hate to guess because I haven't even tried it
I like to guess, even though I haven't tried it ;)
well.. I have to guess even if I wrote it
SWPadnos: it's not really RT stuff.. so very small things get "lost"
RT only copies the inputs to status
hmmm. is the input check in userspace?
oh - interesting
you could have some bit "triggered" that gets set in RT, and checked/reset in userspace
fenn: yeah, maybe .. but there's no real advantage in doing that
the code that waits for the input to happen is user-space
the interpreter is halted while the input needs to happen, so after you get the trigger you won't resume immediately
it will first start interpreting, queueing, etc, and at some point it will start execution
but you won't miss a small blip
fenn: if you have small blips you can use debounce
or a latch in HAL
hmm.. yeah i guess its the same thing really
others might say small blips are noise
actually the whoel triggering could have been in hal.. not sure that was a wise decision
you cant easily set hal parameters from g-code though?
for example if you want to trigger at 1 at some part of the program, then trigger at 2 later on
well.. you sorta "can" using custom M-codes
or M64 outputs