Back
[02:34:09] <tomp2> i wrote the VB code for outputs, ran fine
[02:34:09] <tomp2> i wrote the vb code for inputs and got hard lock
[02:34:09] <tomp2> that was with all inputs floating
[02:34:09] <tomp2> and same with 1 input pulled up to +5 thru 2.2K
[02:34:09] <tomp2> now running with all inputs pulled down to GND thru 2.2K's
[02:34:10] <tomp2> i dont understand the input scheme
[02:34:12] <tomp2> but i read that there's a bunch of i/o boards designed to hang onto those ide cnxrs
[02:34:14] <tomp2> now a jmpr from +5 to another 2.2k to the signal end of the pull downs shows it toggle
[02:34:16] <tomp2> tested all 8 ok
[02:34:18] <tomp2> no hard lucks ;)
[02:35:04] <tomp2> oh, 100ms polling period
[02:44:10] <tomp2> still working
[02:44:25] <tomp2> timestamp sez 10 min cool
[02:46:13] <SWPadnos> 100ms seemed to work on Linux too, at least some of the time :)
[02:46:26] <tomp2> want faster?
[02:46:47] <tomp2> going to chg now,
[02:47:04] <SWPadnos> is it repeatable that it locks with floating inputs but not when they're pulled either high or low?
[02:48:27] <tomp2> 1ms ok
[02:48:53] <tomp2> so far that is repeatable, tho i dont like the test ;)
[02:48:54] <SWPadnos> how is the delay done?
[02:49:04] <tomp2> a param to a call
[02:49:05] <SWPadnos> read / update display / sleep ?
[02:49:50] <tomp2> internals I dont know, it's a lib that i asked for src from ETT, but no reply
[02:49:56] <SWPadnos> I'm suspicious that it's a "wait a millisecond" after all processing is done, so the actual loop time is likely to be longer
[02:50:15] <tomp2> but , no lock
[02:50:18] <SWPadnos> <do work for 30 ms><pause for 1ms> is different from <read every 1ms> :)
[02:51:10] <tomp2> i can scope outputs and maybe make a counter for a known pulse input
[02:51:25] <tomp2> like a waveform gnr8r and a counter
[02:51:37] <tomp2> enuf for today
[02:51:50] <tomp2> learning VB was a pain
[02:51:51] <SWPadnos> if you have some outputs, then scoping those will be easiest/best, I think
[02:51:53] <SWPadnos> heh
[02:51:59] <SWPadnos> why not use BCB?
[02:52:04] <SWPadnos> at least it's C
[02:52:09] <tomp2> outputs may not have the delay that inputs have
[02:52:23] <SWPadnos> it lets you see the actual loop time
[02:52:42] <tomp2> i 'll buy the carcasses that others dont like, i think this stuff works and wasnt understood
[02:53:15] <tomp2> but for another day, gnite & thx
[02:53:20] <SWPadnos> VB is very much not RT, so when you sleep for 1ms, it will probably do all the screen updates, then let any other programs run, then wait a millisecond or two, then return to your code :)
[02:53:56] <SWPadnos> leave it the same, just set one port to output and toggle a bit each loop
[02:55:06] <tomp2> will try ... oh, this is the card that was 'bad' , i just pulled the 8255 and plugged #2 into #1 so it's got some guts
[02:55:39] <tomp2> it didnt fry the bridge anyway
[02:55:44] <SWPadnos> heh
[02:55:51] <tomp2> g'nite
[02:55:59] <SWPadnos> see you. thanks for beating on it
[12:41:53] <CIA-49> EMC: 03jepler 07TRUNK * 10emc2/docs/man/man3/rtapi_outb.3rtapi: whoops, didn't show prototype for rtapi_inb
[12:42:21] <CIA-49> EMC: 03jepler 07v2_2_branch * 10emc2/docs/man/man3/rtapi_outb.3rtapi: from TRUNK: show prototype for rtapi_inb
[13:15:41] <tomp2> pci8255 ran all night at 1ms poll period, and is alive this morning
[13:18:26] <jepler> tomp2: so you think the critical thing was to add pull-downs to the 8255 I/O pins?
[13:19:42] <SWPadnos> I question whether a 1ms poll period is actually 1ms
[13:20:24] <tomp2> best I can tell. when i noticed they had so many add on boards I figgered the inputs were soemthing besides what i tried
[13:21:20] <jepler> but an 82c55 chip should operate properly without pullups or pulldowns on its I/O pins
[13:22:07] <tomp2> chip 1 port A has xtra stuff on the pcb, some O/C stuff, may affect ins somehow
[13:22:17] <SWPadnos> O/C?
[13:22:37] <tomp2> open colloector driver chip for outpurts... may affect inputs soemhow
[13:22:42] <jepler> i think the extra stuff near chip 1 is concerned with the relay (not driven by 8255) and with generating the chip select signals
[13:22:42] <SWPadnos> ah, thanks
[13:23:31] <tomp2> I'll ask for a schema tho i have gotten no replies, some old notes they did send helped a lot, they're specific to V3 rev
[13:24:22] <tomp2> btw: the green light is 'powered up', the yellow led is relay
[13:35:00] <skunkworks_> * skunkworks_ think then it does have something to do with input state switching.. :)
[13:37:30] <SWPadnos> inputs switching could also point at power issues
[13:37:59] <SWPadnos> skunkworks might have a better power supply, which would make problems less frequent
[13:38:11] <SWPadnos> switching inputs do cause a dynamic load
[13:38:52] <SWPadnos> so if jepler's PC has a worse power supply, or is noisier (causing more input switching), then that could cause more problems
[13:39:19] <skunkworks_> so - BA capasitor on the supply for the card? ;)
[13:40:05] <skunkworks_> I could stick it into one of these dells for grins.
[13:40:43] <tomp2> i gotta work on other stuff today but will read the logs, thx
[13:41:50] <cradek> wow, ray's class ideas sound great
[13:42:29] <SWPadnos> yeah
[13:42:48] <SWPadnos> I'm thinking it would be good to have an installation demo like every hour or two
[13:43:05] <cradek> you mean OS install?
[13:43:06] <SWPadnos> take PC, wipe HD, insert disc and demo from there
[13:43:08] <SWPadnos> yes
[13:43:17] <SWPadnos> this is how hard it is ...
[13:43:19] <cradek> yeah, it's SO easy
[13:44:41] <alex_joni> it's OS easy :)
[13:45:06] <alex_joni> how about a large-ish disk, and on each install a new 4G partition :D
[13:45:23] <alex_joni> * alex_joni snickers about 20-30 grub items for multi-boot installs
[13:45:28] <SWPadnos> I have 15 or so 4G SCSI disks, we can give them away after the demos ;)
[13:45:33] <alex_joni> haha
[13:45:39] <SWPadnos> (not enough controllers, but we don't have to tell them that)
[13:46:03] <alex_joni> hmm.. that resumes to a big mobo with lots of PCI slots
[13:46:15] <SWPadnos> no, one at a time
[13:46:23] <SWPadnos> install, pick a winner, give them the drive
[13:46:27] <SWPadnos> lather, rinse, repeat
[13:46:59] <alex_joni> * alex_joni wonders what they will think when they get back home and notice the connectors won't fit..
[13:47:00] <skunkworks_> issue with that - what happens when they put it into thier motherboard?
[13:47:09] <jepler> man emc has terrible hardware support -- they can't even use standard hard drives!
[13:47:25] <skunkworks_> heh
[13:47:37] <alex_joni> skunkworks_: if they manage to connect them.. they get my admiration :D
[13:47:39] <SWPadnos> we'll be long gone by then. muahahahahaha
[13:48:03] <SWPadnos> you can connect 3 SCSI hard drives to a Mesa 5i20
[13:48:13] <SWPadnos> they won't do anything, but you can connect them
[13:48:50] <skunkworks_> step right up.. See the free os install that takes less than 20 minutes.. Step right up.
[13:59:33] <skunkworks_> jepler: running your 8255.hal file right now.
[14:00:10] <SWPadnos> with a big cap added, pull-up/down resistors added, or "stock"?
[14:00:11] <jepler> skunkworks_: what did you change? did you add pull-downs too?
[14:01:02] <skunkworks_> nope
[14:01:26] <jepler> are you expecting a different result than earlier for some reason?
[14:01:32] <skunkworks_> it ran for a good 5 minutes.. the second I plugged in my ribbon cable to plug 1 - the computer locked up.
[14:02:22] <skunkworks_> lets try it again
[14:02:59] <skunkworks_> I put it in a different computer.. 3rd one now.
[14:04:45] <cradek> wow, alex pulled off homing on STG1. I don't think he even had a card, and I think that's the card that's full of stupid regarding homing
[14:05:41] <alex_joni> cradek: might be ;)
[14:05:56] <alex_joni> but I also got a couple of patches during the devel cycle (couple years/months)\
[14:06:28] <cradek> was it stg1 or 2 that had the terrible pairs of encoders sharing registers or whatever
[14:07:12] <cradek> I can't believe dave was using 2.0.0 all this time
[14:07:30] <tomp2> skunkworks: yes will run a whilel w/o cable, and less with ( all w/o pulldowns ) thats one of the bits that led me to try pulldowns
[14:08:05] <tomp2> with cabl you may see the inputs flicker before death ( another reason to push/pull the lines )
[14:08:14] <jepler> adding the cable adds capacitance
[14:08:21] <tomp2> gotcha
[14:08:22] <rayh> cradek, He gets a system working and stays with it.
[14:08:37] <jepler> in my own testing I was inconsistent about having a cable or not, that could explain why I saw variations in how fast things would go wrong
[14:08:54] <tomp2> my notes same way
[14:08:58] <rayh> I had to convince him to boot a live cd and test before he'd change.
[14:09:11] <rayh> But that proves the value of the live boot.
[14:09:37] <tomp2> try the fanuc live cd to see if you want to upgrade ;)
[14:09:39] <cradek> two years ago (I think) I even fixed a bug that was biting him (G18/G19 arcs with G43)
[14:09:40] <rayh> His board is a 600 MHz with ISA slot.
[14:09:51] <cradek> he must have never got the bugfix until now
[14:10:00] <tomp2> no, just give them 1M$
[14:10:22] <rayh> If I remember, I compiled that fix here and sent to him.
[14:10:58] <rayh> He was jumping for joy yesterday when the system came to life.
[14:11:16] <cradek> sooooo much is better since 2.0.0
[14:11:25] <rayh> Yep.
[14:11:53] <rayh> He said he had a breath taking moment when it homed on index for the first time.
[14:12:13] <rayh> That time between switch and index pulse.
[14:12:20] <cradek> heh
[14:12:27] <rayh> Was more than a half turn on the first axis.
[14:12:51] <rayh> Then relief, "Oh shit it works!"
[14:12:57] <cradek> I bet that will be handy. he has been going without it for a while!
[14:13:08] <rayh> Long time.
[14:13:26] <rayh> I'll bet he figures out spindle orient and tool change during fest.
[14:13:53] <cradek> he changes tools manually now?
[14:14:03] <rayh> Yes
[14:15:27] <cradek> orient is the most finicky part of the tool change on that machine - I wish there was a better way to do it
[14:15:39] <rayh> The casting at the top of the spindle is different on his machine that Roland's.
[14:16:26] <rayh> Some mazak machines had a regular encoder up there and the orient was a card on the spindle drive.
[14:16:31] <rayh> Those would be trivial.
[14:17:11] <cradek> do any machines have a heart cam and simple solenoid for orient?
[14:17:46] <rayh> Yes. The Mood Hydrapoints I had were a bit like that.
[14:17:59] <skunkworks_> our spindle has a cog.
[14:18:44] <rayh> Then they used the rotation resistance to hold the spindle while a motor turned the retension bar.
[14:19:36] <rayh> Some just used a flat on a wheel up on top.
[14:22:25] <skunkworks_> so - is it the act of the inputs switching getting back to the bus causing problems? or are the inputs switching causing the 8255 to screw up?
[14:22:36] <skunkworks_> still running without the cable plugged in.
[14:22:53] <SWPadnos> you all have defective 8255s if having the inputs switch is screwing them up
[14:23:13] <SWPadnos> I wonder if they're just really prone to latch-up or something
[14:23:19] <skunkworks_> like - even if the thing doesn't lockup with pull-downs.. will it lock up once you start switching the inputs?
[14:26:06] <SWPadnos> hmmm:
http://www.piclist.com/images/edu/drexel/ece/www/http/ECE/ECE-E431/latch-up/latch-up.html
[14:26:34] <SWPadnos> did somebody say a chip had gotten warm?
[14:28:02] <skunkworks_> I think tom burned up a chip
[14:28:47] <tomp2> skunkworks: i have 8 inputs of port A tied down, and strum across the inputs (like a guitar ) using a pull up, no lockups, and inputs on gui ripple
[14:29:11] <tomp2> i will retest the chip, maybe/maybe not
[14:29:21] <jepler> My money is still on the real flaw being in the management of the 8255-side data bus. from that page: "Sudden transients on the power or ground bus, which may occur if large numbers of transistors switch simultaneously, can drive the circuit into latchup."
[14:30:04] <rayh> I had similar dip 8255 chips on several ISA cards and had no problems with them failing.
[14:30:14] <SWPadnos> but reading shouldn't change any significant number of transistor states
[14:31:00] <skunkworks_> tomp2: inputs on the gui ripple? even though they are pulled up - the data changes on them?
[14:31:07] <tomp2> " strum across the inputs (like a guitar ) using a pull up, no lockups, and inputs on gui ripple"
[14:31:17] <jepler> no but when both the '245 and the 8255 are driving the 8255-side data bus you get a lot of current through 8255 -- it's not the number of outputs switching, but the current on them
[14:31:26] <tomp2> they are being pulled up in succession quickly
[14:31:58] <tomp2> anything into a computer will need some conditioning
[14:32:00] <SWPadnos> jepler, true. did you try plugging cables in when you had the data '245 removed?
[14:32:56] <jepler> I doubt I ever had a cable installed when a 245 was removed
[14:33:25] <SWPadnos> ok. if you think of it (and feel like it :) ), try that configuration some time
[14:33:41] <jepler> no, I'm done with that card
[14:33:44] <SWPadnos> heh
[14:34:05] <SWPadnos> bring it to Galesburg, we can hook up a scope to every pin on a '245 and see what happens
[14:34:13] <jepler> 21:34:10 <tomp2> i wrote the vb code for inputs and got hard lock
[14:34:13] <jepler> 21:34:10 <tomp2> that was with all inputs floating
[14:34:46] <SWPadnos> that points away from data bus management
[14:35:04] <SWPadnos> tomp2, try changing that pull-down to a pull-up SIP
[14:35:16] <jepler> two people both wrote straightforward drivers and both found that it locked up and maybe damaged chips in input mode
[14:35:31] <SWPadnos> that's true, it does sound like it's not worth the trouble
[14:35:33] <jepler> I don't much care if adding external pullups or pulldowns might fix it
[14:35:44] <jepler> there's a lot of emphasis on "might" IMO
[14:36:12] <skunkworks_> but it is such a pretty card...
[14:37:51] <SWPadnos> looks don't matter
[14:37:52] <tomp2> SWPadnos: my 1st attempt was a single p/u. so the test is to see if byte wide(port wide) p/u is beneficial, right?
[14:38:12] <SWPadnos> the fact that someone married me proves that ;)
[14:38:55] <SWPadnos> tomp2, yes - checking to see if the number of 1 bits on the data side matters
[14:39:20] <SWPadnos> I don't think it should, but it would show that the data side can handle any data
[14:39:20] <tomp2> i'd like to see some of the add-on cards... what they did to i/f hdwr to the card
[14:40:14] <tomp2> SWPadnos: will try later, right now have an INAV ctrl being tested on that box
http://www.inavcnc.com/
[14:40:21] <SWPadnos> heh, ok :)
[14:42:24] <tomp2> will try std mem test patterns, marching 1's etc
[14:43:53] <SWPadnos> oh hey - I saw an interesting thing on a machine yesterday. MDI mode had a multi-line editor, so you could enter several commands then execute them with the cycle start button
[14:45:46] <tomp2> Heidenhain MDI is a file & lets you edit that, run that and eventually save as file ( the real 'oops' programming system )
[14:46:11] <SWPadnos> right - this one showed a program number for the MDI editor
[14:46:20] <SWPadnos> presumably you could save/recall using that
[14:47:00] <skunkworks_> fanuc has a multi line mdi also
[14:47:09] <jepler> so somebody should write one for emc
[14:47:20] <skunkworks_> I rarely used it ;)
[14:47:21] <SWPadnos> sounds like a good plan
[14:47:41] <jepler> two ways: directly use nml to send multiple mdi commands in a burst; or use axis-remote so that the user can also preview mdi before executing it
[14:48:04] <SWPadnos> can you use axis-remote when axis is running?
[14:48:17] <jepler> yes, that's the only time its useful
[14:48:18] <SWPadnos> err - that probably was a stupid question :)
[14:48:18] <cradek> the BOSS has "mdi store" on the front panel. it appends the commands to the end of the program you forgot to clear before you started
[14:48:30] <SWPadnos> that's really useful! :)
[14:49:10] <cradek> it makes you enter a tool number and spindle speed too, even though it can't change the tool or set the spindle speed for you
[14:49:16] <SWPadnos> heh
[14:49:48] <SWPadnos> I think multiple MDI commands wouldn't work right - movements would all be exact stop, for instalce (I'm assuming it would work that way anyway)
[14:49:53] <SWPadnos> instamce
[14:49:55] <SWPadnos> gah
[14:49:58] <SWPadnos> coffee time
[15:00:53] <cradek> well the gui could just put them in a file and run it
[15:02:25] <rayh> Long years ago we had an EMC that did just that. A hidden file was sent all kinds of stuff that started up when you pressed run. Kinda scary at times.
[15:04:51] <skunkworks_> rayh: nice wiki. We are planning on coming down on wednesday this year so 'classicladder ladder thrusday' will be great!
[15:05:35] <rayh> Okay. Sounds good.
[15:06:56] <SWPadnos> rayh, do you have any modbus devices you can bring?
[15:09:26] <rayh> Sure. A couple of AD VFDs and a couple AD 106 PLCs
[15:10:21] <SWPadnos> great. I think a userspace modbus driver is possible, using some sort of description language like pyvcp to tell it how to talk to the device
[15:10:42] <SWPadnos> ... like pyvcp uses ...
[15:10:48] <rayh> Okay. I can kinda see the thinking.
[15:11:34] <SWPadnos> the main issue I see when thinking about it now is how to share a serial port among different devices
[15:12:06] <rayh> I'd favor a multi card like some of the mesa stuff.
[15:12:21] <rayh> a lot cleaner in my head.
[15:12:42] <rayh> nothing up there any more.
[15:13:06] <rayh> Although we could use the pymod stuff to create a 485 like header.
[15:13:34] <alex_joni> see you tomorrow guys
[15:13:45] <alex_joni> off to the hotel, and no wifi there (at least I don't care to pay for it ;)
[15:13:57] <rayh> Night alex
[15:13:57] <SWPadnos> heh. see you later
[15:14:45] <SWPadnos> id the description language is sufficient, it ouwld be possible to have separate device numbers using the same port
[15:14:47] <SWPadnos> if
[15:15:03] <SWPadnos> so you'd say "port /dev/ttyS0" somewhere, and only one of those is allowed
[15:15:13] <rayh> And for user space devices, why not.
[15:15:38] <SWPadnos> but later you could have something like several modules, with a base name, device number, and other stuff
[15:15:42] <SWPadnos> for each
[15:15:59] <SWPadnos> tha way you have one serial read/write function, but possibly many devices
[15:16:08] <SWPadnos> then load another instance for another port
[15:16:17] <SWPadnos> (possibly with multiple modules)
[15:16:25] <rayh> Internally route all the ttyS0 mods there.
[15:16:50] <SWPadnos> sort of - the separate module thing is only really necessary because the device number changes, and the HAL names will also likely change
[15:17:42] <rayh> Will loadrt v loaduser handle the two paths.
[15:17:58] <SWPadnos> there wouldn't be any RT involved
[15:18:03] <SWPadnos> it is serial after all
[15:18:15] <SWPadnos> oh - right
[15:18:18] <rayh> Someday we will have an rt path to serial devices
[15:18:35] <SWPadnos> there would be only one component name, like modbus_0
[15:18:37] <rayh> I hope
[15:18:53] <SWPadnos> but possibly many pin names, like VFD.speed and modio.out-01
[15:19:13] <SWPadnos> that may be possible, but it isn't necessary
[15:19:25] <SWPadnos> modbus is not RT
[15:19:58] <rayh> sure. If we've got two plcs out there modbus_0 and modbus_1
[15:20:21] <SWPadnos> serial errors cause packets to be discarded, so even if the data arrives "on time", it doesn't guarantee that the data arrives on time (since a retransmit is needed)
[15:21:04] <rayh> Are you thinking all of the modbus devices out there are named modio.out-xx
[15:21:21] <SWPadnos> those were sample pin names
[15:21:33] <SWPadnos> starting with VFD and modio, rather than modbus_0
[15:21:49] <SWPadnos> even though the component name might be modbus_0
[15:21:51] <rayh> and some way the module sorts them out
[15:22:01] <SWPadnos> any module can create a pin with any name
[15:22:13] <SWPadnos> to be confusing, I could have the modbus module create a pin called motion.something :)
[15:22:17] <rayh> Okay
[15:24:40] <rayh> What if there are more than one modbus device. Would a single module handle them both.
[15:25:01] <SWPadnos> that's what I was talking about. where were you? :)
[15:25:26] <SWPadnos> I think I'd have one component per serial port though, that should make things simpler
[15:25:35] <SWPadnos> since you can loadusr as many as you want
[15:26:30] <SWPadnos> component meaning a HAL userspace software module
[15:27:44] <rayh> okay then loadusr mycomponent ttyS0 dev1 dev2 devx
[15:28:16] <rayh> where dev1 ... is an outboard device on ttyS0
[15:29:04] <SWPadnos> I'm thinking more like pyvcp, where there's an XML (or other) file that describes what is on the serial bus, which registers need to be read/written, what the device number is, what the pins should be named, etc.
[15:29:24] <rayh> We may have to work up a diagram for this.
[15:29:33] <SWPadnos> so the load line is like "loadusr hal_modbus /dev/ttyS0 devices.xml"
[15:29:35] <SWPadnos> yes
[15:29:41] <SWPadnos> possibly with the port in the XML file
[15:29:56] <SWPadnos> so you'd have "loadusr hal_modbus devices.xml"
[15:30:02] <rayh> That breaks out the logical elements and links between them and their internal pins and params.
[15:30:30] <rayh> Okay. So the XML is charged with handling all of the details.
[15:30:36] <SWPadnos> like pyvcp: you can create an LED with whatever name you want (except it always starts with the component name, I think)
[15:30:39] <SWPadnos> yes
[15:31:24] <rayh> IMO we need to write the XML spec so that it includes instances and inheritance.'
[15:31:34] <SWPadnos> could be
[15:32:21] <SWPadnos> there's a configuration library I ran across recently that lets you specify config parameters in files, environment vars, or on the command line
[15:32:40] <SWPadnos> ((probably not important for this discussion)
[15:33:12] <SWPadnos> I'd like to be sure we don't go off having many different config file types, which is the sate we're in now
[15:33:32] <rayh> Right.
[15:33:36] <SWPadnos> (ini, xml, hal, scripts, nml, etc)
[15:33:49] <rayh> In my terminology these are all separate languages
[15:33:50] <SWPadnos> anyway, that's a big discussion of the type we should have at Fest :)
[15:33:53] <SWPadnos> yes
[15:34:10] <rayh> Each with their own semantics and syntactics.
[15:34:18] <rayh> and dictionary
[15:34:20] <SWPadnos> yep
[15:35:01] <rayh> And now there's stepconf. I love it but it's another one.
[15:36:24] <rayh> As much as I am hesitant to embrace xml it does permit the range of data we employ in configuration.
[15:36:48] <SWPadnos> well, we need something, and it would be ideal to not have to write it ourselves
[15:37:11] <rayh> I tried that with a couple of my early configurators.
[15:39:37] <rayh> This XML file does not appear to have any style information associated with it
[15:39:51] <SWPadnos> do you mean DTD?
[15:40:07] <rayh> something like that.
[15:40:16] <SWPadnos> what is "this XML file"? :)
[15:40:40] <rayh> my-mill.stepconf
[15:40:44] <SWPadnos> ah
[15:42:14] <rayh> Jeff did include a <stepconf> and </stepconf>
[15:42:24] <rayh> so that's a good start
[15:42:41] <SWPadnos> heh
[15:42:51] <SWPadnos> I don't think the file format was the main design goal ;)
[15:43:11] <rayh> No but it becomes a part of that big picture sort of config thing.
[15:44:00] <rayh> If we chose xml
[15:44:35] <SWPadnos> oh - it was in the boost libraries - that command-line option thing
[15:44:56] <rayh> Okay.
[15:51:22] <SWPadnos> damn, that was hard to find
[15:51:27] <SWPadnos> http://www.boost.org/doc/libs/1_35_0/doc/html/program_options.html
[15:51:45] <SWPadnos> sample code here:
http://www.boost.org/doc/libs/1_35_0/doc/html/program_options/tutorial.html
[15:52:45] <rayh> looking
[15:53:10] <SWPadnos> don't strain, it is C++ after all :)
[15:53:33] <rayh> k
[15:53:53] <rayh> I read that language about as well as Chinese
[15:54:21] <SWPadnos> heh. me too, when they start getting cinto it
[16:00:32] <rayh> Hey I like that.
[16:01:52] <SWPadnos> there's something else provided with KDE (and presumably something similar with gnome) that lets you use command line, environment, and multiple ini files (like system-wide inis, with the ability to tell the config system that certain parameters are not overridable in user configs)
[16:02:39] <rayh> So that's how they do "themes" and such.
[16:02:51] <SWPadnos> could be
[16:03:12] <rayh> So we stop talking about configs and begin talking about, "What's your emc theme?"
[16:03:19] <SWPadnos> heh
[16:03:37] <rayh> I think I like an XML file better.
[16:03:39] <SWPadnos> for something like a mail program, you could set the server as immutable, but let the users change other options (for example)
[16:03:50] <rayh> Gonna be easier to esplain to lucy.
[16:03:53] <SWPadnos> heh
[16:04:07] <SWPadnos> also easier to move complete configs around for troubleshooting purposes
[16:08:43] <rayh> Yes.
[16:09:05] <rayh> But still that is a pretty interesting bit of code interaction they have going.
[16:09:44] <SWPadnos> yeah - imagine being able to test by doing something like emc --maxaccel=0.5
[16:09:54] <jepler> xml is 1000x worse to hand-edit than .ini
[16:09:54] <SWPadnos> and having that override ini file values
[16:10:05] <SWPadnos> yes, that's possibly an understatement
[16:10:33] <rayh> Sure it is.
[16:10:48] <rayh> And if we move that way we will need parsers for all of it.
[16:10:58] <SWPadnos> one parser to rule them all
[16:11:16] <SWPadnos> the idea would be to have every program use the same calls to get configuration information
[16:11:17] <rayh> an uberparser
[16:12:10] <SWPadnos> we may not be able to get that far though, because parts of the system must be time sequenced (such as connecting pins only after the components are loaded and ready)
[16:12:44] <SWPadnos> and config info is usually not considered that way - it's generally flat data
[16:13:07] <rayh> That's where the "inheritance" comes in.
[16:13:40] <rayh> Or however you high power coders tend to think of it.
[16:13:48] <SWPadnos> heh
[16:16:01] <jepler> at least the inifile parsing library is already exposed to all the languages we use (C, C++, Tcl, Python)
[16:16:38] <jepler> is modbus configuration hard to express in a way that would fit in an inifile?
[16:16:45] <jepler> (that's what started this discussion, right?)
[16:17:21] <rayh> Yes it is.
[16:18:06] <SWPadnos> I think modbus configuration would be more like pyvcp configuration
[16:18:25] <SWPadnos> I'm not sure it would fit well with ini syntax, because the sections need to be defined within the file
[16:18:55] <rayh> I don't think there would be any issues with ini variables creating the modbus connection.
[16:19:15] <SWPadnos> modbus is too generic to define in an ini file
[16:19:18] <SWPadnos> you
[16:19:42] <rayh> But once you begin to describe the nature of the data you run into issues at both ends.
[16:19:54] <SWPadnos> it's inherently hierarchical - a given device has some parameters associated with it (device number at least)
[16:20:29] <SWPadnos> then you define HAL pins, which have certain registers/coils they connect to, and a HAL name
[16:20:36] <rayh> I'm going to shut up and listen a while.
[16:21:00] <SWPadnos> also type, which could be a bit (for coils), short, long, float (with associated parameters), etc
[16:21:30] <SWPadnos> since an ini file is flat, you either need a section for each pin, with redundant settings saying which device that pin goes to
[16:21:43] <SWPadnos> or you need to list all pins for a particular device within the device section
[16:22:06] <SWPadnos> you'd also need to list all device sections for a given port in the port section
[16:22:24] <SWPadnos> and of course you need to specify how many port sections there are too ...
[16:22:33] <SWPadnos> ini can be done, but it isn't pretty
[16:22:45] <SWPadnos> XML is known to be non-pretty, so we might as well use it :)
[16:25:15] <jepler> [MODBUS_0]
[16:25:15] <jepler> _device = /dev/ttyS0
[16:25:15] <jepler> _baud = 9600
[16:25:15] <jepler> # addr type gain offset
[16:25:15] <jepler> spindle-speed-out = 0x300 float 0.025 0.0
[16:25:17] <jepler> spindle-enable-out = 0x304 bit
[16:25:19] <jepler> spindle-direction-out = 0x305 bit
[16:25:50] <SWPadnos> I believe the current ini interface gives us no access to variables with unknown names
[16:26:16] <SWPadnos> so we'd need to know the spindle-speed-out, spindle-enable-out ... names a priori
[16:26:16] <jepler> then fix the library or use pin = spindle_speed_out ... and use the api to get each variable with the same name
[16:26:31] <SWPadnos> yep - thought of the pin= syntax as I was typing
[16:26:45] <SWPadnos> still need to know how many there are though, or get full section access
[16:26:55] <SWPadnos> or parameter arrays or something
[16:27:22] <SWPadnos> there also needs to be a size, since some values are made up from multiple registers
[16:27:31] <SWPadnos> and others are a fraction of a register
[16:27:57] <SWPadnos> also, there are separate address spaces - coils, contacts, registers (and I think another)
[16:28:17] <SWPadnos> with separate commands to read/write them
[16:28:34] <jepler> looks like you can just loop until the inifile.Find method tells you it didn't find an item
[16:28:37] <jepler> oops, real work is calling me
[16:28:51] <SWPadnos> me too, I suppose
[16:29:33] <rayh> Catch you guys later.
[16:29:39] <SWPadnos> see you
[19:43:38] <skunkworks_> wow - 3 computers now needed the rtai_smi
[20:03:30] <jepler> I suspect most sufficiently new intel machines do
[20:16:33] <skunkworks_> pent 3,4 class at the moment
[22:03:37] <dave_1> hey skunkworks ...
[22:05:23] <dave_1> anyone else had experience/results with smi?
[22:06:10] <skunkworks> you can load rtai_smi.ko manually to test.
[22:06:35] <dave_1> I understand it might help my latency
[22:06:52] <skunkworks> what kind of latency are you getting?
[22:07:04] <dave_1> 1.1 ms or so
[22:07:08] <skunkworks> yeck
[22:07:13] <dave_1> exactly
[22:07:13] <skunkworks> onboard video?
[22:07:23] <dave_1> 600 MHz intel P3
[22:07:37] <dave_1> no ... video card
[22:07:51] <skunkworks> what kind of video card?
[22:08:11] <dave_1> I really don't know .. been in there forever
[22:08:35] <dave_1> probably ati ... not nvidia
[22:08:39] <skunkworks> ok. do you know what chipset it has?
[22:08:50] <skunkworks> motherboard?
[22:09:14] <dave_1> not offhand ... intel Seattle board ...
[22:09:18] <skunkworks> do a lspci -v and see what shows up - normally it is towards the top. says 82something
[22:09:32] <dave_1> brb
[22:09:48] <dave_1> anything else I should try while I'm there
[22:10:12] <skunkworks> you could just try loading the rtai_smi.ko module for grins.
[22:10:23] <skunkworks> (then run the latency test)
[22:10:38] <dave_1> standalone
[22:11:15] <skunkworks> go to /usr/your-rtai-directory/modules then run sudo insmod rtai_smi.ko
[22:11:21] <dave_1> tnx
[22:11:34] <skunkworks> then run latency-test
[22:19:21] <skunkworks> * skunkworks almost sounds like he know what he is talking about.
[22:19:53] <skunkworks> are you running hardy or dapper?
[22:26:14] <skunkworks> if it is dapper - I think you might have to follow the directions on here to put the rtai_smi.ko file into your rtai modules directoy.. I don't think dapper had it by default.
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?FixingSMIIssues
[22:26:19] <dave_1> I'm back
[22:26:54] <skunkworks> whats the damage?
[22:27:28] <dave_1> there is a rtai_smi.ko under usr/realtime-2.xxxx-magma/modules but it would not load
[22:28:05] <skunkworks> so you're using dapper?
[22:28:06] <dave_1> my install is a brand new off Live CD which should be dapper ????
[22:28:34] <dave_1> took a look at the board and my memory is failing .... video is a nvidia
[22:29:07] <skunkworks> ok - then I would get the rtai_smi.ko module from the wiki and install it per directions here
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?FixingSMIIssues
[22:29:42] <dave_1> I grabbed the lspci output on usb but need to retrieve it before it does me any good.
[22:29:42] <skunkworks> seems to me alex_joni had said something about the rtai_smi that came with rtai was flawed.
[22:30:08] <dave_1> OK ...
[22:30:10] <skunkworks> heh - it would be nice to know your motherboard chipset from that
[22:30:28] <dave_1> give me a bit ...
[22:31:24] <skunkworks> but - you said nvidia? I wonder what driver it is using.. You may have video driver issues - I know it has been said that even the NV open source driver might give latency issues.
[22:32:09] <skunkworks> you might try changing it to vesa
[22:32:20] <skunkworks> (you may have 2 things to look at) :)
[22:47:33] <skunkworks_> I am going to have to leave. Good luck.
[22:53:13] <dave_1> darned ..... took too long to get back
[22:53:35] <dave_1> I'm printing out the smi instructions and will try them
[22:53:53] <dave_1> also will go looking for a better video card
[22:55:00] <dave_1> gotta to ... tnx
[23:05:39] <tomp2> I got the INAV ctrl up and running 3 axis, it really humms ( sounds like r2d2 :)
[23:15:38] <SWPadnos> so, here's a silly question: how can I use a bash script to start several processes in the background?
[23:15:57] <SWPadnos> I'd like something like for i in seq [1 10] ; do myprogram & ; done
[23:16:04] <SWPadnos> but of course the & doesn't work
[23:24:08] <dave_1> SWP ... really dumb question does bash know the difference between myprogram& and myprogram & ?
[23:29:37] <SWPadnos> sure, there's a space between them
[23:29:48] <SWPadnos> or it's one word
[23:31:45] <SWPadnos> a-ha. ; and & are both line terminators, so juse use for blah blah ; test & done