Back
[00:00:23] <geo01005> PCW: That would be great. I think it is going to take me quite a while to understand how it all works, but I might be able to figure it out.
[00:01:41] <PCW> geo01005:do you have a 7I43-400?
[00:02:23] <geo01005> yes I do.
[00:05:23] <PCW> OK if you send an email to Mesa, Ill send you back a bitfile tomorrow
[00:05:26] <PCW> preferences on pinout?
[00:05:27] <PCW> It easiest if I just tack the SPI pins on a existing pinout,
[00:05:29] <PCW> maybe stealing some stepgen pins or some such
[00:09:32] <geo01005> I have been using the SV8B bit file.
[00:11:34] <geo01005> I'm using a 7I30 for the first four servos, I need one other servo for the spindle/extruder, but it dosn't matter where the pins are.
[00:12:31] <PCW> OK I would have to steal one servo axis to get the pins for the SPI port
[00:12:33] <PCW> if I steal one axis (6 pins) I can make a SPI interface for 3 devices max
[00:12:34] <PCW> (clk,di,do,cs0,cs1,cs2)
[00:13:21] <geo01005> Sounds good.
[00:13:54] <PCW> OK bye all...
[00:16:45] <skunkworks> wonder how long this thread will last..
http://www.cnczone.com/forums/showthread.php?t=73749
[00:34:52] <mshaver> skunkworks: Well, I'll have to bookmark that one!
[01:40:30] <KimK> SWPadnos: Are you around? Have you got a moment to look at a picture (voltmeter test lead repair related) and let me know if you've ever run across this before, and if so, what you did about it? Anyone else who has any advice for me on this is invited to jump in too.
http://imagebin.ca/view/7WZOZP.html
[01:41:17] <KimK> "description" has more info
[01:49:22] <cradek> can you replace the female part in the meter?
[01:49:30] <cradek> those don't look like any banana plugs I know
[01:56:59] <KimK> Yes, they are kind of odd. Replace the existing jacks? Probably not, molded in. But so far my leading choice is to very slowly, gently, and carefully (by hand? with a pin vice?) drill the jacks a few thousandths(?) bigger. Need more measurements before starting this, though. And waiting for any better advice from my friends!
[01:58:27] <cradek> that is an approach I didn't consider - might just work.
[01:59:05] <SWPadnos> KimK, never had to deal with that exact problem
[01:59:26] <SWPadnos> I don't know that I'd go reaming out the socket though, you never know what kind of coatings you'll be taking off
[02:00:33] <mshaver> There are at least 2 sizes of banana plugs
http://www.pomonaelectronics.com/pdf/d2944_100.pdf and
http://www.pomonaelectronics.com/pdf/d1325-5230-5406-6546_100.pdf
[02:01:25] <mshaver> and I've seen several different diameters of pin jacks and plugs, especially on biomedical instruments
[02:01:58] <mshaver> well, nighty-night all
[02:02:08] <KimK> mshaver: thanks! goodnight
[02:16:22] <topls64> for ref. I have bannana plugs here measuring .190 and .160
[02:17:01] <tomp> topls64: what was you edm question?
[02:17:20] <SWPadnos> oh hey tomp
[02:17:28] <tomp> SWPadnos: hello
[02:17:34] <SWPadnos> I think that "too many bounces" email is an automated thing
[02:17:41] <tomp> ok
[02:17:46] <tomp> thx
[02:17:46] <topls64> i had a bunch earlier. still 50/50 with how i want to control it
[02:17:48] <SWPadnos> I'm pretty sure none of us has sent you an email telling you we're deleting you from the lists ;)
[02:18:02] <tomp> it was automate
[02:18:05] <tomp> d
[02:18:07] <SWPadnos> yep
[02:18:23] <SWPadnos> so that means that for some reason, sourceforge and your email provider don't always get along
[02:18:25] <SWPadnos> (I think)
[02:18:55] <SWPadnos> was there an action you could take to prevent getting removed from the list?
[02:19:03] <tomp> topls64: emc has controlled edm thru a way to reduce velocity automaticly.
[02:19:19] <tomp> SWPadnos: no action i know of
[02:19:23] <SWPadnos> ok
[02:19:41] <SWPadnos> I wasn't sure if there might have been a link to click on to say "wait a minute, don't do that
[02:19:43] <SWPadnos> ""
[02:20:06] <topls64> tomp: yes, we discussed adaptive feedrate. It is a prototype machine and learning for me, so this one may just be controlled by a standalone avr based comtroller
[02:20:16] <tomp> topls64: it will never go forward and backwards, but can 'stay behind ' the cut and produce work.
[02:20:46] <tomp> not at all like the classic servo design of the lazerenkovs
[02:20:58] <SWPadnos> for a sinker, you might be able to do a little forward/backward stuff
[02:21:11] <tomp> not thru tp/tc
[02:21:12] <SWPadnos> with a separate HAL component that only affects Z
[02:21:18] <tomp> yes, thru hal
[02:21:21] <topls64> tomp: i wan't to adapt feed/retract based on arc power consumption
[02:21:40] <tomp> no one does, you may want gap control tho
[02:21:43] <SWPadnos> the TP can be slowed by AF, and you can also offset Z by some amount
[02:22:00] <SWPadnos> you'd want both
[02:22:23] <SWPadnos> well, if you want power, you still want gap voltage, so you want both in this case :)
[02:22:45] <tomp> SWP you mean +/- offset? interesting
[02:22:52] <topls64> Thats the thing - can't I control gap based on the power consumption>
[02:23:08] <SWPadnos> you run control loops on both, and use the one that slows things the most as the controller
[02:23:15] <SWPadnos> topls64, no, I don't think so
[02:23:36] <tomp> btw, the dev of this ctrl is in italy retrofitting ECMs right now
[02:23:38] <SWPadnos> if you're using very low power, is that because you aren't near the work yet, or is it because you've touched the work?
[02:24:14] <SWPadnos> tool touch would cause ~0V, but high I, yielding somewhat low power, I think
[02:24:35] <tomp> topls64: gap based on ower consumption? you ean position is power based? classic gap control for em is maintinging a voltage between the tool and work ( anode and cathode)
[02:24:50] <tomp> argh crap kbd
[02:25:02] <SWPadnos> at least all the D's appeared to appear that time :)
[02:25:17] <SWPadnos> oh, except in EDM ;)
[02:25:29] <topls64> tomp: I would think I can measure the current and voltage to the arc, and position the tool within a threshold
[02:25:40] <SWPadnos> when I was in college, I had a keyboard that had a flaky G key
[02:26:02] <SWPadnos> so I added some choice words into the word processor conrrection vocabulary
[02:26:10] <SWPadnos> things like "voltae" -> "voltage"
[02:26:20] <topls64> thats silly
[02:26:26] <SWPadnos> too bad you don't have an auto-correcting IRC client
[02:26:57] <topls64> wife spilled soda on mire wireless and it would type ......................con...sta...n...tly...
[02:27:02] <SWPadnos> heh
[02:27:37] <tomp> classic is only voltage difference, given a desired value (say 30V), then advance proportionally to the difference between desired and measured ( the diff is + or - and is scaled by a gain )
[02:28:07] <tomp> like (Whatyou want - whatyougot) * gain = new signed velocity
[02:29:15] <topls64> tomp: so how would one measure the what you got value? I assume what I want is the powersully setpoint
[02:29:21] <tomp> the new signed velocity would advance or retreat along the cnc path (ideally).
[02:29:41] <KimK> I'm glad I got to at least say thanks to mshaver, that was enlightening. I didn't know there were miniature banana plugs, 0.120" dia. x 0.300" L versus 0.166" dia. x 0.550" L. It appears my plugs may be some odd hybrid of miniature diameter and standard length. Rather than drilling, maybe I should make adapters to shrouded safety bananas? (I forgot to mention I also got some standard test probes that I can't use as is.) Anyway, thanks to
[02:29:42] <KimK> all for your good advice! I'll be working for a bit, back after while.
[02:30:07] <tomp> ah, the measured value is simpy a voltmeter reading from tool to work
[02:30:57] <topls64> s
[02:31:04] <tomp> and for the desired point, the actual discharge is near 30V for most edm ( observe the wave on a scope and measure the level of the discharge )
[02:31:28] <tomp> it will vary but not a lot, the fine points of edm are beyond a chat irc
[02:32:40] <topls64> taking notes...
[02:32:41] <tomp> so actual - desired ( eg 28V - 30V ) yields a small (slowish) retreat. and 40-30 = medium advance... etc
[02:33:10] <tomp> when you are far from work (100-30) = 70 means go forwar fast
[02:33:31] <tomp> when you are shorted (0-30) = -30, means RUN AWAY
[02:34:20] <tomp> some systems inrterpret the value thru a 'curve' ( a map of value to velocity) an allow you to 'bend' the curve
[02:37:14] <topls64> So, I'm thinking AVR micro based, 2 voltages and maybe current on a2d converter, oem750, stepper, powersupply, lcd, etc
[02:37:27] <tomp> this difference and curve can be done in HAL
[02:37:42] <topls64> But them I have to lug a pc around
[02:37:51] <topls64> with the tank, powersupply..
[02:38:53] <topls64> v2 will need hal for sure. and I'll bring up wire emd prolly next year...
[02:38:57] <SWPadnos> a PC can be as light as a gallon of water and as small as a hardcover book
[02:39:09] <SWPadnos> I don't think PC size is an issue these days
[02:39:18] <tomp> i dont see how current enters the scheme, the gap is based on voltage not current. the term 'dielectric breakdown strength' has no current in its equation, only voltage resisitance and distance.
[02:39:41] <topls64> I'd just like to have it. its an io pin to me.
[02:39:49] <tomp> the spark jump occurs at same distance wit a zillion amps and a microamp
[02:40:03] <topls64> There is more beyond just pc size to me. It just the way things work here
[02:40:04] <tomp> yes, monitoring the current is a good idea
[02:40:45] <tomp> a small liteweight edm demonstrator is something i'd like too, at least luggable or car-trunk able
[02:41:04] <topls64> I may be your man
[02:41:24] <topls64> the 4" travel slide should arrive this week
[02:41:25] <tomp> and taking the mountain to mohammed is not always the right approach ;)
[02:42:22] <topls64> Just something to play and learn with, and score points at work (broken taps, bolts in hardened tooling)
[02:42:28] <topls64> hence portable
[02:42:53] <tomp> yes, small slides, look for trashed wire edm 'heads, the U-V slides are very good crossed roller bearings with servos, limits and maybe 40mm travel ( still near 10kg)
[02:42:54] <topls64> emc is on the mill for tooling
[02:43:36] <tomp> i gotta get back to work, very interesting to talk to you, l8r
[02:43:44] <topls64> peace
[02:44:18] <tomp> :) tomp prays for whirled peas
[02:46:39] <topls64> A slide for the head brings up a good point. Is there any heavy forces involed, other than the weight of the tool and ineria?
[02:47:51] <topls64> in a sinker edm
[02:50:06] <cradek> I think none whatsoever. the sinker does not touch anything.
[02:50:41] <cradek> I bet you want it as light as possible so you can accelerate it
[02:52:24] <tomp> it is common to counterbalance (weight or air balance) even on small systems. yours however is 'teenytiny' ( the technical term )
[02:53:27] <SWPadnos> how does that compare to "itsy bitsy"?
[02:53:55] <tomp> slightly larger by a 'smidgen'
[02:54:18] <SWPadnos> an, so you'd have to move it over by "a scoche"
[02:54:29] <SWPadnos> s/an/ah/
[03:54:17] <JymmmEMC> and lastly... a cunt hair
[03:55:11] <seb_kuzminsky> JymmmEMC: wrong window
[05:37:30] <topls64> just caught all that. All good terms for small ;) 'nite guys & thx 4 the chat(s)
[12:58:52] <skunkworks> 5 days to vegas
[12:59:04] <skunkworks> * skunkworks has never been
[12:59:33] <alex_joni> sounds good
[13:00:15] <skunkworks> planning on a daytrip to see the south rim of the grand canyon.. That should be cool.
[13:00:32] <archivist> sounds expensive
[13:00:48] <skunkworks> actually - right now it isn't
[13:01:03] <skunkworks> they are really trying to get people there I think.
[13:01:21] <archivist> then they suck you dry
[13:01:40] <skunkworks> heh - they hope to. We are not gamblers - so lots of sight seeing.
[13:01:55] <skunkworks> going to see hoover dam also.
[14:33:48] <jepler> skunkworks: ooh fun
[14:34:22] <jepler> I went to grand canyon as a kid, but I don't remember it as an adult. I'd like to see that again, and the hoover dam would be neat to see too
[14:44:43] <skunkworks> jepler: I have not been west yet.. so this should be neat.
[14:47:02] <jepler> http://emergent.unpy.net/files/sandbox/img_0604-medium.jpg yesterday we went to a park with lot of birds
[14:47:10] <jepler> off to the next day of vacation, bbl
[15:03:14] <skunkworks> jepler: pretty :)
[16:05:29] <jensor> In EMC Documentation Wiki "MILLSETUP" step 9 mentions to issue commands in MDI to home the machine before turning it off. Wouldn't it be more appropriate to include those commands in the g-code file?
[16:06:01] <jensor> at the end of the file?
[16:06:08] <archivist> no because you run many jobs per switch on
[16:06:48] <jensor> I see
[16:15:03] <SWPadnos> skunkworks, if you want a nice (and somewhat expensive) dinner there, go to "The Tillerman"
[16:15:24] <SWPadnos> it's somewhere out on Flamingo I think - a few miles off the strip
[16:17:17] <shrdlu-> sorry, what was the line to connect the digital out again? net <something> motion.digital-out-00 => parport.0.pin-01-out ?
[16:17:29] <shrdlu-> for the m62
[16:17:43] <SWPadnos> yep, that's right
[16:18:00] <shrdlu-> did there need to be something where the something is?
[16:18:05] <SWPadnos> a name
[16:18:22] <shrdlu-> oh, is that arbitrary?
[16:18:31] <SWPadnos> net iknowwhatyoudidlastsummer motion.digital-out-00 => parport.0.pin-01-out
[16:18:38] <shrdlu-> roger, thanks
[16:18:46] <SWPadnos> well, whether it's arbitrary or not is your choice :)
[16:18:54] <shrdlu-> heh
[16:19:12] <SWPadnos> it just has to be unique, or you'll be connecting those pins to the existing net with that name
[16:19:35] <shrdlu-> I've decided to just buy that dongle for the time being. I'm going insane trying to work this all out on a short time scale
[16:19:44] <shrdlu-> $300 :(
[16:19:51] <shrdlu-> for bad software
[16:20:12] <SWPadnos> yeah, sadly it's usually money that gets you out of a tight bind the fastest
[16:20:36] <SWPadnos> if you don't have time to learn a new system, you can't really do anything else
[16:20:43] <shrdlu-> no, quite
[16:20:51] <shrdlu-> you've all been very helpful though, I appreciate it
[16:21:07] <SWPadnos> sure. I'm sure it's been frustrating for you
[16:22:41] <BJT-Work> shrdlu-:
http://www.linuxcnc.org/docview/html//hal_basic_hal.html
[16:24:00] <shrdlu-> thankyaw
[16:27:00] <piasdom> g'mornin all
[16:39:52] <geo01005> Trying to get some clarification on the raw read and write in the hostmot2 driver.
[16:40:53] <geo01005> It looks like you can only transmit and receive only one address for each hm2_read() or hm2_write() call.
[16:40:57] <geo01005> Is that right?
[16:41:11] <BJT-Work> what do you mean geo01005
[16:41:53] <BJT-Work> AFAIK each read and write does the whole card but I'm just getting started with a 5i20
[16:43:13] <BJT-Work> * BJT-Work runs to read the hostmot2 docs here
http://www.linuxcnc.org/docview/devel/html//drivers_hostmot2.html
[16:43:17] <geo01005> Well I'm working on reading SPI devices using the raw mode. I need to write to more than one address for each hm2_write() call.
[16:44:18] <BJT-Work> most likely you need to catch seb on here or post your question on the mailing list so seb will catch it...
[16:45:46] <geo01005> I'll try to catch him when he is on.
[16:47:03] <BJT-Work> geo01005: look for seb_kuzminsky
[16:47:48] <geo01005> It looks like he is the main contributor for the hostmot2, no?
[16:48:19] <BJT-Work> yes
[16:48:56] <BJT-Work> * BJT-Work wanders off to lunch
[16:49:20] <SWPadnos> geo01005, you can read and write one location per strobe of the write_strobe pin
[16:49:35] <SWPadnos> according to the manual. I haven't checked the code to make sure that's true
[16:52:23] <geo01005> Well in the man page it sayswrite_strobe: Each time the hm2_write() function is called, this pin is examined. If it is True, then value in .write_data is written to the address in .write_address, and .write_strobe is set back to False.
[16:52:35] <SWPadnos> yep
[16:52:41] <geo01005> So only one location per hm2_write()
[16:52:52] <SWPadnos> correct
[16:52:53] <geo01005> IE once per servo loop.
[16:53:02] <SWPadnos> yep
[16:53:27] <SWPadnos> you could put the write function into a somewhat faster thread, but it's probably not useful to do that
[16:54:25] <geo01005> I belive the thread speed of the read and write functions is largely limited by the speed of EPP.
[16:54:45] <SWPadnos> oh. 7i43 huh
[16:54:50] <geo01005> yeah.
[16:55:06] <SWPadnos> yep, you'll have a hard time going much past 2-5 kHz then, I imagine
[16:55:38] <SWPadnos> there is a gpio_write function, but I don't know if the raw write is done there or in the larger "write" function
[16:56:18] <geo01005> gpio_write is not avaible for the 7i43 because the EPP.
[16:57:04] <SWPadnos> right, I was just getting to that realization
[16:57:27] <geo01005> It looks like a new SPI module will have to be made if data needs to be recieved every servo thread.
[16:58:30] <geo01005> Now, for a thermocouple I don't need data that frequently, but if I'm going to do anyting I would like to do it right.
[16:59:37] <SWPadnos> yeah, getting the SPI driver done is definitely a better solution all around :)
[17:02:21] <geo01005> On the bright side, it looks like the SPI module will be very much like the Encoder or Stepgen modules.
[17:02:48] <SWPadnos> other than figuring out the setup and insmod parameters, it should be easy ;)
[17:07:42] <SWPadnos> oh, now he shows up
[17:07:44] <SWPadnos> :)
[17:08:00] <seb_kuzminsky> hi
[17:08:10] <SWPadnos> err, that's what I meant
[17:08:12] <SWPadnos> hi
[17:09:44] <geo01005> Hi seb, have you been following any of my crazy thoughts about adding an SPI module to the hostmot2 driver?
[17:10:45] <seb_kuzminsky> hi geo01005, i've been following it somewhat
[17:11:08] <seb_kuzminsky> i think it's a great idea, but hard to do in a good usable way
[17:11:32] <seb_kuzminsky> the problem is you need not just a driver for the SPI UART on the AnyIO board, but also a driver for the device at the end of the serial line
[17:11:51] <seb_kuzminsky> and there's no good way that i know of for the driver to know what kind of device that is
[17:11:58] <SWPadnos> yep "interpreting" the data is the really hard part
[17:12:01] <seb_kuzminsky> you can't (in general) probe it and ask it what it is
[17:12:16] <seb_kuzminsky> SWPadnos: i think of it as a configuration issue
[17:12:28] <seb_kuzminsky> how do you tell the driver about the hardware it's supposed to drive?
[17:12:30] <SWPadnos> that's especially trrue if you're connecting something you built
[17:12:43] <SWPadnos> sure, that's the same problem I've had with a generic modbus driver
[17:12:58] <SWPadnos> modbus and SPI are the mechanism for moving data, but they don't know what the data is
[17:13:12] <geo01005> Yes that is true.
[17:13:18] <seb_kuzminsky> hostmot2 is great great great because of the IDROM, the Module Descriptors, and Pin Descriptors, that completely describe the AnyIO board and the firmware running on it
[17:13:54] <seb_kuzminsky> SPI or modbus can do similar things, the important thing is communicating from the device to the driver what the capabilities are
[17:13:56] <geo01005> How about the thought of supporting only a couple of SPI chips?
[17:14:08] <seb_kuzminsky> geo01005: well its a start :-)
[17:14:16] <SWPadnos> there are three SPI daughtercards made by Mesa
[17:14:34] <geo01005> I just can't tell you how much I want to have a couple of ADC on the mesa cards.
[17:14:49] <SWPadnos> if you want it $800 worth, I can help ;)
[17:15:49] <geo01005> I hate to sound stingy, and I don't want to exclude any of the mesa cards, but when a single analog card cost more than the rest of my setup I cringe just a little.
[17:16:00] <SWPadnos> heh
[17:16:19] <SWPadnos> they have a $279 (?) card with 8 analog inputs I thihnk
[17:16:32] <geo01005> yes.
[17:16:41] <shrdlu-> what do I need to install to satisfy "Required OpenGL header missing."
[17:16:54] <shrdlu-> for python
[17:16:59] <SWPadnos> shrdlu-, something like libglu1-mesa
[17:17:02] <SWPadnos> oh, hmmm
[17:17:18] <SWPadnos> is this for emc or some other program?
[17:17:24] <shrdlu-> emc
[17:17:39] <SWPadnos> apt-get build-dep emc2
[17:17:51] <SWPadnos> with sudo, of course
[17:17:55] <shrdlu-> oh, damn. heh
[17:18:00] <shrdlu-> I must have missed that line
[17:18:05] <shrdlu-> anyway, libglu1-mesa got it
[17:18:11] <SWPadnos> that may not be the one
[17:18:26] <SWPadnos> I don't know that it has anything to do with python
[17:18:43] <SWPadnos> oh, also it's a library, not a -dev package, so it probably doesn't have any headers
[17:18:58] <SWPadnos> build-dep will pull in everything you need. is this a new install?
[17:19:24] <shrdlu-> yeah
[17:19:41] <SWPadnos> h. then you need to go thrrough all the instructions again ;)
[17:19:44] <SWPadnos> ah
[17:23:48] <geo01005> For most of the SPI ADC chips that I have seen, like a microchip MCP3208, all that you would need to do is throw the address of the input you want at it and it faithfully reports the data.
[17:24:35] <geo01005> Isn't there a easy way of seting up the transmit and recive frames so they can be flexible for the differences between the devices?
[17:25:38] <SWPadnos> that's not the hard par
[17:25:39] <SWPadnos> t
[17:25:50] <SWPadnos> there are also SPI serial->parall IO chips
[17:26:08] <SWPadnos> so for some devices, what you get back should be an array of bits, not a 10/12/16 bit "analog" value
[17:26:50] <SWPadnos> when exporting the HAL pins, you would want different parameters for those two cases as well
[17:27:07] <seb_kuzminsky> geo01005: i think i heard you talking about a spindle/extruder... are you working with the reprap folks?
[17:27:10] <SWPadnos> the digital inputs need an xxx-in and an xxx-in-not pin
[17:27:18] <SWPadnos> digital outputs need an xxx-invert parameter
[17:27:24] <SWPadnos> and you need scale for analog I/Os
[17:28:15] <geo01005> Reprap yes... only I don't want to use EMC just as a crutch to get to the Reprap electronics. I think that EMC is a more powerful system that will do a better job.
[17:28:24] <seb_kuzminsky> :-D
[17:28:58] <geo01005> So I would like to put together an interface using the mesa boards that will control the whole machine rather than the arduino they are using.
[17:29:24] <geo01005> After all, the reprap community is already using gcode.
[17:29:37] <seb_kuzminsky> reprap is cool, but i agree with you that it'd be interesting to do it with emc2
[17:29:57] <seb_kuzminsky> are they modeling the extruder as a spindle or as an axis?
[17:29:59] <alex_joni> it always struck me as odd that they want to replicate the emc2 functionality
[17:30:03] <alex_joni> since it's already there..
[17:30:09] <alex_joni> seb_kuzminsky: I think I/O
[17:30:21] <seb_kuzminsky> good thing they have geo01005 to pull them back on the righteous path ;-)
[17:30:52] <alex_joni> I'm sure it'll take a bit more than that :)
[17:30:59] <geo01005> Neither really... the spindle is just running at an open loop speed... well I suppose like an open loop spindle.
[17:31:03] <alex_joni> but it's a supposedly free world
[17:32:00] <seb_kuzminsky> geo01005: tell me again what you want SPI for?
[17:32:10] <geo01005> I wanted to tie the velociy of the extruder to the velocity of the tool head while extruding, to get consistent flow rate/ velocity ratio.
[17:33:03] <geo01005> I want SPI to read a thermocouple in the extruder so that I can control the extruder heater with a PID loop.
[17:33:57] <geo01005> The build often requires different temps at differnt times, and currently the heater control is sort of... well, I don't like it.
[17:35:27] <geo01005> So either an SPI ADC, or and SPI thermocouple interface, or a voltage-> frequency-> encoder interface.
[17:37:06] <geo01005> The easiest is just the voltage->frequency read by and up down encoder. But and SPI ADC would be more usefull to other people in the EMC community.
[17:38:21] <SWPadnos> I think what SPI might need will be some minimal configuration for the hostmot2 driver, then a separate HAL module that takes raw data from hostmot2 and turns it into useful data for the rest of HAL
[17:39:00] <SWPadnos> so you configure the SPI module for bit rate, number of bits, number of transfers ..., and you get back a set of U32 (or something)
[17:39:38] <SWPadnos> you then write a module that takes in however many U32 words and cooks the data to be useful on the other side
[17:39:50] <SWPadnos> that module would also export the parameters or other pins needed
[17:40:16] <SWPadnos> so you'd have one that takes in one U32, exports a scale and offset parameter, and has a float output
[17:40:17] <geo01005> The hal module could device specific, or general.
[17:40:31] <SWPadnos> the hal module may bneed to be device specific
[17:40:42] <SWPadnos> consider two 12-bit ADCs chained together
[17:40:50] <SWPadnos> you'd get 24 bits inside one 32-bit word
[17:41:56] <SWPadnos> the SPI driver only takes care of the actual data transfer (as it should), the "device driver" takes that data and puts it into a form that's useful for HAL
[17:44:40] <geo01005> Could we not develop a set of templates, maybe XML, that describe each decive connected to a BSPI channel and use these templates to configure a hal driver?
[17:44:52] <SWPadnos> not easily
[17:45:09] <seb_kuzminsky> i'd love *something* like that for hm2 configuration
[17:45:21] <SWPadnos> for one thing, it's not so easy to get data from a file into a kernel module
[17:45:25] <seb_kuzminsky> but it requires parsing and validating XML in the kernel, which is sort of gross
[17:45:32] <seb_kuzminsky> SWPadnos: that part's actually pretty easy
[17:45:46] <SWPadnos> request_configuration ;)
[17:45:53] <seb_kuzminsky> you could request_firmware() it, or write it to a file in /proc or /sys, or use configfs or...
[17:46:12] <SWPadnos> you still need a userspace helper
[17:46:19] <seb_kuzminsky> udev
[17:46:34] <SWPadnos> which is silly because the kernel is what actually reads the damned files anyway ...
[17:46:44] <seb_kuzminsky> heh
[17:46:45] <geo01005> I have to admit, I'm not terribly familar with all of this, so my suggestions may be way off base.
[17:47:04] <seb_kuzminsky> geo01005: i thought long and hard about how to do what you're talking about
[17:47:12] <seb_kuzminsky> and i didnt come up with a satisfactory solution :-(
[17:47:15] <SWPadnos> heh. and jmk and myself before that ;)
[17:47:23] <SWPadnos> among others
[17:47:34] <seb_kuzminsky> in the end i'm using the "config" modparam to the hm2 low-level driver
[17:47:38] <seb_kuzminsky> see hostmot2(9)
[17:47:59] <seb_kuzminsky> it's not xml, but it's a small "key=value" config language
[17:48:07] <seb_kuzminsky> and everyone hates it (including me)
[17:48:08] <geo01005> so are hal drivers complied duing a EMC build and are more or less concrete after that?
[17:48:17] <seb_kuzminsky> yes
[17:48:28] <SWPadnos> you can compile them as often as you like, but they don't change while you're using them ;)
[17:48:44] <seb_kuzminsky> changing a hal driver requires a recompile, but changing the connections between them is a runtime thing
[17:48:56] <seb_kuzminsky> which is a big part of what makes hal so super duper awesom
[17:49:16] <SWPadnos> once you load a module, its configuration is more or less fixed
[17:49:19] <geo01005> so could a new hal driver be complied when EMC starts?
[17:49:27] <seb_kuzminsky> yes, but ewww
[17:49:33] <SWPadnos> you can have parameters (as hostmot2 does) that change how the module behaves
[17:49:54] <seb_kuzminsky> better to compile all the modules when you build, then pick which one gets loaded and how it's configured when you start emc2
[17:49:54] <SWPadnos> you could compile "on demand", but you would then need sudo to run emc
[17:50:15] <seb_kuzminsky> SWPadnos: why would you need sudo?
[17:50:22] <seb_kuzminsky> not if you rip
[17:50:22] <SWPadnos> since you must be sudo to (a) comp --install, (b) make setuid, or (c) make install
[17:50:29] <SWPadnos> sudi make setuid
[17:50:31] <SWPadnos> sudo
[17:50:42] <seb_kuzminsky> but normal components are not setuid
[17:50:45] <SWPadnos> you can't do the setuid step without sudo
[17:50:50] <seb_kuzminsky> only a couple of strange executables need that
[17:50:51] <SWPadnos> kernel components are
[17:51:09] <SWPadnos> anything that runs in RT is a kernel component, and therefore needs sudo to install
[17:51:10] <alex_joni> they are not seruid, but a helper program is setuid to be able to modprobe them
[17:51:16] <alex_joni> setuid*
[17:51:18] <SWPadnos> AFAIK
[17:51:51] <SWPadnos> the thing is, you need to be root to install a file that the module loader is willing to load
[17:52:02] <seb_kuzminsky> geo01005: you sense extruder-barrel temperature with a thermocouple and ADC? How is it heated?
[17:53:35] <geo01005> Well you need a thermocouple signal conditioner to get from mV input to the ADC. I'm using a cartige heater, rectifed AC, switched with a FET.
[17:54:25] <geo01005> regular reprap uses custom hand wound heater with switched 12VDC by a FET.
[17:54:45] <seb_kuzminsky> You're PWM'ing the FET for the heater? what's the signal timing on that?
[17:55:19] <geo01005> I was planing on just using the same frequency as the servos I'm running, 20-30 khz.
[17:56:04] <geo01005> One of the lame things about Reprap untill recently is the power is just switched on and off to the heater.
[17:56:16] <seb_kuzminsky> low-res pdm ;-)
[17:57:08] <seb_kuzminsky> so the only real blocking issue for this is getting temperature feedback from the extruder into emc's pid, it sounds like
[17:58:31] <geo01005> Yes. And like I said, because the frequency responce of the heater is pretty low, the temp feedback loop could run at a low frequency and I could use a voltage to frequency converter to digitize the temp.
[17:59:09] <geo01005> But no help to other who want and ADC on a mesa card.
[17:59:18] <seb_kuzminsky> right...
[17:59:40] <geo01005> But hey, I be saying that other want it, and there really isn't a demand.
[18:00:03] <geo01005> Often it would just be an extra feature or a toy.
[18:00:17] <seb_kuzminsky> it would be a cool feature, but you could make an emc reprap without it
[18:00:48] <geo01005> Yeah.
[18:01:20] <geo01005> The supper easy way is just to rig up an arduino to send the temp over the usb.
[18:01:39] <geo01005> Since the responce is slow, it should work fine...
[18:01:50] <seb_kuzminsky> getting info from usb into hal isnt easy
[18:01:56] <seb_kuzminsky> maybe a userspace component?
[18:02:05] <seb_kuzminsky> i dont know anything about those...
[18:02:09] <SWPadnos> must be a userspace component
[18:02:16] <geo01005> well, really is sends the info over a virtual serial port.
[18:02:31] <SWPadnos> you can't access Linux devices (like USB) from a realtime context
[18:02:33] <geo01005> Other have already done this.
[18:02:49] <seb_kuzminsky> SWPadnos: but you can access non-realtime hal from realtime hal, right?
[18:02:54] <geo01005> it isn't realtime, and not guaranteed. So I don't like it.
[18:02:55] <SWPadnos> yes
[18:03:27] <seb_kuzminsky> if, say, one temp-reading per second is enough for a stable control loop, then you could read the temp via usb in userland, and put it in hal where the realtime pid can read it
[18:04:01] <geo01005> Sure, here is an example...
http://axis.unpy.net/01198594294
[18:04:12] <seb_kuzminsky> right
[18:04:25] <geo01005> But what happens when I want to use feedforward control based on extrusion rate?
[18:04:53] <seb_kuzminsky> pre-emptively raise the extruder temp because you're anticipating pushing more plastic through it?
[18:04:57] <SWPadnos> what happens if the userspace component crashes?
[18:05:09] <SWPadnos> the HAL data will never change, and you'll get a saturated PID
[18:05:29] <geo01005> Exactly. I sure don't want to walk away from that machine.
[18:05:41] <seb_kuzminsky> what happens if realtime crashes?
[18:06:00] <seb_kuzminsky> maybe userspace is less reliable, but nothing here is so reliable that you dont need hardware safety
[18:06:11] <SWPadnos> if realtime crashes then the PID stops too ;)
[18:06:11] <geo01005> Really it needs to have an overtemp cutoff switch....
[18:06:23] <SWPadnos> but it's really really hard to crash realtime
[18:06:31] <seb_kuzminsky> at work we use bimetallic switches for overtemp protection
[18:06:38] <seb_kuzminsky> SWPadnos: nah, it's easy, i do it all the time ;-)
[18:07:03] <SWPadnos> I've had a PC lock up hard - so hard that it didn't respond to pings, but RT was still running, making very very consistently timed pulses on my mesa card ;)
[18:07:12] <SWPadnos> well, if you write bad software, sure :)
[18:07:16] <seb_kuzminsky> heh
[18:07:47] <seb_kuzminsky> i lol'ed the first time linux froze, but my servos kept tracking my mpg :-)
[18:07:59] <geo01005> So what do you think? better to use and Arduino on the USB?
[18:08:15] <seb_kuzminsky> geo01005: i'd start with that
[18:08:32] <seb_kuzminsky> anything else means writing a bunch of kernel code at this point
[18:09:09] <geo01005> what kinds of delays can I expect from the userspace?
[18:09:41] <seb_kuzminsky> many tens up to a few hundreds of milliseconds, perhaps
[18:10:17] <SWPadnos> it varies, though it's usually pretty fast
[18:10:55] <seb_kuzminsky> in my dayjob i run a complete pid-based temperature controller all in userspace, and it works fine
[18:11:00] <seb_kuzminsky> our plant is so slow...
[18:12:51] <skunkworks> production wise?
[18:13:38] <alex_joni> skunkworks: seen tons of those
[18:13:42] <motioncontrol> GOOD EVENING. THE NEW GUI FOR SETTING THE EMC WITH LABVIEW IS GO ON.
[18:13:48] <alex_joni> for example for big curing ovens
[18:14:02] <alex_joni> motioncontrol: your finger tripped to CAPS LOCK
[18:14:18] <geo01005> Hmm... I was just so excited about SPI...
[18:14:34] <motioncontrol> excuse. can i load the image on pastebin?
[18:14:50] <alex_joni> I'm sure you can
[18:14:57] <archivist> geo01005, that a/d looks good for a project Im about to do
[18:14:59] <motioncontrol> ok one moment
[18:19:20] <geo01005> It is a good ADC, it could easily report 8 channels every servo period.
[18:19:35] <geo01005> Could work OK for LVDT feedback.
[18:20:43] <archivist> I just need a cheap D/A and choose my PIC now
[18:22:28] <geo01005> archivist:Wait, are you talking about the Arduino, or the MCP3208?
[18:23:00] <motioncontrol> i don,t can send the image .jpg bacause the limit is 150kb and the image is 250kb
[18:23:11] <motioncontrol> on pastebin limit
[18:23:34] <archivist> geo01005, MCP3208
[18:23:38] <geo01005> Use GIMP and change the compression?
[18:23:48] <motioncontrol> ok i prove
[18:24:08] <SWPadnos> imagemagick may be a better tool
[18:24:22] <SWPadnos> convert image.jpg -scale 50% smallerimage.jpg
[18:24:25] <SWPadnos> or similar
[18:25:47] <BJT-Work> hi seb_kuzminsky
[18:25:56] <seb_kuzminsky> hi BJT-Work
[18:26:13] <seb_kuzminsky> those funny BIT files, they're for mshaver's project i think
[18:26:25] <BJT-Work> ok
[18:28:29] <geo01005> What is the labview-EMC project about? I havn't heard about it.
[18:29:15] <BJT-Work> so I should not have them in the config charts I'm guessing
[18:30:02] <seb_kuzminsky> maybe mention that they exist, as a way to introduce the idea that you can make custom hm2 firmwares for your custom projects?
[18:30:29] <motioncontrol> http://imagebin.ca/view/xEtNx8.html
[18:30:30] <BJT-Work> ok, that sounds good
[18:30:53] <motioncontrol> ok this is the my new gui for emc
[18:33:12] <motioncontrol> the interface read the actual configuration and can mofification the single parameter the .ini file and hal file
[18:33:29] <SWPadnos> man I hate labview
[18:34:26] <seb_kuzminsky> hi peter!
[18:34:34] <pcw> Hi seb
[18:37:02] <pcw> Had an idea just in case anyone gets the crazy idea of working on a SPI interface
[18:37:03] <pcw> : split the reading part into two pieces (start_SPI_read, Finish_SPI_read)
[18:37:05] <pcw> so that other read operations and be put between to overlap some of the SPI
[18:37:06] <pcw> delays with the other reads
[18:37:16] <motioncontrol> in the menù tab you can select the general parameter and the axis x-y-z ecc specific parameter.
[18:38:00] <pcw> (can be put)
[18:39:53] <seb_kuzminsky> pcw: good idea :)
[18:41:50] <seb_kuzminsky> did you hear swp's idea to make a generic hm2 spi uart driver that puts the data it reads on some HAL pins, and then write per-device hal drivers for all the spi slaves, and hook them to the spi uart in hal?
[18:42:56] <pcw> SPI writes are free basically because of the send buffer
[18:42:58] <pcw> but you have to wait for SPI receive data...
[18:43:00] <pcw> Not sure I understand SWPs idea
[18:43:16] <seb_kuzminsky> we were discussing the issue of how to tell the driver what slave is on what spi port
[18:43:21] <motioncontrol> i'm interesting at spi interface for use more io?what is the time development finisch?
[18:43:40] <seb_kuzminsky> motioncontrol: there's currently no one working on it
[18:43:54] <geo01005> Are bitwise operations allowed in hal files?
[18:44:08] <SWPadnos> halcmd doesn't know how to do any math
[18:44:09] <seb_kuzminsky> pcw: so the idea was to connect slave drivers to uarts using hal, rather than load-time configuration
[18:44:13] <SWPadnos> if that's your question
[18:44:28] <SWPadnos> you can load components that do logic operations though
[18:44:54] <geo01005> Swp: yes, I was wondering if there is a way to extract say a bit from a u32.
[18:45:07] <SWPadnos> well, that's harder ;)
[18:45:38] <SWPadnos> actually, there may be a comopnent that takes an int in and sends bits out. if not it should be easy to write
[18:46:07] <SWPadnos> bbl
[18:46:24] <seb_kuzminsky> geo01005: there's this:
http://www.linuxcnc.org/docs/devel/html/man/man9/conv_u32_bit.9.html
[18:46:37] <seb_kuzminsky> that might be a good place to start to write the component you need
[18:47:36] <geo01005> Could it be possible to skip the component and just split the data up in a hal file?
[18:47:47] <seb_kuzminsky> geo01005: no
[18:48:13] <seb_kuzminsky> hal files are interpreted by halcmd, which doesnt know how to do that kind of stuff
[18:49:54] <pcw> Oh OK, a general purpose SPI interface is pretty messy, but I think one that had some HAL settable masks and
[18:49:56] <pcw> generic scaling-sign operations would cover a lot of A-D and D-A and GPIO chip types, There would be a lot
[18:49:57] <pcw> of chip specific specific setup however
[18:51:16] <seb_kuzminsky> can you point me to some docs (maybe mesa manuals?) that show the different spi interfaces in use, and the chip-specific setups needed?
[18:51:29] <alex_joni> seb_kuzminsky: feel like having chip specific setup as a config param and be passed on at loadrt time? :D
[18:52:01] <seb_kuzminsky> no i'd rather shoot myself
[18:53:15] <alex_joni> I'm sure you would :P
[18:53:46] <seb_kuzminsky> what i'd really like is a dynamic hal
[18:54:23] <seb_kuzminsky> imagine a hal pin that enables an encoder instance, replacing the gpio-pin hal objects with the encoder's hal objects
[18:54:31] <seb_kuzminsky> * seb_kuzminsky shivers in delight
[18:55:07] <seb_kuzminsky> the device would come up as all gpio, and then in hal you can turn on the higher-level stuff you want
[18:55:16] <cradek> isn't that just hiding/exposing pins?
[18:55:29] <seb_kuzminsky> i think so, yeah
[18:55:31] <cradek> say the pins are all there, just start with them hidden?
[18:55:32] <pcw> Seb: here are two chips we use in the 7I65 for example:
[18:55:34] <pcw> AD5754
[18:55:36] <pcw> AD7329
[18:55:37] <pcw> (plus a SPI EEPROM and SPI CPLD for GPIO)
[18:55:46] <seb_kuzminsky> cradek: what is this "hidden" you speak of?
[18:55:57] <cradek> seems like a simple hack
[18:56:13] <alex_joni> hal_show_pin() ?
[18:56:13] <cradek> add a mask bit to each pin and make the things that traverse the list of pins skip them if they're masked
[18:56:17] <alex_joni> hal_hide_pin() ?
[18:56:29] <seb_kuzminsky> i asked jmk about it a while ago and he said he thought it would be hard
[18:56:41] <alex_joni> I bet he doesn't think about hacks :P
[18:56:50] <cradek> well he's smarter than me, so I'm sure I'm missing something
[18:57:13] <seb_kuzminsky> he said the problem was modifying the list of hal objects from the realtime context
[18:57:20] <pcw> ( AD5754 quad 16 bit +-10V out DAC)
[18:57:20] <seb_kuzminsky> i didnt really understand his whole explanation
[18:57:22] <pcw> ( AD7329 8 channel 1 M/S 12 bit + sign A-D)
[18:58:22] <seb_kuzminsky> thanks peter i'll check it out
[18:58:48] <alex_joni> seb_kuzminsky: I'm sure jmkasunich would have done this properly..
[18:59:08] <alex_joni> actually removing the hal gpio component, when a encoder component is enabled
[18:59:44] <seb_kuzminsky> that was our discussion, yes
[18:59:58] <seb_kuzminsky> maybe modifying hal-object metadata (hidden/exposed bit) is easier
[19:00:03] <seb_kuzminsky> hmm
[19:00:04] <alex_joni> cradek is suggesting something way easier
[19:02:15] <seb_kuzminsky> bbl, lunch
[19:02:21] <alex_joni> enjoy
[19:03:01] <pcw> By all, cant avoid work any longer...
[19:03:14] <alex_joni> pcw: bummer.. try changing the timezone :D
[20:03:47] <billykid2> hello
[21:59:20] <alex_joni> good night all
[21:59:30] <seb_kuzminsky> later alex_joni
[22:00:07] <alex_joni> way later probably, gonna start installing a bot tomorrow :)
[22:00:35] <BigJohnT> night alex_joni
[22:04:47] <buckie555> anyone know when www.linuxcnc.org is coming back up?
[22:05:22] <seb_kuzminsky> it's down? oh, it's down!
[22:05:25] <skunkworks> huh - look at that..
[22:06:23] <seb_kuzminsky> jepler runs that machine, right? and isnt he off on vacation somewhere, the slacker?
[22:06:51] <seb_kuzminsky> gallivanting around the countryside instead of responsibly rebooting his servers when they crash?
[22:06:52] <skunkworks> no - that is hosted by dreamhost.
[22:06:56] <seb_kuzminsky> oh
[22:07:02] <skunkworks> SWPadnos: would know..
[22:07:54] <skunkworks> jepler runs the cvs server.
[23:13:23] <jmkasunich> http://status.dreamhost.com/
