Back
[13:05:46] <steves_logging> steves_logging is now known as steve_stallings
[13:07:19] <steve_stallings> I have been sort of following a project called USB4RT. It aims to provide USB services that work with RTAI, but seems to use an abstraction layer called RTDM. Anyone know more about USB4RT or RTDM?
[13:16:08] <cradek> I remember someone mentioned it on one of the emc lists, but I don't know anything about it
[13:20:03] <steve_stallings> http://developer.berlios.de/projects/usb4rt/
[13:20:26] <steve_stallings> Seems from the mailing list that it may be still alive... 8-)
[13:20:55] <steve_stallings> They mention using RTDM as an abstraction layer into the RTOS.
[13:22:34] <steve_stallings> Was wondering if RTDM was a known standard for use with RTAI. My seach on RTDM has too many hits to analyze.
[13:26:00] <alex_joni> RTDM (Real Time Driver Model)
[13:26:05] <steve_stallings> Ahhh, found something meaningful. RTDM = real time driver model. See:
http://www.captain.at/rtai-rtdm-serial-port-example.php
[13:26:20] <alex_joni> steve_stallings: :)
[13:26:53] <alex_joni> steve_stallings: it seems to me RTDM is xenomai specific
[13:27:12] <steve_stallings> So RTDM and the abstraction used by EMC2 are not quite equavilent.
[13:27:26] <steve_stallings> xenomai ?? kernal version ??
[13:28:04] <alex_joni> no, xenomai is another RT OS
[13:28:16] <alex_joni> it was part of RTAI as a branch initially, but the parted
[13:28:23] <alex_joni> it was called RTAI/fusion initially
[13:28:35] <alex_joni> steve_stallings: no, not equivalent
[13:28:43] <alex_joni> "RTDM has been merged into Xenomai (former RTAI/fusion branch) on 2005-07-20 and comes with official releases since 2.0 (actually, since fusion-0.9). There is currently ongoing work to integrate it in RTAI as well (upcoming release 3.3). The RTDM layer for Xenomai is implemented as a skin. Xenomai also comes with a full-featured serial devices driver for RTDM (see 16550A in the drivers directory). Further information can be found in the API documenat
[13:29:52] <alex_joni> steve_stallings: by the first looks at it, it's not really usefull for emc2 :)
[13:30:19] <steve_stallings> Not even if emc2 wants to talk to USB devices?
[13:31:13] <steve_stallings> That is talk to USB devices in real time...
[13:33:10] <alex_joni> not usefull for emc2 drivers
[13:33:25] <alex_joni> it's usefull for traditional drivers (like serial. USB, ethernet, etc)
[13:33:45] <alex_joni> so it's only partly interesting for emc2 (to be used as an existing medium), but not something to integrate into emc2
[13:35:35] <steve_stallings> OK, I need a roadmap. There was recently talk of adding ethernet via RT-Net interfaced to HAL. I am hoping for similar for USB.
[13:36:12] <alex_joni> steve_stallings: it's easy to add a new interface
[13:36:23] <alex_joni> the problem with interfaces is that you need some protocol
[13:36:26] <steve_stallings> Like ethernet, USB will require non-network, standalone message handling.
[13:36:33] <alex_joni> and parts talking the same language :)
[13:36:52] <alex_joni> for RT-Net, there will be 2 HAL modules talking to each other over the RT-net
[13:36:59] <alex_joni> each one on a different PC
[13:37:05] <alex_joni> thus linking 2 HAL's together
[13:37:34] <steve_stallings> USB hardware is quite complicated, more so than ethernet, and I was hoping to have that hard part done already.
[13:37:47] <alex_joni> I agree
[13:39:52] <steve_stallings> It will also have the same issue as the parallel port. The OS will have to not use the USB so as to not interfere with real time.
[13:41:01] <alex_joni> right
[13:41:12] <alex_joni> probably you need to deactivate a full controller (more than one port)
[13:41:26] <steve_stallings> likely
[13:42:01] <steve_stallings> and that would be a bummer if keyboard and mouse were USB
[13:42:59] <alex_joni> usually there are 2-3 controllers in one PC
[13:43:13] <alex_joni> in a modern one at least
[13:43:20] <alex_joni> but what are you trying to accomplish?
[13:43:38] <alex_joni> why do you need RT USB?
[13:44:18] <steve_stallings> external stepper/servo interface for slotless PC or laptop use
[13:44:31] <alex_joni> I can see that.. but why RT?
[13:45:02] <alex_joni> you won't get packets faster than 1msec I think, but for a servo loop that's enough
[13:45:16] <steve_stallings> depends, RT needed if PID remains in PC, maybe not if PC sends splines to external
[13:45:48] <steve_stallings> USB would be limited to 500 Hz PID is everything works right using ISO mode
[13:46:34] <steve_stallings> 500 Hz may be ok for "hobby" use but serious machines are already using 2K and above
[13:47:15] <alex_joni> right, so that means PID on the device, and only canon calls through the USB
[13:47:30] <steve_stallings> that is one way to skin the cat 8-)
[13:47:33] <alex_joni> but I don't see that needing RT USB, it can go through normal USB
[13:48:01] <alex_joni> as it is now, you could probably connect the G101 to emc through a stadard USB
[13:48:11] <steve_stallings> yes, normal USB is fast enough for canon calls, but now device has to support a much more comples command set
[13:48:14] <alex_joni> standard even
[13:48:32] <steve_stallings> complex even
[13:49:16] <steve_stallings> and the interface to canon calls does not yet pass thru HAL does it?
[13:49:31] <alex_joni> no, and it will probably never do
[13:50:08] <steve_stallings> will I can say the same for NML, not going to be implemented in any external device that I feel like tackling
[13:50:39] <alex_joni> that is probably a bit too much overhead I agree
[13:52:04] <alex_joni> although a small ARM board with linux on it might be great
[13:53:53] <steve_stallings> we were seriously considering ARM, but at the chip level inside our device
[13:54:36] <steve_stallings> running Linux, even embedded, is more that I had in mind though
[14:06:38] <alex_joni> steve_stallings: you can always use a 'simple' OS with net support
[14:06:41] <alex_joni> like www.ethernut.de
[14:13:20] <steve_stallings> the ARM version of NutOS might be ok, like BSD vs. GNU license for this case, need to see if using free NutOS without buying hardware is ok
[14:16:38] <steve_stallings> well.... it looks like the ARM stuff is still beta....
[14:18:56] <steve_stallings> oops, time to hide, the AVR lover is here....
[14:19:13] <SWPadnos> PIC-head
[14:19:22] <SWPadnos> :)
[14:19:33] <steve_stallings> nope, pushing ARM this time 8-P
[14:19:39] <SWPadnos> hey - thanks for that lathe pointer - the machines are sweeeet!
[14:19:45] <cradek> do PICs have uarts yet?
[14:19:56] <SWPadnos> the PIC doesn't have a functional carry bit
[14:20:09] <SWPadnos> but they do have UARTS
[14:20:14] <cradek> oh good
[14:20:26] <cradek> I've waded through bit-banging pic code one too many times
[14:20:37] <steve_stallings> some PIC have UARTs and even other magic things, but they remain strange beasts
[14:20:49] <SWPadnos> and carry-less
[14:21:14] <SWPadnos> I'd go with the Atmel AT91RM7X128 or 256 for ARMs
[14:21:15] <cradek> can you program modern pics with gcc now?
[14:21:16] <steve_stallings> still easier to use than Lab View (bait !!!)
[14:21:23] <SWPadnos> fscker
[14:21:24] <cradek> hahaha
[14:21:41] <SWPadnos> at least you can tellwhat a PIC is doing
[14:22:01] <SWPadnos> oops - AT91SAM7X128/256
[14:22:17] <steve_stallings> like ARM because of advanced hardware support for trace using Keil IDE/debugger
[14:22:33] <SWPadnos> I think that's what I'll base my G-Rex CPU module on
[14:22:53] <alex_joni> SAM7 is sweet
[14:23:03] <SWPadnos> my devkit should have been here by now :(
[14:23:07] <alex_joni> it even has DMA ;)
[14:23:24] <SWPadnos> I also like the looks of the AVR32, but it's a bit expensive compared to the ARMs
[14:23:25] <steve_stallings> ST and Philips also do some real nice ARM stuff
[14:24:00] <SWPadnos> the SAM7x is pretty amazing - $12 in single quantity, and it has USB2, 10/100 ethernet, and a lot of other stuff (such as 128k flash)
[14:24:45] <steve_stallings> shame that SAM7 and the ST device include the MAC but not the PHY
[14:24:46] <cradek> wow ethernet
[14:24:58] <SWPadnos> yeah - just about nobody includes the PHY
[14:25:10] <SWPadnos> cradek, that's why I like it for a motion controller :)
[14:25:14] <steve_stallings> PHY is almost as big and expensive as the CPU
[14:25:36] <SWPadnos> or the AVR32, which also has ethernet (dual, actually), plus an LCD controller (2kx2k max resolution)
[14:25:52] <SWPadnos> but it's $25 or so
[14:30:32] <SWPadnos> hmmm - the cheapest PHY I can find (at digikey) is $4.73 in singles, $2.74/100, made by NS (and a 48-LQFP ;) )
[14:50:28] <alex_joni> http://oss.kernelconcepts.de/maemo/ <- that's nice ;)
[14:51:06] <SWPadnos> cool
[14:52:29] <SWPadnos> hmmm - wlan, bluetooth and USB2 device connectivity
[14:52:36] <alex_joni> The processor in the device is a 220-MHz, ARM9-based Texas Instruments (TI) OMAP 1710.
[14:52:37] <SWPadnos> no RT capable interfaces ;)
[14:52:45] <alex_joni> there is RTAI for ARM
[14:53:03] <alex_joni> RTAI supports several architectures:
[14:53:04] <alex_joni> x86 (with and without FPU and TSC)
[14:53:04] <alex_joni> x86_64 (beta)
[14:53:04] <alex_joni> PowerPC (recovering)
[14:53:04] <alex_joni> ARM (StrongARM; ARM7: clps711x-family, Cirrus Logic EP7xxx, CS89712, PXA25x)
[14:53:07] <SWPadnos> RTAI for welan, bluetooth, or USB2 would be the issue ;)
[14:53:11] <SWPadnos> wlan, that is
[14:55:06] <SWPadnos> hmmm - $359.99
[14:55:14] <alex_joni> a bit much ;)
[14:55:26] <SWPadnos> I agree (though it is nice and small)
[14:56:12] <alex_joni> I like this one better:
http://www.olimex.com/dev/sam7-ex256.html
[14:56:46] <SWPadnos> the display isn't quite as nice ;)
[14:57:01] <alex_joni> almost ;)
[14:57:35] <alex_joni> the price is right though
[14:57:37] <alex_joni> SAM7-EX256 development board with AT91SAM7X256, LCD, Audio, CAN, USB, Ethernet 10/100 USD $115.95
[14:57:40] <SWPadnos> I like this one better:
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3918
[14:57:58] <SWPadnos> but the price is worse ;)
[14:59:11] <alex_joni> how much?
[14:59:16] <SWPadnos> $500
[14:59:30] <SWPadnos> but you can get it from DigiKey for $544
[14:59:32] <SWPadnos> :)
[14:59:55] <alex_joni> ouch
[15:00:23] <SWPadnos> dual ethernet, QVGA display, 256M SD card, and Linux devkit :)
[15:00:41] <alex_joni> heh AC97
[15:00:43] <SWPadnos> plus a binch of other stuff
[15:00:52] <alex_joni> still kinda much
[15:00:57] <alex_joni> you can get 2 PC's for that money
[15:01:08] <alex_joni> or a good one + display
[15:01:49] <SWPadnos> heh
[15:02:29] <SWPadnos> I may need to make a 12-camera synchronizer this week. I'm toying with the idea of using a smallPC and HAL
[15:02:35] <SWPadnos> small PC, that is
[15:03:28] <SWPadnos> I'd like 10-microsecond accuracy, bit I think I could get away with 100 microseconds
[15:05:29] <alex_joni> you can do 10 usec easily
[15:05:36] <alex_joni> how do you want to output the stuff ?
[15:05:53] <SWPadnos> I'd think so. it's just two byte reads and two byte writes, plus a very little math
[15:06:12] <alex_joni> read/write from where?
[15:06:25] <SWPadnos> parport or MESA card
[15:06:45] <SWPadnos> I need 24 I/Os for the cameras, plus one or two for other stuff (like a trigger)
[15:07:17] <alex_joni> so either 2-3 parports
[15:07:19] <alex_joni> or a MESA
[15:07:22] <SWPadnos> yep
[15:07:31] <alex_joni> parport sounds way cheaper ;)
[15:07:35] <alex_joni> 20$-30$
[15:07:55] <SWPadnos> and MESA may have output modules that can trigger cameras as well (though a parport may be able to do it also)
[15:08:16] <alex_joni> 5i20?
[15:08:27] <SWPadnos> "relay racks" :)
[15:08:35] <SWPadnos> but very small ones - just transistors
[15:10:54] <SWPadnos> actually, the mesa card would be ideal anyway, since it could do all the timin gitself, with an appropriate FPGA core
[15:20:17] <steve_stallings> steve_stallings is now known as steves_logging
[16:53:44] <jepler> well I'm back .. what did I miss?
[16:55:35] <SWPadnos> mocrocontroller discussions
[16:55:46] <SWPadnos> err - microcontroller discussions
[16:56:45] <jepler> I see a bit of that in my scrollback
[16:57:02] <SWPadnos> I missed anything else before that
[16:57:17] <SWPadnos> (I actually left this computer off for the night, for the first time in a long time)
[16:58:27] <jepler> gasp!
[17:07:30] <SWPadnos> the real gasp part is that this is a Windows 2000 machine, and I usually leave it on ;)
[19:09:25] <alex_joni> hi jeff
[19:09:46] <jepler> hi alex_joni
[19:09:53] <alex_joni> back from the trip?
[19:10:08] <jepler> yep
[19:10:20] <alex_joni> nice, you've been missed :D
[19:10:38] <jepler> have I really?
[19:10:48] <alex_joni> so I heard ;)
[19:10:51] <alex_joni> no, really
[19:11:34] <alex_joni> how was it?
[19:11:58] <jepler> oh it was fine
[19:12:24] <alex_joni> nice
[19:13:24] <jepler> and because they bumped us from our flight last night we now have a pair of free round-trip tickets, so we get to think about our next trip already
[19:13:40] <alex_joni> oh.. sweet.. whereto?
[19:14:44] <jepler> dunno yet
[19:14:58] <jepler> I want to go back to new mexico to see the sandhill cranes this winter
[19:15:09] <alex_joni> oh, any location basicly?
[19:15:13] <alex_joni> or limited to US ?
[19:15:30] <jepler> 48 states
[19:15:34] <Lerneaen_Hydra> nice!
[21:11:36] <alex_joni> you guys around?
[21:11:48] <cradek> I am, but leaving really soon
[21:12:08] <alex_joni> same here.. just wanted to remind us of the upcoming release ;)
[21:12:20] <alex_joni> wanted to know what others think of the schedule?
[21:12:35] <alex_joni> I'm looking at
http://sourceforge.net/pm/task.php?group_project_id=46285&group_id=6744&func=browse
[21:15:30] <cradek> I don't want to think about it right now...
[21:16:41] <alex_joni> cradek: ok
[21:16:47] <SWPadnos> quick question: to create the /dev/rtf nodes, is the command mknod -c 150 3 /dev/rtf3 ?
[21:17:09] <cradek> without the -
[21:17:14] <SWPadnos> ah - thanks
[21:17:40] <SWPadnos> I just installed dapper on my opteron, with emc2 and the magma kernel (it's a 32-bit install)
[21:17:47] <alex_joni> SWPadnos: it's also in the wiki
[21:17:53] <alex_joni> SWPadnos: any issues?
[21:17:53] <SWPadnos> wanted to run the testsuite stuff
[21:18:08] <alex_joni> I mean any problems so far?
[21:18:12] <alex_joni> during the install..
[21:18:12] <SWPadnos> only getting the nvidia driver to work, but it actually seems to work now (dual screen and all)
[21:18:26] <alex_joni> it might cause big problems with RT though
[21:18:33] <SWPadnos> that's what I wanted to check :)
[21:18:34] <cradek> I use nvidia too, ok as long as you don't run a machine
[21:18:41] <cradek> it'll be bad, trust me
[21:19:02] <SWPadnos> I'll take a look with the testsuite, then with a scope
[21:19:17] <cradek> run some opengl stuff and watch it suck
[21:20:02] <SWPadnos> yep
[21:20:30] <SWPadnos> mknod says "invalid device type '150'"
[21:20:58] <cradek> mknod /dev/rtf3 c 150 3
[21:21:25] <cradek> * cradek gently urges SWP toward the man page
[21:21:44] <SWPadnos> duh - i kant reed!
[21:21:55] <SWPadnos> that's better - thanks
[21:21:57] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TroubleShooting
[21:22:02] <SWPadnos> wow, are those numbers small!
[21:22:11] <cradek> just wait :-)
[21:22:23] <cradek> I have to run, might be back in a few hours
[21:22:33] <alex_joni> cradek: see you ..
[21:22:43] <alex_joni> cradek: maybe you get around at putting those debs in the repo?
[21:23:19] <SWPadnos> when I ran glxgears, I got one sample at 199000 or so
[21:23:44] <SWPadnos> with it running (at 13400 fps), I get 8000-9000 consistently
[21:23:48] <alex_joni> ouch
[21:23:56] <alex_joni> one should be enough they say :D
[21:24:13] <SWPadnos> well - the idea there is "don't start 3D apps when a machine is running" ;)
[21:24:35] <SWPadnos> I'm sure the numbers will suck if I maximize glxgears though :)
[21:25:08] <alex_joni> SWPadnos: tkemc?
[21:25:36] <alex_joni> I happen to know of a nicer emc GUI, but it uses 3D :)
[21:26:15] <SWPadnos> somehow I don't think axis would bog this machine down much :)
[21:26:29] <SWPadnos> unless I load a multi-megabyte NC file
[21:26:50] <SWPadnos> with glxgears maximized, the latencies were still averaging ~3000
[21:27:11] <SWPadnos> the user test is a little worse, ~3300 average (with glxgears at 1920x1200 on one screen)
[21:28:38] <SWPadnos> durr - there seems to be no realtime script (at least not in the path)
[21:28:43] <SWPadnos> should I be reading a manual again? :)
[21:29:19] <SWPadnos> nevermind
[21:29:51] <alex_joni> try /etc/init.d/realtime start ;)
[21:43:15] <alex_joni> good night all