Back
[00:25:57] <jepler> probin: that is great news
[02:03:43] <jmkasunich_> hi guys
[02:04:07] <cradek> hi
[02:04:23] <jmkasunich_> I scared him away
[02:04:29] <cradek> probin: welcome, glad to hear your fpga card is going well
[02:17:30] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[02:59:11] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[06:45:25] <alex_jon1> alex_jon1 is now known as alex_joni
[12:04:12] <jepler> unfortunately, I think I spotted a bug on pluto_step last night
[12:04:38] <jepler> when running at the maximum frequency command, sometimes the step signal HIGH time is 2x as long just after a direction change
[12:05:02] <jepler> I fear that this may be 2 step pulses issued without an intervening LOW time
[12:08:14] <SWPadnos> is it always 2x, regardless of the HIGH time setting?
[12:08:54] <jepler> I didn't think to test that
[12:09:19] <SWPadnos> what setting have you been testing with?
[12:09:52] <jepler> smallest possible (1.6uS?) step HIGH and LOW time
[12:10:35] <jepler> I don't remember what the scope settings said, but if I understood right it was displaying captures of single events, not envelopes or averages
[12:10:44] <SWPadnos> ok, that's still multiple cycles of the internal FPGA clock though, right?
[12:12:15] <jepler> the FPGA clock is 40MHz (25ns), but the step generators use a "divided by 64" (1.6uS) signal for everything
[12:12:34] <SWPadnos> oh. in that case it may be a single extra clock cycle glitch
[12:12:41] <SWPadnos> rather than 2 stape
[12:12:43] <SWPadnos> steps
[12:12:52] <jepler> nothing in the step generator should be having transitions except at the 1.6uS rate
[12:14:35] <jepler> the next things I'll test are longer step HIGH times, and using the "signal present for more than" trigger mode to see if there are any 3.2uS glitches except at direction changes
[12:16:10] <SWPadnos> set the HIGH time to 3.2 uS, and trigger on anything longer than 4.8 uS (+ a little)
[12:16:30] <SWPadnos> if you get no triggers, then you know it's a single cycle problem
[12:17:13] <SWPadnos> then, go to a 3.2+ uS trigger, to see if it's gone with higher HIGH settings
[12:17:43] <SWPadnos> (it could be that the minumum step size is 2 for some reason, not that you always get N+1)
[12:21:12] <jepler> I'm not 100% sure I follow all that
[12:21:16] <jepler> and I have to work all day before I get to play with it more anyway
[12:21:23] <SWPadnos> heh. me too :)
[12:28:57] <jepler> I think it's most likely that it's 2 step pulses without an intervening LOW time because the LOW time is ensured only by a limit on the frequency commands given by the HAL driver
[12:29:15] <SWPadnos> ok. that may be the key
[12:30:00] <jepler> like the HAL software step generator, the accumulator is supposed to pause counting during a direction change
[12:31:51] <SWPadnos> does it correctly wait the DIRHOLD (or DIRSPACE)?
[12:32:08] <alex_joni> hi guys
[12:32:07] <SWPadnos> whichever one is the "time after reversal before generating a step"
[12:32:09] <SWPadnos> hi Alex
[12:32:20] <jepler> SWPadnos: yes
[12:32:24] <alex_joni> dirhold I think
[12:32:26] <SWPadnos> ah. ok
[12:32:38] <jepler> another corner cut: there is a single DIRTIME that is enforced before and after a direction change
[12:32:57] <SWPadnos> you need a 7i43 ;)
[12:34:31] <jepler> I suppose I do
[12:36:32] <SWPadnos> the single DIRTIME isn't a big deal, since direction changes only happen at slow/no speed
[12:36:49] <SWPadnos> even with a 20 uS hold time, it's only doubled to 40 us
[12:46:28] <jepler> yeah, for applications with any acceleration it's not a big burden
[12:51:18] <jepler> (assuming it's not buggy anyway)
[13:01:38] <alex_joni> hi ray
[13:02:22] <rayh> Hi alex
[13:03:12] <alex_joni> what's new?
[13:26:39] <jepler> rayh: hi ray.
[13:38:14] <alex_joni> jepler: ever looked at comedi?
[13:38:27] <jepler> alex_joni: no, I only know it's some acronym or name associated with rtai
[13:40:03] <SWPadnos> I just took a look there yesterday (again)
[13:40:36] <SWPadnos> they have a kernel and userspace interface to their drivers, which I thought could be usefull to look at
[13:41:39] <alex_joni> jepler: they support a wide range of data aquisition boards
[13:41:47] <jepler> alex_joni: interesting
[13:42:16] <jepler> do you think there might be a use for this in the context of emc, or for some other thing I've mentioned?
[13:43:04] <jepler> or maybe for something you have in mind ? ;-)
[13:43:51] <SWPadnos> scope scope scope
[13:48:39] <jepler> badger badger badger
[13:48:50] <SWPadnos> mushroom MUSHROOM!
[13:49:17] <jepler> when shopping for a new scope, I dismissed any PC-attached data acquisition cards because I assumed the software would be windows only .. maybe I was wrong.
[13:49:28] <jepler> on the other hand, the two GUI apps linked from the main comedi site are ugly ugly ugly
[13:50:00] <SWPadnos> standalone scopes have much much (much!) better triggering options, and the UI is almost universally better
[13:50:56] <jepler> I also imagine '80s HP test equipment has to be better quality than '00s non-name USB capture equpment
[13:51:07] <SWPadnos> I'm sure of it
[13:51:33] <SWPadnos> if you can get '60s HP test equipment, it's even better
[13:51:36] <jepler> hah
[13:51:53] <jepler> I don't know what year the old tek 465b was
[13:52:01] <SWPadnos> the old signal generators had true frequency output, not something that "averages out" correct
[13:52:18] <rayh> HI jepler SWPadnos
[13:52:19] <SWPadnos> these days, with PLLs, you only get something that's statistically correct
[13:52:22] <SWPadnos> hi rayh
[13:52:25] <rayh> was away in a meeting
[13:52:29] <SWPadnos> ugh
[13:52:46] <SWPadnos> I think I may have found a good embedded PC for EMC
[13:53:04] <SWPadnos> I'll be getting 2 today, so I'll have test info later on
[13:53:09] <alex_joni> jepler: I was thinking of a HAL wrapper around the comedi drivers
[13:53:51] <rayh> Oh let me know how the boards test out and what they cost.
[13:54:15] <jepler> alex_joni: go for it! that'll also force us to tackle the issue where HAL driver "A" requires non-HAL module "B" to be loaded, which lurks for users of rtai_net and rtai_serial type devices too
[13:54:22] <jepler> alex_joni: do you have some comedia-supported hardware now?
[13:55:25] <jepler> s/comedia/comedi/
[13:56:06] <SWPadnos> rayh, will do. I think the board itself is $450 in singles, plus storage, CPU, and RAM - so around $600 complete
[13:56:28] <SWPadnos> but it's from an industrial supplier, so hopefully the parts won't change much from day to day
[13:56:33] <rayh> Okay.
[13:56:39] <alex_joni> jepler: unfortunately no
[13:56:42] <SWPadnos> did you ever get that other one to boot?
[13:56:56] <rayh> That jetway itx is supposed to be in production for 4+ years.
[13:57:09] <rayh> Sent em back
[13:57:14] <SWPadnos> uh-huh. did the second one ever boot? :)
[13:57:19] <alex_joni> did you look at the hardware the guy who was in here yesterday uses?
[13:57:30] <rayh> nope
[13:57:31] <alex_joni> probin...
[13:57:32] <SWPadnos> heh
[13:57:37] <rayh> ??
[13:57:39] <SWPadnos> www.atelierrobin.net
[13:57:42] <SWPadnos> the ARCNC100
[13:58:04] <alex_joni> also ITX iirc
[13:58:25] <SWPadnos> yep - looks like ITX + a custom FPGA card
[13:58:34] <alex_joni> http://atelierrobin.net/mini-itx.jpg
[13:58:41] <SWPadnos> mini ITX, from the image name
[13:58:45] <alex_joni> http://atelierrobin.net/PCIO100.jpg
[13:58:58] <alex_joni> Xilinx Spartan
[13:59:14] <alex_joni> XC3S500E
[13:59:47] <alex_joni> "Runs EMC 2.x standalone"
[14:00:17] <SWPadnos> hmmm. I don't see the output card for that - I'm assuming it plugs into the card-edge connector on top
[14:01:18] <rayh> almost the same mini itx I've tested here.
[14:02:26] <jepler> yeah I also assume that's where the outputs are
[14:02:51] <SWPadnos> this is the one I've got coming:
http://www.acrosser.com/Product/Embedded%20PC/Embedded%20Systems/mbedded_system_celeronM_ar-es0892.html
[14:03:04] <SWPadnos> there are others that don't have the PCIe and PCI slots
[14:03:07] <rayh> Ah I saw that. Looked really good.
[14:03:38] <SWPadnos> that case has a 120W power suplpy built in, and the qty. 1 cost is $557 (+CPU/RAM/HD)
[14:03:44] <SWPadnos> supply
[14:04:29] <SWPadnos> I need a 5i22 in my system, so I went with that one. Also, if the integrated graphics screw things up, I can stick in a cheap Nvidia PCIe video card (if I need video at all)
[14:05:14] <rayh> Sure. I've not had any rt issues with what they call the unichrome onboard.
[14:05:28] <SWPadnos> excellent - I hope to have the same lack of problems
[14:05:55] <SWPadnos> it's bad when a 2000A power supply goes tits-up due to my controller :)
[14:06:07] <alex_joni> "I have developed a real time protocol for controlling machines via
[14:06:09] <alex_joni> the USB port on a Windows Xp based computer. "
[14:06:14] <rayh> Yuck.
[14:06:21] <jepler> alex_joni: sure you have
[14:06:24] <SWPadnos> heh
[14:06:30] <alex_joni> jepler: not me.. I just found that :P
[14:06:45] <jepler> SWPadnos: is this the same project you were talking about back at fest, where you were hoping to have 16 or 32 PIDs running at a few kHz?
[14:06:49] <rayh> There is a guy in the netherlands that does it with parts of emc.
[14:06:52] <alex_joni> "It has almost, +-20ms, real time on screen graphical animation
[14:06:54] <alex_joni> going on when the tool path is being executed on the machine. "
[14:06:58] <SWPadnos> yes, but it's morphed quite a bit
[14:07:28] <jepler> SWPadnos: I thought for awhile it was shelved, or at least the HAL part of it
[14:07:35] <alex_joni> jepler: now we have a politically correct definition of real-time (+/- 20 ms)
[14:07:40] <SWPadnos> jepler, yep, that's accurate
[14:08:03] <SWPadnos> alex_joni, that's more or less within one frame (and well under a frame time for cinema)
[14:08:41] <jepler> I bet you could have a tolerable low-speed machining system with 20ms position commands
[14:09:08] <SWPadnos> USB can be great for any system that doesn't need feedback fro control
[14:09:11] <SWPadnos> for
[14:09:26] <SWPadnos> e.g. G-Rex
[19:17:55] <SWPadnos> cradek, I don't see how your changes would have affected parameter 5220
[19:18:02] <cradek> they didn't
[19:18:05] <SWPadnos> ok
[19:18:06] <alex_joni> he didn't say they did
[19:18:13] <cradek> it made a bunch more required fields in the var file
[19:18:13] <alex_joni> that's just the error that pops up
[19:18:33] <cradek> the interp incorrectly adds them I guess, I didn't dig into it too much
[19:18:33] <SWPadnos> ok, so it's a bogus message
[19:18:47] <SWPadnos> ?
[19:18:55] <cradek> well I think the interp generates a new var file with all "required" fields set to 0
[19:19:00] <cradek> ... which is invalid since #5220 can't be 0
[19:19:22] <cradek> please fix it better if you care
[19:19:35] <cradek> (I just put proper var files in all the configs)
[19:19:46] <cradek> if(#5220==0) #5220=1;
[19:19:50] <cradek> ^ one obvious trivial fix
[19:19:55] <SWPadnos> hmmm. do you suppose that may be happening even if 5220 is 1 (writing the file due to missing UVW params, but still writing 0 to 5220)
[19:19:59] <SWPadnos> heh
[19:20:19] <cradek> you now know everything I know, sorry
[19:20:23] <SWPadnos> damn
[19:23:18] <skunkworks> there was a random bug that somehow set it to 0.. It happened to me once but I could not reproduce it..
[19:25:00] <cradek> I have not seen that for years now
[19:25:42] <cradek> I think it was tkemc actually (it reads and writes to the var file itself, so does the interpreter, neither of them has any locking scheme)
[19:26:52] <cradek> but that's only speculation, I never tried to find/fix it
[19:31:17] <alex_joni> one of these days I'll make it all work through NML
[19:33:30] <SWPadnos> on a separate note, I've done some testing on that embedded PC, and it looks - unspectacular
[19:33:49] <alex_joni> what's that supposed to mean?
[19:33:56] <SWPadnos> latencies are usually pretty good, but max_latency is ~12000-13000
[19:34:03] <SWPadnos> not very good?
[19:34:05] <alex_joni> that's ok I guess
[19:34:16] <alex_joni> what CPU freq?
[19:34:16] <SWPadnos> it's not too great for a 1.8 GHz processor, I think
[19:34:20] <alex_joni> eek
[19:34:29] <alex_joni> might get the same from a 800 C3
[19:34:33] <SWPadnos> it's an Intel board as well
[19:34:52] <alex_joni> no SMI issues or such I hope
[19:34:53] <SWPadnos> maddash had reported good luck with a very similar chipset, but no luck here
[19:34:56] <SWPadnos> I don't think so
[19:35:25] <SWPadnos> I actually couldn't get any video from the onboard graphics (at all - no boot), luckily I had gotten an Nvidia card just in case
[19:36:56] <SWPadnos> there was an SMI-like latency anomaly once. something like 500-600 ms latency at one point
[19:37:06] <SWPadnos> and this was without X running
[19:37:07] <alex_joni> yuck
[19:37:23] <SWPadnos> I had just done a networking restart though, so that may have something to do with it
[19:37:41] <SWPadnos> (hard to tell when you have to switch terminals to see, and there's no backscroll)
[19:37:50] <alex_joni> yuck.. fb?
[19:37:56] <SWPadnos> no, text mode (I think)
[19:38:07] <SWPadnos> it's an Intel 965, so I'm not sure it's supported well by Dapper
[19:38:13] <SWPadnos> (I think it's a 965)
[19:38:20] <alex_joni> I had a SBC on which I had to enable FB and disable scrollback
[19:38:29] <alex_joni> in order to get proper things displayed
[19:38:30] <SWPadnos> hmmm
[19:38:47] <cradek> some of the new intel chips have incompatible PIDE (including cdrom)
[19:38:58] <SWPadnos> actually, I was using the 7300 at the time, since I never got any display from the onboard video
[19:39:21] <SWPadnos> I used my laptop drive with EMC2+dapper on it :)
[19:39:36] <SWPadnos> so I didn't even need to boot from CD
[19:39:53] <SWPadnos> but this was worse - no BIOS POST screen at all from onboard video
[19:39:56] <skunkworks> when did ide change to pide.. Do many poeple got confused?
[19:40:04] <skunkworks> to
[19:40:14] <cradek> err PATA
[19:40:23] <SWPadnos> PATA/IDE :)
[19:40:32] <skunkworks> right ;)
[19:40:48] <alex_joni> PITA?ADE
[19:41:04] <SWPadnos> I'm also kind of bummed because I've found the perfect A/D chip - 16 bits, 6 channels, simultaneous sampling, 250 KHz
[19:41:11] <SWPadnos> not available until the end of the month :(
[19:41:27] <alex_joni> expensive?
[19:41:36] <SWPadnos> $25.80 in low qty
[19:41:42] <SWPadnos> cheap, for what it is
[19:42:44] <alex_joni> * alex_joni agrees
[19:42:50] <skunkworks> and what your going to make on the project ;)
[19:43:02] <SWPadnos> Analog Devices AD7656, in case you want to know
[19:43:08] <SWPadnos> heh
[19:43:19] <SWPadnos> I make more if parts are available
[19:43:34] <SWPadnos> I guess I should go check the core duo unit. bbl
[19:45:22] <skunkworks> can you isolate one of the 'processors' on a core duo?
[19:47:20] <cradek> skunkworks: yes
[19:48:10] <SWPLinux> cradek: which was the usable SMP kernel? 2.6.17 or 2.6.20?
[19:48:15] <SWPLinux> I guess it would be .20
[19:48:39] <cradek> they both work but .17 had a keyboard issue (for me) and .20 has no bootsplash
[19:48:47] <SWPLinux> ah
[19:49:07] <SWPLinux> I might as well download half the files in /experimental instead of all of them :)
[19:53:45] <SWPLinux> hmmm. presumably linux-source contains everything in linux-headers?
[19:54:27] <alex_joni> yes
[19:54:38] <alex_joni> but you still want to install linux-headers
[19:54:45] <SWPadnos> ok
[19:54:45] <alex_joni> if you want to compile & distribute stuff
[19:54:51] <SWPadnos> ah
[19:54:55] <alex_joni> it's better to compile against linux-headers
[19:55:01] <SWPadnos> I'll likely want to compile
[19:55:01] <alex_joni> makes it for less stuff to distribute
[19:55:09] <SWPadnos> right
[19:57:32] <alex_joni> SWPadnos: ADS7862Y
[19:57:46] <alex_joni> 12 bit, 2+2 channels, 500 ksamplings
[19:58:10] <SWPadnos> that's nice, but 12 bits kills it for this project
[19:58:25] <alex_joni> I see
[19:58:37] <SWPadnos> that's a burr-brown (TI) part, right?
[19:59:25] <alex_joni> yup
[19:59:44] <awallin> just in case you're not reading #emc, Stuart Stevenson sent me some pics of his Dah-Lih conversion
http://www.anderswallin.net/2007/08/dah-lih-emc2-conversion/
[21:07:44] <SWPLinux> err - I have 2.6.20 running on this machine (woohoo), but I can't run the latency test
[21:07:57] <SWPLinux> http://pastebin.ca/643510
[21:08:23] <SWPLinux> when I ./run the latency test, all the /dev/rtf? files go away. do I need to set up some udev thing?
[21:45:55] <SWPLinux> argh. and I can't run EMC either
[21:50:46] <SWPLinux> here's a compile error I have gotten a couple of times:Syntax checking python script pumagui
[21:50:46] <SWPLinux> Traceback (most recent call last):
[21:50:48] <SWPLinux> File "<string>", line 1, in ?
[21:50:50] <SWPLinux> File "emc/usr_intf/axis/scripts/axis.py", line 3145
[21:50:52] <SWPLinux> widgets.spinoverride.configure(from=min_spindle_override, to=max_spindle_override)
[21:50:55] <SWPLinux> ^
[21:50:57] <SWPLinux> SyntaxError: invalid syntax
[21:51:01] <SWPLinux> well, I guess it's a syntax check error, but still
[21:52:41] <jepler> what version of emc is this axis.py from ?
[21:52:54] <SWPLinux> cvs today
[21:52:59] <jepler> widgets.spinoverride.configure(to=max_spindle_override)
[21:53:05] <jepler> the closest line to that in my copy ^^^
[21:53:25] <SWPLinux> widgets.feedoverride.configure(to=max_feed_override)
[21:53:27] <SWPLinux> widgets.spinoverride.configure(from=min_spindle_override, to=max_spindle_override)
[21:53:32] <SWPLinux> those are lines 3144 and 3145
[21:54:00] <SWPLinux> hmmm. maybe it didn't update correctly - CVS says "M"
[21:54:19] <jepler> "from" is a python reserved word
[21:54:32] <jepler> "M" means you modified it -- trying to add a minimum spindle override number?
[21:54:48] <SWPLinux> couild have been
[21:54:49] <jepler> to use the -from of a tk widget, write "from_=min_spindle_override" (see the added _ in from_)
[21:54:52] <SWPLinux> -i
[21:55:29] <SWPLinux> U just deleted and updated. we'll know what happens in a few seconds
[21:55:39] <SWPLinux> it did work once today, that's the interesting thing
[21:55:45] <jepler> huh, I see that MIN_SPINDLE_OVERRIDE was listed in the 2.1.0 release notes...
[21:55:46] <SWPLinux> at least, I'm pretty sure it did
[21:56:40] <SWPLinux> I wonder how much this laptop hard drive is slowing things down
[21:57:45] <SWPLinux> whoah. it may be time for a clean checkout
[21:58:11] <SWPLinux> I get endless "waiting for s.axes != 0 -- Had to poll again..."
[21:58:42] <jepler> unfortunately, that message may obscure the actual emc startup failure
[21:58:51] <SWPLinux> what was the CVS incantation to reset to TRUNK/HEAD and overwrite anything?
[21:58:57] <jepler> you might want to remove the print or increase the wait time from 100 times per second..
[21:58:56] <SWPLinux> -AC or something
[21:59:07] <jepler> cvs -H up
[21:59:29] <SWPLinux> err
[21:59:32] <SWPLinux> I have no -H available
[21:59:36] <jepler> -A to go back to TRUNK from another tag; -C to get rid of modified files (but often in my experience that fails)
[21:59:52] <jepler> I was playing "teach a man to fish", but I guess it didn't work :-P
[22:00:10] <jepler> for me, -C often fails to get rid of the old file, and prints some errors
[22:00:11] <SWPLinux> heh
[22:00:16] <jepler> then I give up and get a fresh checkout instead
[22:00:17] <jepler> bbl
[22:00:22] <SWPLinux> sorry - food deprived and overheated :)
[23:55:46] <SWPLinux> hmmm. anybody notice that isolcpus is a map, not a quantity?
[23:56:27] <SWPLinux> actually it's a list, not a map
[23:57:31] <SWPLinux> I guess I should reboot and try it :)
